Shadowrocket 分流规则怎么写:匹配顺序、FINAL 兜底与 PROXY/DIRECT/REJECT 策略

一、先确认 Global Routing，再检查规则

规则写进文件，并不等于当前请求一定按该文件分流。Home 用于管理连接与服务条目，Config 用于管理配置文件，Settings 用于应用设置。排查时先确认连接所使用的配置，再查看 Home → Global Routing。本文的规则解释以 Config 姿态为前提，不适用于用 Proxy 或 Direct 临时覆盖分流的情况。

Global Routing 中的 Scene 涉及场景选择，应核对场景当前采用的设置；它不是可以写在 [Rule] 内的规则关键字。为减少变量，初次验证规则时明确切到 Config。Settings → On Demand 控制按条件触发连接的行为，也不负责改变规则的先后顺序。

二、规则语法：条件在前，策略在后

配置文件中的规则位于 [Rule] 段。多数常见规则使用“类型,匹配值,策略”的结构，使用英文半角逗号分隔。下面三行分别展示精确域名、域名后缀与最终策略；示例域名用于说明，不能当作实际业务清单直接照搬。

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

PROXY 不是服务地址，也不是协议名称。Shadowsocks、VMess、VLESS、Trojan、Hysteria2 与 WireGuard 属于连接协议的范畴；规则决定请求使用哪种策略，服务条目再提供实际连接参数。不要把协议名、订阅地址或服务器端口直接填到规则的策略位置。若引用自定义策略组，其名称必须与配置中定义的名称一致。

三、匹配顺序：上方命中后，下方不再补判

规则从上到下依次检查，命中后执行对应策略。它不是“越精确越自动优先”，也不是把所有命中结果合并。上面的示例中，api.example.com 先命中 DOMAIN，因此使用 PROXY；img.example.com 不满足第一行，随后命中 DOMAIN-SUFFIX，因此使用 DIRECT。

1. 先放精确例外。单独处理的完整域名可以放在宽泛后缀前，例如把 DOMAIN,api.example.com,PROXY 放在 DOMAIN-SUFFIX,example.com,DIRECT 之前。
2. 再放范围规则。DOMAIN-SUFFIX 同时覆盖指定域名本身及其子域名。example.com 会覆盖 example.com 与 a.example.com，但不是任意包含这段文字的域名。
3. 谨慎放置拒绝规则。若先写 DOMAIN-SUFFIX,example.com,REJECT，后面针对 api.example.com 的放行规则便没有机会执行。
4. 最后放 FINAL。当前面的条件均未命中时，再进入最终策略；FINAL 后面的规则无法承担正常的后续匹配工作。

将前两行交换，就会得到不同结果。下面的写法会使 api.example.com 先命中第一行并直接连接；第二行虽然更精确，仍不会推翻已经得到的结果。

[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
DOMAIN,api.example.com,PROXY
FINAL,PROXY

四、FINAL 兜底与 IP 规则怎样配合

FINAL 不带域名或网段参数，正确结构是 FINAL,策略，例如 FINAL,PROXY 或 FINAL,DIRECT。它不是失败重试机制：某条 PROXY 规则已经命中但连接失败，不会因此继续向下找到 FINAL 改走 DIRECT。兜底针对的是“没有匹配条件命中”，不是“连接没有成功”。

no-resolve 用于避免为了匹配这条 IP 规则而额外发起域名解析。它不等于关闭整个应用的 DNS，也不会让域名自动变成 IP。若请求本身已经携带可用目标 IP，仍可按该 IP 检查；若只有域名且尚无可用 IP，就不能把这条规则当作必然命中的条件。

GEOIP 的结果受目标 IP 与本地数据库影响，同一域名使用不同解析结果时，命中的地域条件也可能不同。对必须采用固定策略的少数业务域名，优先写明确的 DOMAIN 或 DOMAIN-SUFFIX 例外，再安排 GEOIP 等较宽条件。不要把“解析成功”“匹配规则”和“建立连接成功”当作同一件事。

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

上面的片段展示一种排列顺序，不是完整配置，也不是适用于所有网络的推荐清单。采用前应确认局域网网段、目标域名与最终策略都符合自己的需要。若目标实际使用 IPv6，仅有一条 IPv4 的 IP-CIDR 规则不能覆盖对应 IPv6 地址，需要另行检查相关规则与网络条件。

五、保存后怎样验证命中结果

验证的单位应是一条新建连接，而不是一个已经打开的页面。浏览器可能复用旧连接，网页也可能直接显示缓存；只看页面是否仍能打开，无法判断刚才的规则是否生效。修改前先保存一份原配置，测试过程中每次只改变一个条件或一个策略。

1. 确认配置

   进入 Config，确认当前选用的文件。编辑该文件的 [Rule] 段并保存，不要只修改另一份未启用的副本。

2. 固定姿态

   回到 Home → Global Routing → Config，确认选择的是 Config，而不是 Proxy、Direct 或尚未核对的 Scene。

3. 重建连接

   让配置重新生效后重新发起目标请求，必要时断开并重新连接。关闭测试页面的旧连接，避免把连接复用误判成新规则失效。

4. 核对记录

   查看请求记录中实际出现的目标域名或 IP，以及匹配规则和所用策略。若页面涉及多个域名，逐项区分主文档、登录接口与资源请求。

5. 恢复测试项

   记录原规则、改动内容和结果，恢复临时添加的拒绝或例外规则。不要把测试用的 REJECT 留在需要正常访问的业务域名上。

例如，已获授权的测试域名设置为 REJECT 后，新的目标请求应呈现被拒绝的结果；但页面上的旧文字仍可能来自缓存，其他域名加载的图片也可能继续显示。这是验证思路，不是本站实测数据。判断时应以对应请求的记录为依据，而不是要求整张网页立刻变成空白。

六、规则分流常见问题

整理配置时，先保证少量规则可以解释每一次测试结果，再逐步增加范围。对每条新增规则，应能回答三个问题：它匹配什么、它之前是否已有覆盖条件、命中后使用什么策略。只要这三点清楚，FINAL 就只是末尾的一项明确选择，而不是掩盖前面规则错误的补丁。