分流规则：决定每个连接走哪条路

规则的"思维模型"：把它当成一份决策表

与其把规则当成一堆难懂的语句，不如把它想成一份决策表：每一行是一个"如果……那么……"。如果域名属于某个类别，就走某个策略；如果 IP 在某个段内，就走某个策略；如果以上都不是，就走兜底策略。决策表的特点是：从上到下判断，一旦命中就结束。所以你在设计规则时，要问自己三个问题：最特殊的例外是什么（放最前）？最大的类别是什么（放中间）？没被覆盖的情况怎么办（放最后）？

用这个模型去审视一份订阅里的规则，你会发现大多数订阅的规则结构大同小异，差别主要在规则集的来源与更新是否及时。

常见的规则类型

一份最小的规则示例

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

这份示例的意思是：example.com 直连；局域网段直连；目标 IP 在国内的直连；其余全部走 Proxy 策略组。

no-resolve 是什么

IP 类规则默认会让客户端先解析域名拿到 IP 再匹配。给规则加上 no-resolve，表示"遇到域名请求时不要为了匹配这条规则去解析"，可以避免不必要的 DNS 查询，也能减少 DNS 污染的影响。

规则写错的典型表现

• MATCH 写在中间：它后面的所有规则都不会生效。
• GEOIP 放在域名规则前面：会让本该按域名命中的连接先被 IP 判断截走。
• 规则集没更新：新域名没被收录，访问行为与预期不一致。
• 策略名拼写与策略组不一致：客户端会报错或回退。

如果你想在图形界面里改规则，可以直接看 Clash Verge 规则设置。

一份分层的规则，应该怎样排顺序

把规则想成一道层层过滤的筛子：越具体、越确定的放得越靠前，越宽泛、越兜底的放得越靠后。一个常见的分层思路是：先放需要拦截的（比如广告域名，策略写 REJECT），再放局域网和私有地址的直连，然后是你个人需要特殊处理的域名，接着是大块的规则集，最后才是 GEOIP 和 MATCH。顺序里最容易出错的是把 GEOIP 放得太靠前：它是按目标 IP 的地区判断，会把本该按域名命中的连接提前截走。

rules:
  - RULE-SET,ads,REJECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN-SUFFIX,example.com,DIRECT
  - RULE-SET,proxy-domains,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

规则集的三种 behavior

远程规则集（rule-providers）需要声明 behavior，也就是这个规则集里的条目是什么类型。填错类型，规则集会加载失败或者根本不生效。

GEOSITE 与 GEOIP 有什么区别

GEOIP 按"IP 属于哪个地区"判断，GEOSITE 按"域名属于哪个站点分类"判断。前者依赖 IP 数据库，只有在客户端已经拿到目标 IP 时才能匹配；后者直接基于域名，不需要先解析。所以在需要分流域名的场景里，优先使用 GEOSITE 或域名规则，把 GEOIP 留给"按地区兜底"这类场景，并且给它加上 no-resolve 以避免多余的解析。两者都依赖本地的数据文件，文件过旧会让分流结果和现实不符，需要定期更新。

怎么调试一条规则有没有生效

1. 先访问目标网站，让客户端产生连接记录。
2. 在连接页面找到这条连接，看它命中的规则和使用的策略。
3. 如果没命中预期规则，往上检查是否有更靠前的规则抢先命中。
4. 修改规则后，关闭已有连接，再重新访问，避免旧连接影响判断。

规则变更的"安全流程"

1. 修改之前备份。
2. 一次只改一处。
3. 改完立刻在连接页面验证。
4. 确认无误后，再改下一处。