Clash 自定义规则怎么写：rules 语法、匹配顺序与优先级详解

1. rules 的作用范围与基础语法

rules 是配置文件顶层的有序列表，用于决定连接交给哪个策略。它不负责创建节点，也不负责测速。规则右侧可以填写内置策略 DIRECT、REJECT，也可以填写配置中已经存在的代理节点名或策略组名。名称必须精确一致，包括空格和大小写。

本文以 Clash Nyanpasu 使用 mihomo 内核的常规规则模式为背景。Clash 不同内核支持的扩展规则并不完全一致；迁移配置时，应先在客户端的内核信息或启动日志中确认实际内核。下面的基础域名规则可以帮助理解分流，但不能据此认定所有内核都支持相同的高级字段。

先确认模式，再编辑字段

Rule 模式：按 rules 列表判断连接去向，是本文讨论的模式。
Global 模式：使用全局策略，不按普通 rules 列表进行分流。
Direct 模式：以直连方式处理流量，不能用来验证代理分流规则。

YAML 中的 mode: rule 表示规则模式。客户端界面也可能切换运行模式，因此要同时检查当前运行状态。系统代理与 TUN 则决定哪些流量进入内核，它们不是规则优先级开关；未进入内核的连接，不会因为新增一条规则就自动被接管。

mode: rule
rules:
  - DOMAIN,portal.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,节点选择
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,节点选择

2. 常用规则类型与字段位置

普通规则通常写成“类型、匹配内容、目标策略”。MATCH 不需要匹配内容；部分 IP 规则可以追加 no-resolve。使用英文逗号分隔参数，列表行前保留短横线与空格，缩进统一使用空格，不使用 Tab。

类型	示例	匹配含义
`DOMAIN`	`DOMAIN,api.example.com,DIRECT`	仅匹配完整域名 api.example.com。
`DOMAIN-SUFFIX`	`DOMAIN-SUFFIX,example.com,DIRECT`	匹配根域名及其各级子域名。
`DOMAIN-KEYWORD`	`DOMAIN-KEYWORD,example,节点选择`	匹配域名中包含的字符串，范围较宽。
`IP-CIDR`	`IP-CIDR,10.0.0.0/8,DIRECT,no-resolve`	匹配 IPv4 地址段。
`IP-CIDR6`	`IP-CIDR6,fc00::/7,DIRECT,no-resolve`	匹配 IPv6 地址段。
`GEOIP`	`GEOIP,CN,DIRECT`	按目标 IP 所属的地理数据库条目判断。
`RULE-SET`	`RULE-SET,business,节点选择`	引用名为 business 的规则提供器。
`MATCH`	`MATCH,节点选择`	接收前面规则均未命中的连接。

域名规则不填写 URL 路径

DOMAIN 的匹配内容是主机名，不是完整网址。应写 api.example.com，而不是 https://api.example.com/login。常规域名规则无法区分同一主机下的 /login 与 /images。HTTPS 请求的路径也不是普通域名分流可直接使用的条件。

DOMAIN-SUFFIX,example.com 会匹配 example.com 和 a.example.com，不会因为另一个域名含有相似字符就匹配 notexample.com。而 DOMAIN-KEYWORD 是字符串条件，容易扩大范围，通常应排在明确的域名例外之后。

3. 规则优先级：从上到下，首条命中

常规规则列表没有“域名规则天然高于 IP 规则”或“越精确越优先”的自动排序。内核按列表顺序检查，首条命中后便采用其目标策略，不再用下面的规则覆盖。精确规则只有放在更宽泛的规则前面，才能形成有效例外。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,节点选择
  - MATCH,节点选择

api.example.com：第 1 条命中，直连。
www.example.com：第 1 条不匹配，第 2 条命中，交给“节点选择”。
example.net：前两条都不匹配，由第 3 条兜底。

如果把第 2 条移到第 1 条之前，api.example.com 会先命中后缀规则，原本的直连例外就失效。类似地，将 MATCH 放到列表首行，会使后面的常规规则失去匹配机会。

4. IP-CIDR、GEOIP 与 no-resolve

IP-CIDR,192.168.0.0/16,DIRECT 覆盖从 192.168.0.0 到 192.168.255.255 的 IPv4 地址。只处理单个 IPv4 地址时可使用 /32；只处理单个 IPv6 地址时可使用 /128。网段范围应按实际需求填写，不能把所有内网地址都视为同一条业务规则。

当连接目标是域名时，IP 类规则可能需要解析域名才能判断。追加 no-resolve 表示不要为了这一条规则主动触发域名解析；如果连接已经具备可用的目标 IP，仍可进行地址匹配。它不表示关闭整个客户端的 DNS，也不表示所有 DNS 请求都会被跳过。

rules:
  - DOMAIN,intranet.example.com,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

这里把已知的内部域名单独放在前面，是因为带 no-resolve 的地址规则不能保证仅凭域名就判断出其内网地址。GEOIP 使用的是目标 IP 的数据库分类，不是页面内容、域名注册地或服务器品牌；CDN 地址和数据库更新都可能影响结果。

5. RULE-SET 与 rule-providers 的配合

规则数量较多时，可以把匹配内容放入规则提供器，再用 RULE-SET 引用。rule-providers 定义数据来源和格式，rules 定义它在匹配链中的位置及命中后的策略。提供器名称相同，并不意味着它会自动参与分流，仍需在 rules 中引用。

本地 domain 规则集示例

下面使用 mihomo 的本地文件提供器。将文件路径对应的规则集放到内核实际使用的配置目录中；相对路径以运行时工作目录为准，不应仅凭下载文件所在位置推断。可从客户端日志确认实际读取路径。

rule-providers:
  business:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/business.yaml

rules:
  - DOMAIN,health.example.org,DIRECT
  - RULE-SET,business,节点选择
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

./rules/business.yaml 的内容如下。对于 domain 类型，+.example.org 表示匹配该域名及其子域名；不要把完整的 DOMAIN-SUFFIX,example.org,节点选择 规则行直接塞进 domain 类型的列表。

payload:
  - '+.example.org'
  - 'api.example.net'

behavior: domain：内容为域名匹配表达式。
behavior: ipcidr：内容为 IP 地址段。
behavior: classical：内容为相应内核支持的规则条件，例如 DOMAIN-SUFFIX,example.org，通常不在条目中填写目标策略。

三种行为不能随意混用。远程提供器还涉及下载、更新和缓存，排错时应先确认提供器加载成功，再分析规则优先级。即便规则集有数千条内容，它在主列表中的优先级仍由那一行 RULE-SET 的位置决定；主列表前方已命中的规则不会被它重新覆盖。

6. 订阅规则的持久化与覆写检查

远程订阅更新可能重新生成配置。直接修改下载得到的 YAML，常见结果是本次生效、下次更新丢失。较稳妥的流程是保留原订阅，把个人规则放在客户端支持的本地覆写、合并或脚本处理环节，并确认处理后的最终顺序。具体入口名称随客户端版本而异，不要把“保存订阅文本”等同于“保存持久覆写”。

备份当前可用配置，记录所选 Profile、模式和策略组名称。
在配置管理中确认正在使用的配置，而不是只编辑一份未激活的副本。
先加入 1 条明确域名规则，确保它出现在原有宽泛规则之前。
查看运行时生成的配置，确认只有一份 rules，并核对首行、规则集引用和末尾 MATCH。
执行一次订阅更新，再次检查规则是否保留、顺序是否改变。

不同合并工具对列表的行为可能是替换、追加或前插。仅在文本中看到新规则并不足以证明有效：追加到 MATCH 后面的规则虽然存在，却无法命中。脚本覆写也应检查输出结果，而不是只检查脚本是否执行成功。YAML 层级与字段说明可参阅YAML 配置手册。

7. 自定义规则不生效的排查顺序

排查时使用同一个目标主机，固定策略组选择，逐次只修改一个条件。连接面板中的“命中规则”“目标策略”和“实际代理链”是不同信息：命中“节点选择”只说明交给了该组，组内若选择 DIRECT，实际仍然直连。

现象	优先检查	处理动作
连接面板没有目标请求	应用流量是否进入内核	检查系统代理、应用代理或 TUN 路由；先解决流量入口。
命中较宽的旧规则	自定义规则的实际行序	把精确例外移到该规则之前，检查覆写是否只是追加。
提示策略不存在	规则右侧的组名	复制当前配置中的完整组名，核对空格、大小写及配置切换。
RULE-SET 加载失败	提供器名称、路径和 behavior	检查启动日志与文件格式，先修复加载错误再测试流量。
修改后仍走旧策略	旧连接是否复用	关闭目标连接后重新发起请求，不只刷新已有长连接。
更新订阅后规则消失	修改是否保存在生成文件	迁移到持久覆写，并检查更新后的最终配置。

一次最小验证

确认运行模式为 Rule，并确保所选配置已经应用。
为实际测试域名添加一条 DOMAIN 规则，放在列表前部。
保存并应用配置；若有解析错误，先恢复备份，不继续叠加修改。
关闭该目标的已有连接，再重新访问一次。
在连接详情中核对目标主机、命中规则、策略组和实际出口。
确认结果后，再扩展为后缀规则或规则集，并复测未命中的兜底路径。

规则维护的核心是三项：流量确实进入内核、匹配条件与连接信息一致、目标规则排在覆盖它的规则之前。先用精确域名建立可复现结果，再增加 IP 分类和规则集，比同时修改大量条目更容易判断原因。需要核对 Profile、策略组与 TUN 的概念时，可查看术语手册。