跳到正文
进阶配置 预计阅读 12 分钟

Clash 规则写法详解：DOMAIN-SUFFIX、IP-CIDR 匹配顺序与 MATCH 兜底

规则按书写顺序自上而下匹配，命中第一条即停止。本文拆解 DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、GEOIP、MATCH 的语法，并说明 no-resolve 的作用与规则排序原则。

规则不生效，先确认流量是否进入规则模式

给网站加了直连规则，连接却仍走代理；把某个地址段改成代理，访问结果却没变化。这类问题不一定是语法错误。先确认应用流量经过 Clash，再确认内核使用的是规则模式，最后才检查规则内容。

  1. 在客户端的「代理模式」中选择「规则（Rule）」。不同客户端也可能显示为「规则模式」；不要在「全局（Global）」或「直连（Direct）」模式下验证分流规则。
  2. 打开「连接（Connections）」页面，重新访问目标网站。找不到新连接时，先排查系统代理、应用自己的代理设置或 TUN 接管范围。
  3. 确认当前选中的配置确实是刚修改的那一份。保存文件后需要让客户端重新加载配置，单纯保存不一定会更新运行中的内核。
  4. 关闭目标应用的旧连接再测试。规则主要在连接建立时选择出站，已经建立的长连接不会因为文件变更就自动重新分流。

一条规则的结构：类型、匹配值与出站策略

常见规则写在 YAML 的 rules: 列表中，每行以短横线开头。域名规则通常有三个字段：规则类型、匹配值、出站策略。MATCH 不需要匹配值；支持 no-resolve 的 IP 类规则还可以增加第四个字段。

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,REJECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

这段配置只使用内置策略，便于观察结构：DIRECT 表示直连，REJECT 表示拒绝连接。实际需要代理时，最后一个字段应填写配置中已经存在的代理节点名或策略组名。PROXY 不是在所有配置里都存在的通用内置策略。没有同名节点或策略组，直接照抄就可能导致配置加载失败。

  • 使用英文半角逗号，不要写成中文逗号。
  • YAML 缩进使用空格，不要使用 Tab；同一列表中的规则保持相同缩进。
  • 策略名称必须与定义一致，包括大小写、空格和符号。
  • 在已有配置中修改时，把条目合并到原来的 rules: 下，不要再添加一个同名顶层键。

域名规则：DOMAIN、DOMAIN-SUFFIX 与 DOMAIN-KEYWORD

类型示例匹配范围
DOMAINDOMAIN,example.com,DIRECT只匹配 example.com，不包含 www.example.com。
DOMAIN-SUFFIXDOMAIN-SUFFIX,example.com,DIRECT匹配 example.com 本身，以及 www.example.com、api.example.com 等子域名。
DOMAIN-KEYWORDDOMAIN-KEYWORD,example,REJECT匹配域名中出现 example 字符串的连接，范围比后缀规则更宽。

后缀按域名边界匹配，不是任意字符串结尾

DOMAIN-SUFFIX,example.com,DIRECT 会匹配 a.example.com，但不会匹配 notexample.com，也不会匹配 example.com.other.org。通常不需要写 *.example.com；这里的后缀类型已经包含子域名语义。

规则值只写域名，不要加入 https://、端口或路径。访问 https://example.com:8443/account 时，域名字段仍然是 example.com。普通域名规则不能区分同一站点的 /account 与 /video 页面路径。

精确例外放在宽泛规则前面

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

这里允许 login.example.com 直连，其余属于 example.com 的域名被拒绝。如果交换前两行，登录域名会先命中后缀规则，后面的精确规则就没有机会生效。内核不会比较哪条规则“更精确”，也不会在命中后继续寻找更优选项。

DOMAIN-KEYWORD 适合明确知道匹配范围的场景，不适合靠一个常见短词给整类服务分流。关键词越短，越容易误伤名字中恰好带有相同字符串的其他域名。

IP-CIDR 与 GEOIP：地址段和地区数据库不是一回事

IP-CIDR 判断目标 IPv4 地址是否属于指定网段。192.168.0.0/16 覆盖从 192.168.0.0 到 192.168.255.255；/32 只表示一个 IPv4 地址。IPv6 地址段使用 IP-CIDR6，单个 IPv6 地址可以使用 /128。

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,代理选择

GEOIP,CN,DIRECT 表示根据当前加载的 IP 地区数据库判断目标地址是否归属 CN，再选择直连。它不是“所有中文网站直连”，也不按网页语言或域名后缀判断。CDN 地址分配、数据库更新和 IPv4/IPv6 返回差异，都可能让同一网站在不同网络下命中不同结果。

如果某个服务必须稳定走固定策略，优先使用明确的域名规则。把地区规则当成较靠后的补充更容易维护。无法加载所需地区数据库时，应先处理客户端日志中的资源加载问题，而不是通过调整规则顺序掩盖错误。

no-resolve 的作用：不为这一条规则额外解析域名

当连接携带域名，而规则需要目标 IP 时，内核可能为了执行 IP 匹配发起 DNS 查询。no-resolve 用来避免为这条 IP 规则主动触发域名解析。它不是全局 DNS 开关，也不是“忽略这条 IP 规则”。

  • 目标本来就是 IP：可以直接判断地址是否属于网段，带有 no-resolve 仍可能命中。
  • 连接已有可用的目标 IP：仍可能进行匹配，不能把这个参数理解为“域名连接必定跳过”。
  • 只有域名、没有可用目标 IP：不会仅为这条规则额外解析域名，因而可能继续检查后面的规则。
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,代理选择

这组顺序先处理明确域名，再检查私网地址，之后进行地区判断。注意：虽然第二条带了 no-resolve，第三条没有，它仍可能触发为地区匹配所需的解析。给某一条规则加参数，不会约束后续所有规则的 DNS 行为。

如果把第三条改成 GEOIP,CN,DIRECT,no-resolve，只有域名且没有可用目标 IP 的连接可能无法在此完成地区判断，随后落到代理兜底。是否添加，应根据预期分流结果和 DNS 路径决定，不能为了减少查询就批量附加。

MATCH 兜底与自上而下的排序原则

MATCH 是无条件匹配，写法为 MATCH,策略名称。它通常放在规则列表最后，明确接住所有前面没有处理的连接。不要写成 MATCH,*,策略名称，也不要把它放在还有有效规则需要执行的位置之前。

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,代理选择
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,代理选择

用三次访问检查这份顺序

  1. 访问 login.example.com：第一条命中，直接结束规则查找，使用 DIRECT。
  2. 访问 static.example.com：第一条不匹配，第二条命中，交给「代理选择」策略组。
  3. 访问不属于上述域名、且目标地址未命中 IP 与地区规则的服务：最终由 MATCH 交给「代理选择」。

这些是配置推导结果，不代表示例域名提供可访问的服务。实测时换成自己需要分流的真实目标。还要注意，命中策略组不等于一定走远端节点：如果该组当前选择了 DIRECT，最终仍然直连。

实用排序通常是：精确例外、明确的域名范围、其他业务规则或规则集、IP 与地区补充、最终兜底。这个顺序不是内核强制规定；如果业务要求某条拒绝规则优先于例外，就应该把它前移。关键是明确每条规则覆盖哪些后续条目，而不是机械地按规则类型分类。

订阅与规则集：改对内容，也要改对位置

订阅更新后，自定义规则消失，通常是修改了会被重新下载覆盖的订阅文件。先保留原配置，再使用客户端提供的覆写、合并或扩展配置能力。不同客户端的入口和合并格式不同，不要把某个客户端的扩展字段直接当成 Clash 内核通用配置。

RULE-SET 也受所在位置影响

在 Clash 支持的相应内核版本及 mihomo 中，规则提供器通常定义在 rule-providers:，通过 RULE-SET,提供器名称,策略名称 引用。引用条目参与同一套自上而下匹配：如果前面已经命中宽泛域名规则，就不会再检查后面的规则集。

  • behavior: domain 的载荷按域名集合格式编写，不要直接塞入完整的三字段出站规则。
  • behavior: ipcidr 的载荷是 IP 地址段，适合地址范围集合。
  • behavior: classical 使用规则条件写法，最终出站策略由引用它的 RULE-SET 条目指定。

原版 Clash、不同历史分支和 mihomo 的规则类型与扩展字段并不完全一致。遇到 unsupported rule type 一类提示，先查看客户端「关于」或内核信息，确认实际运行的内核，再核对对应文档。升级界面程序不一定意味着内核已经切换。

验证规则：一次只改一项，查看命中规则和最终出站

  1. 备份并保存。保留一份能正常启动的配置，只增加一条精确域名规则，重新加载后观察是否有解析错误。
  2. 清理旧连接。关闭目标应用，或在客户端「连接」页结束对应连接，再重新发起请求。浏览器的 HTTP/2、HTTP/3 连接复用可能让旧路径继续存在。
  3. 核对目标。在连接详情中检查域名、目标 IP、命中规则与策略链。不同客户端字段名称略有差别，不能只看总流量曲线。
  4. 检查日志。必要时临时把 log-level 设为 debug，重现一次问题后恢复 info。分享日志前遮盖订阅链接、令牌和不宜公开的地址。
现象优先检查
一直命中 MATCH规则是否已加载；域名是否拼错；连接是否只携带 IP；规则集是否加载成功。
精确规则没有命中前面是否存在覆盖它的后缀、关键词或规则集；测试连接是否在修改前已建立。
命中代理组却仍直连该策略组当前选择项是否为 DIRECT，以及嵌套组的最终选择。
域名规则对部分应用无效连接中是否缺少域名；应用是否自行解析；系统代理或 TUN 是否实际接管了该应用。
更新订阅后恢复原样修改的是订阅原文件还是持久化覆写；自定义条目是否被合并到宽泛规则之后。

如果流量只有目标 IP，域名规则可能缺乏匹配依据。mihomo 的 Fake-IP 映射、DNS 接管与嗅探配置会影响域名信息是否可用，但嗅探不能保证识别所有协议，更不能恢复所有加密连接里的真实域名。先看连接详情，再决定是否调整 DNS 或嗅探设置，避免同时修改多个环节。

Clash 安装包