为特定网站编写分流规则

需求通常很具体。某个国内站被订阅里的规则送去了代理，登录老是要验证码；或者某个工具站直连打不开，你想单独把它拎出来走节点。这两件事都不用换订阅、不用改策略组，一行就够。

规则从上往下读，第一条命中就停

内核收到一个请求，会按 rules 列表的顺序逐条比对，命中哪条就把连接交给那条指定的目标，然后立刻停止，后面的一律不看。所以规则表不是一堆条件的集合，是一条有先后的流水线。想明白这点，你面对一条新规则时关心的东西会从「写得对不对」变成「它头上压着谁」。

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - DOMAIN-KEYWORD,steamcommunity,PROXY
  - DOMAIN,ocsp.apple.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - PROCESS-NAME,Telegram.exe,PROXY
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,PROXY

真正会用到的几种规则类型

• DOMAIN：完全匹配。DOMAIN,example.com 只管 example.com 这一个名字，www.example.com 是另一个名字，不命中。
• DOMAIN-SUFFIX：这个域名连同它所有子域。最常用的一种，一行就把 api、cdn、img 这些前缀全收进来。
• DOMAIN-KEYWORD：域名里含有某段字符串就算命中。方便，也最容易误伤——写 google 会顺手把一堆和你无关的主机也拖进来。
• IP-CIDR 与 IP-CIDR6：按地址段匹配。用来处理内网地址，以及那些压根不带域名的连接。
• GEOIP：按 IP 归属的国家匹配，判断依据是本地那份 GeoIP 数据库。
• PROCESS-NAME：按发起连接的程序匹配，和对面是谁完全无关。
• DST-PORT：按目标端口匹配，适合把 SMTP 或者某个游戏用的端口单独安排。

每行最后那一段是目标：可以是策略组的名字，必须和 proxy-groups 里写的一模一样，多一个空格、少一个 emoji 都会让配置加载失败；也可以直接写 DIRECT 或 REJECT。IP 类规则后面还能再挂一个 no-resolve。不加它的话，一个带域名的请求得先解析出 IP 才有东西可比，代价是双份的：多等一次查询，而且你本想避开的那次解析照样发了出去。

位置错了，等于没写

最常见的失败长这样：规则加在列表末尾、MATCH 上面，看着整齐，实际永远轮不到。订阅生成的规则表里，前面通常已经排着几十上百条 geosite 规则和一条 GEOIP,CN,DIRECT，你要处理的那个域名早被其中某条领走了。自定义规则的位置应该在所有可能抢先命中它的规则之前，落到实处基本就是整个 rules 的最前面。想知道是谁抢的，去连接页点开那条连接，客户端会显示它命中了哪条规则。

一个站到底要加哪些域名

1. 打开客户端的连接页，把已有连接清空，让列表安静下来。
2. 在浏览器里访问目标站，正常操作一遍：登录、翻页、点开图片、让视频跑两秒。
3. 回到连接页，看这几秒里冒出来的主机名。一个页面通常牵扯三类域名——主域、放静态资源的 CDN 域、后端 API 域，后两者经常是完全不相干的名字。
4. 只加主域是最常见的半成品：页面能开，图片一直转圈，或者登录接口超时。三类都覆盖到，这条规则才算写完。

按程序名分流

PROCESS-NAME 匹配的是发起连接的可执行文件，适合「这个软件不管连哪都走代理」这种需求。两个平台写法不同：Windows 上带扩展名，比如 Telegram.exe；macOS 和 Linux 上写可执行文件本身的名字，不带后缀。另外内核得先看得见进程信息才谈得上匹配，某些平台上这要求客户端跑在足够的权限下，或者需要在设置里开对应的开关。拿不到进程名时这条规则不会报错，只是安静地永远不命中。

改完之后

保存后让内核重新加载配置——客户端一般在配置页上有重载按钮，把这份配置切走再切回来也一样。接着是很多人栽的一步：已经建立的连接不会改道。TCP 连接走哪条路在握手那一刻就定死了，之后你改规则它收不到。浏览器还在复用之前的 keep-alive 连接，你刷十次看到的都是老路径。测试前先去连接页把相关连接断掉，顽固的就关掉标签页重开。