先说清楚：Clash 里的「分流」到底在分什么？

当你打开一个网页或客户端发起连接时，数据包会经过操作系统、本机 DNS，再到代理内核。Clash 系客户端在内核里维护一张由规则组成的决策链：对每一个待转发的目标（常见是域名或解析后的 IP），从上到下寻找第一条能够匹配的规则，然后执行规则末尾所写的策略名。策略名可能对应「直连」「拒绝」，也可能对应某个代理策略组，由组内再选出具体节点。

因此，「写自定义分流规则」本质上是在编辑配置里的 rules: 段落（以及与之配套的 proxies、proxy-groups 命名），让特定流量在决策链的靠前位置被「截胡」，从而不走你默认的兜底策略。零基础阶段不必死记所有字段，先建立三件事的直觉：顺序优先、类型决定匹配对象、末尾策略名必须在别处有定义。

一条规则长什么样？

在经典 Clash 语法中，rules 是一个 YAML 列表，每一项通常写成一行字符串，用英文逗号分隔若干字段。最常见的形态是「类型, 参数, 策略名」，例如 DOMAIN-SUFFIX,google.com,PROXY。其中：

  • 类型：告诉内核用什么方式理解第二个字段（精确域名、后缀、IP 段、地理库等）。
  • 参数：参与匹配的具体值；某些类型会多一个附加参数（例如 GEOIP 常带国家码与可选参数）。
  • 策略名：必须是 DIRECT、REJECT 等内置关键字，或你在 proxy-groups 里声明过的组名、在 proxies 里声明过的单代理名（视客户端与内核版本而定，GUI 导出模板最可靠）。

若策略名写错一个字节，常见后果是配置校验失败无法启动，或运行时回落到意外路径。建议始终从 GUI 的「当前可用策略组列表」复制名称，而不是手打。

铁律：自上而下，命中即停

这是新手最容易踩坑的地方。rules 不是「评分表」，没有权重合并；它就是有序列表。某个请求一旦命中了第 17 条规则，第 18 条及以后都不会再看。于是出现两类典型问题：

  • 想精细控制某站，却总被前面的 GEOIP 或宽泛后缀规则抢走：你需要把更具体的 DOMAIN 规则挪到更靠上，或放宽前面规则的覆盖范围。
  • 把「大而全」的拦截或直连列表顶在最前，导致后面所有自定义规则形同虚设：应把个人微调放在「公共列表」之前还是之后，取决于你想让谁拥有更高优先级；没有绝对对错，只有是否符合你的意图。

调试时的实用技巧是：先在脑中把规则想成漏斗，再对照客户端日志里的「命中哪条规则」输出（若 GUI 提供连接记录或内核日志），逐项核对顺序，而不是盲目改节点。

常用规则类型速查（够用版）

不同内核版本会扩展更多类型，但下列几项覆盖了绝大多数入门场景。实际键名大小写请以你使用的 Mihomo／Clash Premium 文档为准。

类型（示意） 适用场景 备注
DOMAIN 精确匹配单个完整域名 适合「就这一个 host」的定点分流
DOMAIN-SUFFIX 匹配某后缀及其子域 覆盖面广，写得太宽容易误伤
DOMAIN-KEYWORD 域名中包含某关键字即命中 非常猛，慎用，易误匹配 CDN 共用域名
IP-CIDR / IP-CIDR6 按网段分流 常用于局域网直连、对端已解析为固定 IP 的服务
GEOIP 按地理归属 IP 库命中 依赖内置或外置数据库；与 DNS 结果强相关
MATCH / FINAL 兜底，匹配剩余全部 一般放在列表最后，类似「其他走默认」
部分教程把兜底写成 MATCH，部分模板写成 FINAL。请以当前 GUI 导出的内核版本为准，不要混用旧文章片段。

最小示例：让指定域名走代理，其余走默认

下面是一段教学用骨架，省略了端口、DNS、订阅等噪声字段；你真正使用时必须在完整合法配置基础上增删，而不是单独粘贴启动。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - auto
      - direct

proxies:
  - name: auto
    type: ss
    server: example.com
    port: 443
    cipher: aes-128-gcm
    password: "replace-me"

rules:
  - DOMAIN,learn.example.com,PROXY
  - DOMAIN-SUFFIX,cdn.example.net,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

阅读顺序：先看到 learn.example.com 走 PROXY 组；带 cdn.example.net 后缀的走直连；中国大陆 IP 段直连；剩下全部进入 PROXY。你可以把前两行替换成自己关心的域名，立刻得到可感知的分流效果。记得把示例里的 proxies 换成真实订阅解析出的节点结构。

策略组与规则如何配合？

规则末尾写的 PROXY 往往不是一个具体节点，而是一个 select 或 url-test 类型的策略组。这带来一个好处：你可以在 GUI 里随时切换组内选项，而不必改规则本身。入门阶段的建议结构是：用少量策略组承载「主代理」「直连」「拒绝」等角色，在 rules 里只引用这些稳定组名；细粒度站点规则尽量用 DOMAIN 系列指向同一策略组，减少重复维护。

若你把规则指向了尚未定义的组名，或组名与大小写不一致，就会回到上一节的启动失败问题。合并他人配置时，先对齐「组名表」再对齐「规则表」，比从中间抄一段 rules 更安全。

为什么有时改了规则却不生效？

很多「规则写了 DOMAIN 却仍走意外策略」的案例，根因不在规则行本身，而在DNS 解析路径与 fake-ip 模式：内核在决策时看到的「目标」可能与你浏览器地址栏里的域名不一致。完整讨论属于另一篇文章的范畴，此处只给行动建议：改规则同时打开 GUI 的连接日志，确认当时用于匹配的主机名；若你启用了 TUN 或复杂 DNS 模板，可对照本站《Clash TUN 模式完全指南》检查流量入口与解析是否一致。

规则变多之后：交给 Rule Providers

手写几十条规则很治愈，手写几千条则很难维护。社区主流做法是：把大列表放到 rule-providers 或 Mihomo 的 ruleset 中远程订阅，在 rules 里用 RULE-SET 一类条目挂载。你仍然需要理解本文的顺序与策略名，只是把「长名单」外包给可更新的提供者。若你已熟悉基础语法，可继续阅读《Clash Rule Providers 进阶教程》，把维护成本降下来。

写法与合规上的自我提醒

自定义规则让你精确控制流量走向，也意味着你要对自己写下的 DOMAIN 与 IP 段负责。复制来源不明的「万能规则」时，请意识到那等价于把路由决策外包给第三方文本。企业或敏感环境应在内部评审后再下发；个人用户至少应能解释每一条置顶规则的用途，而不是整页粘贴。

入门自检清单（可收藏）

  1. 确认策略名真实存在
    对照 proxy-groups 与 proxies，避免拼写与大小写错误。
  2. 从宽到窄还是窄到宽，想清楚再排序
    个人定制通常应位于「会误伤的大规则」之前或之后，取决于你想让哪一方优先。
  3. 慎用 DOMAIN-KEYWORD
    除非你能接受误匹配共享基础设施上的无关流量。
  4. 永远保留兜底
    用 MATCH 或模板要求的等价条目接住未命中的流量，避免未定义行为。
  5. 大改前备份整份配置
    与升级内核一样，先导出再动刀，出问题时可以秒级回滚。

小结

为 Clash 编写自定义分流规则，核心不是背全字典式的类型表，而是理解有序匹配与策略名解析这两个齿轮如何咬合。先写最小可用集合，用日志验证命中路径，再逐步叠加；长名单交给 Rule Providers，把「顺序与意图」留在主配置里，才是可长期维护的姿势。

若你还希望把客户端版本、DNS 模板与系统代理开关一并理顺，可在本站使用文档里按平台查阅，再搭配规则调试，整体体验会顺很多。相比零散渠道获取的安装包，从本站统一入口获取客户端也能减少「内核与 GUI 版本错配」导致的解析差异。

相比其他同类工具，Clash 系在规则表达能力与 GUI 生态上往往更利于渐进式学习：你完全可以从三五条手写规则起步，再平滑演进到订阅规则集，而不用一次性面对黑盒式全局开关。

→ 立即免费下载 Clash，开启流畅上网新体验

前往本站下载页获取客户端