为什么「写了 rule 却像没用」：先改观察方式

许多用户搜索「分流不走代理」或「rule 写了没用」时，默认是「这条规则被忽略了」。在 Clash／Mihomo 系里，更准确的说法是：它被别的规则抢先匹配了。内核不会对同一条连接试遍你文件里所有 rule 再择优；而是自上而下找到第一条能够满足匹配条件的规则，然后选用其指向的策略或策略组。

因此，若在实时连接或日志里看到的是 DIRECT／某个「国外」组，而自认为某条 DOMAIN 应命中，第一件事不是再堆一条重复规则，而是：查清这条连接当时被哪条规则冠名。可读 Clash 连接失败与日志排障 中与「策略名、规则类型」相关的读法，先把观察口径对齐。

另一点常见误会，是把策略组里选中的节点与规则匹配的走向混为一谈：规则只决定「进入哪条策略组／DIRECT」；若组内是 url-test 自动选边，「走错节点」有时是测速与组内逻辑问题，需在 策略组与延迟测速 侧单独验证，而不是只在 rules: 段里打转。

从上到下：谁先匹配谁说了算

规则顺序在工程上等价于优先级：写在前面的 RULESET、DOMAIN-KEYWORD、IP-CIDR、GEOIP……都会「截胡」后面的条目。社区模板里常把「局域网／国内直连／广告拦截」放在前半段，再把「漏网之鱼」留给末行，正是这个语义。

若你从公共订阅套壳，又手工在文件底部追加了几条 DOMAIN，却忘了前面某条 RULESET 已经覆盖同一后缀，就会出现你永远看不到自己新规则生效的现象。处理办法只有两类：要么上移你的细规则、要么收紧／拆分挡在前面的 Rule Provider。总原则与拆分技巧可对照 规则分流最佳实践 中的分层写法，避免一条过宽的集合长期挡路。

ℹ 和 TUN／系统代理无关的「顺序」：内核只认配置里拼好的 rules 列表；开不开 TUN 模式 不会改变「谁先匹配」——只会改变哪些流量会进内核。若部分应用仍绕开 Clash，应先确认模式与客户端选型，可参见 Clash 客户端选型 ，再谈 rule 顺序。

MATCH 要不要写最后？兜底与策略组

在 Clash 系配置里，常见的兜底写法是末行 MATCH,<策略组或 DIRECT>（有的模板也写 MATCH 等价的「全量捕获」语义）。它的作用很单纯：前面所有规则都没命中时，才把流量交给这一条。若你把 MATCH 放在中间，那它下面的规则在常规路径下形同虚设——除非你使用非常规合并／覆写插件把两段 rules 拆开（一般用户不会）。

实务上更值得检查的是：MATCH 指向的是哪个策略组。若兜底指向代理组而你在日志里却总看到 DIRECT，通常不是 MATCH「没写」，而是在前面已经被 GEOIP-CN、RULESET-direct 或其他直连规则吃掉。反过来，若你希望「剩余流量全直连」却把 MATCH 指到全局代理组，也会产生「分流不走代理」的反向错觉——实际是MATCH 根本不需要走到。 

规则列表示意（从上到下阅读；具体字段名依内核而定）rules:
  - RULE-SET,google,PROXY
  - DOMAIN-SUFFIX,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,FALLBACK_GRP

上例中：MATCH,FALLBACK_GRP 只承接前三类都未命中的连接；一旦你发现某海外站直连，要在日志里看它是被 RULESET、GEOIP 还是手写 IP-CIDR 接住，再把那条规则上移或改写。

GEOIP、IP-CIDR 与域名类规则的先后

GEOIP 与 IP-CIDR 工作在「已知目标 IP」这一层：GEOIP 依赖离线库把 IP 归到国家／地区；IP-CIDR 则按前缀硬匹配。若连接在规则匹配阶段先有可用 IP（例如你已拿到真实远端地址），这些规则会与域名类共同参与自上而下比较——谁写在前面谁先赢。

典型翻车场景：IP-CIDR,10.0.0.0/8,DIRECT 或「RFC1918 私网直连」一整段放得过早，CDN 回填的某一跳落在保留段观感里，看起来像「规则写了没用」。又如 GEOIP,CN,DIRECT 紧跟在宽松的「全球兜底代理」前面时，会因 IP 库里对 Anycast 的标注，把本应走代理的出口站误判成 CN 直连。GEOIP 误判有时是库旧了，有时是顺序与 CDN 拓扑共同导致——数据侧可参考 更新 mmdb 与 GeoSite 专文做替换与核验；顺序侧则需把「更确定」的域名／规则集放在「更宽」的 GEOIP 之前。

误判从哪来：DNS、Fake-IP、嗅探与 mmdb

在开启 Fake-IP 时，应用侧先拿到的是内核分配的虚拟地址，真正向外建连时才会解析或嗅探出目标 IP。若此时规则阶段仍按「仅 IP」去跑 GEOIP／IP-CIDR，而域名维度的细规则又排在后面，你会在日志里看到先被 IP 类规则带走，表现为「域名 rule 像失效」。缓解思路包括：为关键域名写更靠前的 DOMAIN／RULESET 命中、或调整 DNS 与 fake-ip-filter 与嗅探（sniffing）相关配置，使「域名信息」在匹配链上更早可见。

另一条线是双解析：系统 DNS 与 Clash 内置 DNS 返回的地址不一致时，你在浏览器里看到的 IP 与内核用于匹配的不一定相同，同样会放大「走错策略组」的感受。把 DNS 段与 rules 段放在一次排障里读，比只改规则更有回报。

可复制的修正顺序（清单）

按下面顺序做，一般能在十分钟内缩小问题面：

  1. 在连接日志里抄下「规则名／类型」：确认到底是哪一条命中，而不是猜。
  2. 全文搜索该目标域名或 IP：看是否被更靠前的 RULESET、GEOIP、IP-CIDR 覆盖。
  3. 检查 MATCH 是否在物理意义上处于末行，且其指向是否符合你对「剩余流量」的预期。
  4. 对 GEOIP 异常：交叉比对 mmdb／geosite 版本与 地理库更新 步骤；必要时把细域名规则前移到 GEOIP 之前做 A/B。
  5. 对 Fake-IP／嗅探敏感业务：回到 DNS 段核对 nameserver 与 filter，避免「IP 先行」抢匹配。
⚠ 合规提示：请仅在你有权管理的网络环境中调试代理与规则；勿将排障技巧用于规避所在组织或地区的网络管理规定。

结语

Clash 规则优先级不是玄学，而是一条单向扫描的列表：rule 从上到下，先赢后止。MATCH 规则负责收尾，应配合你对「其余流量」的真实期望来指向 DIRECT 或对应策略组；GEOIP 与 IP-CIDR 则在你写对顺序的前提下，仍可能因库或 DNS 链条产生分流不走代理或反向误判——数据与顺序要一起查。

把「日志里那条命中的规则名」当作唯一真相来源，再动订阅与 YAML，比反复复制粘贴 DOMAIN 高效得多。需要系统学习写法时仍以 分流最佳实践 为主轴，把本文当作线上排障时的速查单即可。

→ 立即免费下载 Clash，开启流畅上网新体验，用自带连接视图对照「规则类型与策略名」，一眼验证自上而下匹配是否已按你的意图落地。