进阶原理 预计阅读 10 分钟

Clash 自定义规则写法:规则类型、匹配顺序与 MATCH 兜底

梳理 DOMAIN、DOMAIN-SUFFIX、IP-CIDR、GEOIP 等常用规则的语法,说明自上而下首条命中的匹配机制,以及覆写规则时的排序技巧。

1. 规则语法：匹配条件与出口策略

Clash 自定义规则解决的是“这条连接应该交给哪个出口处理”。客户端提供编辑界面，内核负责实际匹配；原版 Clash 与 Clash Meta（现名 mihomo）的规则能力并不完全相同。本文先讲两者常见的基础语法，涉及规则集时再单独说明兼容条件。

常见规则写在 YAML 顶层的 rules: 列表中，每行通常由“规则类型、匹配内容、策略”组成，部分类型还允许附加参数。MATCH 没有匹配内容，只需填写出口策略。

rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,REJECT
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - MATCH,DIRECT

这是一段规则配置片段，不是完整的订阅配置。DIRECT 表示直连，REJECT 表示拒绝连接。如果策略写成 代理出口，当前配置就必须已经存在这个名称的节点或策略组；名称是精确引用，不会根据中文含义自动创建出口。

2. DOMAIN 与 DOMAIN-SUFFIX：精确匹配和域名后缀

类型示例实际范围
DOMAINDOMAIN,api.example.com,DIRECT只匹配 api.example.com，不覆盖其子域名。
DOMAIN-SUFFIXDOMAIN-SUFFIX,example.com,DIRECT匹配 example.com 以及 api.example.com 等子域名。
DOMAIN-KEYWORDDOMAIN-KEYWORD,example,REJECT匹配域名中含有 example 的连接，范围比后缀规则宽。

域名规则不填写网址路径

要处理 https://api.example.com/v1/status，应填写域名 api.example.com，而不是把 https://、/v1/status 或端口一起写进去。普通域名规则无法按 HTTPS 页面路径分流；同一域名的两个路径不会因此走不同出口。

  • 只为一个接口设置例外：优先使用 DOMAIN。
  • 希望主域名与所有子域名采用同一策略：使用 DOMAIN-SUFFIX。
  • 关键词规则容易匹配到无关域名，应在连接记录中确认范围后再长期启用。

域名匹配还依赖内核能否获得目标域名。应用直接访问 IP、DNS 没有按预期经过内核，或者连接元数据缺少域名时，不能假定 DOMAIN 规则必然生效。mihomo 的域名嗅探在部分场景可以补充信息，但也不是对所有协议都有效的通用补救。

3. 规则顺序：自上而下，第一条命中即停止

Clash 不会先收集所有命中的规则，再选“看起来最精确”的一条。常规规则列表按顺序检查，第一条满足条件的规则决定出口，后面的规则不再参与这条连接的选择。因此，精确例外通常放前面，宽泛分类放后面。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,REJECT
  - MATCH,DIRECT

在这个例子中，访问 api.example.com 会直连，访问 www.example.com 会被拒绝。如果把前两行交换位置，api.example.com 会先命中域名后缀规则，后面的精确直连规则便没有机会生效。这不是 DOMAIN 的优先级降低，而是匹配已经结束。

一个便于维护的排列顺序

  1. 明确的单站例外：需要单独放行、拒绝或固定出口的域名。
  2. 局域网与内部服务：确认属于本地网络的地址段和内部域名。
  3. 业务分类与规则集：按用途组织的大范围分流规则。
  4. 地区等宽泛判断：例如依赖地理数据库的 IP 规则。
  5. MATCH：处理前面都没有匹配到的连接。

这是一种维护思路，不是必须照搬的固定模板。如果安全要求规定某类连接必须优先拒绝，就应把拒绝规则放在相应放行规则前，并检查是否存在冲突。真正需要保持的原则是：每条靠前的规则，都应当允许它覆盖后面的规则。

4. IP-CIDR 与 GEOIP：目标地址、解析与 no-resolve

IP-CIDR 按目标 IPv4 地址范围匹配，IP-CIDR6 用于 IPv6。比如 192.168.50.0/24 覆盖这个网段的地址，适合给家庭 NAS、打印机或内部服务配置直连；它不是“来源设备”的地址筛选条件。

rules:
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - IP-CIDR6,fd00::/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

GEOIP,CN,DIRECT 按当前 IP 地理数据库判断目标 IP 是否归入 CN，并不表示“中国网站”的完整清单。网站可能使用跨地区 CDN，同一个域名也可能解析到不同地址。数据库内容、更新时间和 DNS 结果都会影响判断，应以实际解析出的目标 IP 和数据库归类确认命中的 GEOIP 规则。

no-resolve 的作用边界

当连接只带有域名而没有可用的目标 IP 时，IP 类规则可能触发 DNS 解析。附加 no-resolve 的含义是：不要为了匹配这条规则主动解析域名；如果连接元数据中已有可用 IP，仍可进行地址匹配。它不等于关闭 DNS，也不等于让所有域名请求绕过 IP 判断。

  • 局域网 IP 直连规则常附加 no-resolve，避免为了检查一个内网网段而提前解析其他域名。
  • 希望 GEOIP 对尚未解析的域名作判断时，不应机械地给它追加 no-resolve。
  • 如果需要按发起连接的设备地址分流，应查看内核支持的来源地址规则，而不是把来源 IP 填进 IP-CIDR。

上面的 fd00::/8 只是一个 IPv6 本地地址范围示例，并未覆盖所有本地网络场景。实际配置应按设备地址规划选择网段，也要检查 DNS 返回 IPv6 地址后是否仍走预期策略。

5. MATCH 兜底：最后一条规则的出口选择

MATCH 是无条件匹配。它放在列表中间时，下面的普通规则实际上无法再被这条常规匹配流程访问。因此，通常只保留一条，并放在列表末尾。把自定义规则追加到 MATCH 后面，是“配置能加载、实际不生效”的常见原因。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,REJECT
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - MATCH,代理出口

此例假设配置中已经存在名为 代理出口 的策略组。前三条之外的连接都会交给该组，但最终出口仍取决于组内当前选项：如果组里选中 DIRECT，连接仍会直连。规则命中某个组，与最终使用某个代理节点，是两个不同层面的结果。

6. 订阅覆写：前置插入、后置追加与整体替换

订阅通常会定期更新，直接编辑下载生成的配置文件，下一次更新可能覆盖修改。更稳妥的方式是使用客户端提供的本地覆写、合并配置或规则编辑功能。不同客户端与版本的入口、字段和合并语义不同，不能把某个客户端的覆写语法当成通用 Clash YAML。

先检查最终配置，再判断是否保存成功

  1. 备份当前可用配置，记录原有策略组名称和最后一条兜底规则。
  2. 在当前订阅关联的本地覆写中，选择前置插入自定义规则；若界面只有追加功能，确认插入位置不是 MATCH 之后。
  3. 查看合并后的生效配置，搜索测试域名，检查它确实出现在 rules 中，而且位于宽泛规则前。
  4. 重载配置后建立新连接，再核对命中的规则。不要只观察编辑器里的原始片段。

“替换 rules”会移除原有规则列表，可能连同订阅中的规则集引用、局域网例外和兜底策略一起移除。只需要改一个域名时，优先考虑前置一条精确规则，而不是复制整份订阅重新维护。

RULE-SET 的位置同样有顺序

支持 rule-providers 的内核可以通过 RULE-SET 引用规则集；具体支持范围需核对内核与版本，不能笼统认为所有原版 Clash 构建都支持。下面片段假设已经定义了名为 work-domains 的 provider，以及名为 代理出口 的策略组：

rules:
  - DOMAIN,status.example.com,DIRECT
  - RULE-SET,work-domains,代理出口
  - MATCH,DIRECT

即使规则集内部包含 status.example.com，前面的 DOMAIN 例外也会先匹配。规则集不会脱离 rules 列表获得额外优先级。还需核对 provider 的 behavior 和文件内容格式：domain、ipcidr、classical 的载荷写法不能随意混用。

7. 自定义规则不生效：按连接记录逐步排查

验证规则最好一次只改一项。可以先为自己的测试域名加入一条临时 REJECT 规则，放在列表顶部，重载后发起新请求；确认连接记录命中该规则，再改回实际需要的出口。测试结束应删除临时拒绝规则，避免影响后续使用。

现象优先检查下一步
新规则完全看不到当前激活的订阅、覆写关联、生效配置确认正在编辑的配置就是内核加载的配置。
命中其他规则列表中靠前的 DOMAIN-SUFFIX、RULE-SET、MATCH把精确例外移到相关宽泛规则之前。
命中策略组但出口不对该组当前选项及嵌套策略组沿策略链查看最终节点或 DIRECT。
只有部分请求符合预期重定向域名、资源域名、IPv6 与已有连接逐条查看新连接，不只观察浏览器地址栏。
重载时报错YAML 缩进、规则拼写、策略与 provider 名称先通过配置检查，再重新加载。

用内核检查配置语法

直接使用 mihomo 命令行时，可在配置文件所在目录执行以下检查；可执行文件需要位于命令搜索路径中，且配置引用的资源应能被正确找到：

mihomo -t -f config.yaml

检查通过说明配置满足该内核的加载要求，不代表分流符合预期。仍需打开客户端的连接记录或日志，观察目标域名、目标 IP、命中规则和策略链。使用图形客户端时，也要核对其实际加载的是哪份生成配置，而不是只检查手边的一份备份文件。

最后，修改规则通常不会把已经建立的长连接立即搬到新出口。浏览器的 HTTP/2 连接、下载任务和即时通信连接可能继续复用原来的通道。保存并重载后，先重新建立测试连接；必要时关闭对应的旧连接再测试，避免把连接复用误判为规则失效。

维护规则时保留少量有明确用途的例外，记录它们为什么放在当前位置。遇到问题，依次确认“流量是否进入内核、是否为规则模式、生效列表顺序、命中策略、最终出口”，通常比反复切换节点更容易定位原因。

下载Clash选择适合设备的客户端