规则写对了却不生效？多半是顺序放错了

一句话结论：Clash 的规则是从上往下逐条比对、命中第一条就停止，不再往下看。 所以一条宽泛的规则排在前面，会让它后面所有更具体的规则永远不被执行——规则还在配置里，只是形同虚设。

一个典型的失效例子

rules:
  - GEOIP,CN,DIRECT
  - DOMAIN-SUFFIX,example.cn,节点选择   # ← 永远不会命中
  - MATCH,节点选择

作者的本意是「国内直连，但 example.cn 这个特例要走代理」。实际结果是 example.cn 走了直连——因为它解析到国内 IP，第一条 GEOIP,CN 就把它拦下了，第二条根本轮不到。

把两条对调就正常了。规则的排列原则很简单：从具体到宽泛。

推荐的顺序

rules:
  # 1. 局域网——必须最前
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve

  # 2. 拦截类——越早拦越省事
  - DOMAIN-SUFFIX,doubleclick.net,REJECT

  # 3. 具体域名规则——你想精确控制的
  - DOMAIN-SUFFIX,openai.com,节点选择
  - DOMAIN-SUFFIX,github.com,节点选择

  # 4. 按域名判断的批量规则
  - DOMAIN-SUFFIX,cn,DIRECT

  # 5. GEOIP——宽泛，且会触发 DNS 解析
  - GEOIP,CN,DIRECT

  # 6. 兜底
  - MATCH,节点选择

局域网为什么必须最前

内网地址走代理不但没意义，还会导致路由器后台、NAS、本地开发服务器打不开。如果它排在 GEOIP 后面，而某些内网段被判成了别的归属，就会出现「192.168.1.1 打不开」这种诡异问题。

no-resolve 这个后缀也很重要：它告诉 Clash「不要为了判断这条规则去做 DNS 解析」。IP 类规则加上它可以避免不必要的解析开销。

GEOIP 为什么必须靠后

两个原因。

一是它太宽泛。 它匹配所有解析到国内 IP 的地址，会吃掉你精心写的域名规则。

二是它需要 DNS 解析。 请求里给的通常是域名，而 GEOIP 判断的是 IP，所以客户端必须先把域名解析成 IP 才能比对。这意味着：

• 产生额外的 DNS 查询，增加延迟
• 如果 DNS 被污染，解析出的 IP 是错的，归属判断也就跟着错

把常用域名用 DOMAIN-SUFFIX 提前拦住，能让大部分流量根本走不到 GEOIP 这一步。

MATCH 必须是最后一条

MATCH 匹配一切，所以它后面的任何规则都永远不会执行。如果你在 MATCH 之后还写了规则，那部分配置是死的。

反过来，不写 MATCH 也有问题：未命中的流量走什么策略取决于客户端的默认行为，不同客户端不一致，表现为「大部分网站正常，个别网站莫名其妙不走代理」。这类问题特别难查，因为它只影响那些没被任何规则覆盖的冷门域名。

怎么验证某个域名到底命中了哪条

肉眼从上往下推演几十条规则很容易出错。把规则和目标域名粘进规则匹配测试器，它会按 Clash 的顺序逐条比对，显示每条是命中、不命中还是判断不了，并在命中处停下。

有一点它会诚实告诉你：GEOIP、RULE-SET、GEOSITE 这几类规则在浏览器里判断不了——它们需要 IP 归属数据库或远程规则集文件，本地拿不到。如果这类规则排在命中之前，工具会明确标注「结论不确定」，而不是假装算出了答案。这不是能力不足，是这类判断确实需要工具没有的数据，猜一个结果比不给结果更糟。

如果你是想生成一套顺序正确的规则，规则生成器会按上面的原则自动排序——你勾选的顺序无所谓，它一律按正确顺序输出。

一个容易忽略的细节

规则里的策略名必须真实存在。DOMAIN-SUFFIX,google.com,节点选择 里的「节点选择」必须是某个策略组的 name、某个节点的 name，或者 DIRECT / REJECT 这类内置策略。写错了 Clash 会拒绝启动。

改订阅后节点名批量变化时，这类错误会成片出现。用配置校验器可以一次把所有对不上的引用列出来。

小结

• 命中即停，所以宽泛的规则放前面会让后面的规则失效
• 顺序原则：局域网 → 拦截 → 具体域名 → 批量域名 → GEOIP → MATCH
• GEOIP 会触发 DNS 解析，DNS 被污染时判断也会错
• 不确定就用工具逐条追踪，别靠肉眼推演