Shadowrocket 自定义规则写法:匹配顺序、FINAL 兜底与 PROXY/DIRECT/REJECT

本文速览

本文适合已经在 Shadowrocket 中导入自己已有的订阅、准备修改 Config 的用户。先确认 Global Routing 使用 Config，再区分规则条件和执行策略；通过可核对的规则片段，理解精确域名、域名后缀、IP 网段与 FINAL 的排列方式，最后用单变量测试定位“不命中”和“命中后仍失败”这两类不同问题。

先核对 Global Routing，再修改 Config

Shadowrocket 的 Home 用于连接与选择已有服务，Config 用于管理配置文件，Settings 用于应用设置。订阅条目提供可用的连接参数，并不等于当前配置文件中的规则。只更新已有订阅，不代表你编辑的规则已经被启用；只保存一个配置文件，也不代表 Home 当前采用它进行分流。

检查入口是 Home → Global Routing。本文讨论的是 Config 姿态下的规则判定，不是把 Proxy 或 Direct 当成一条规则。Global Routing 中还可见 Scene，它涉及场景选择；排查本文的静态规则时，先明确切换到 Config，避免场景变化引入额外变量。

Config

Proxy

以代理姿态处理流量，而不是按本文的自定义规则逐条选择 DIRECT 或 REJECT。它可作为排查代理连接是否可用的对照条件。

适合:临时隔离规则分流因素

Direct

以直连姿态处理流量。若停留在这里，不能用访问结果判断 Config 中某条 PROXY 规则是否有效。

适合:核对本地网络直接访问的表现

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

常见规则使用英文逗号分隔字段，写入配置的 [Rule] 段。域名规则通常是“类型、匹配内容、策略”；FINAL 没有匹配内容字段，直接写“FINAL、策略”。不要把中文逗号或说明性文字粘进规则行，也不要在同一个文件中为了追加几条规则而重复建立多个 [Rule] 段。

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
FINAL,PROXY

这里的 example.com 是文档示例域名，192.168.50.0/24 是私有网段示例，不代表你的网络实际使用该网段。这段内容用于说明字段结构和顺序，不是建议覆盖现有配置的通用规则集。

关键字	示例条件	核对要点
`DOMAIN`	`api.example.com`	匹配完整域名；不把其他子域名一起纳入。
`DOMAIN-SUFFIX`	`example.com`	匹配该域名及其子域名，不需要写通配符星号。
`IP-CIDR`	`192.168.50.0/24`	匹配目标 IPv4 地址所在网段，不按域名文字匹配。
`GEOIP`	`CN`	按目标 IP 在地理数据库中的归属判定，不依据网页内容判定。
`FINAL`	无条件字段	承接前面都未命中的请求，必须放在规则列表末尾。

DOMAIN-SUFFIX 匹配的是域名边界，不是任意字符串包含。例如 example.com 可以覆盖 www.example.com，但不应被理解为覆盖 notexample.com。规则中也不填写 https://、页面路径或查询参数；这些不是域名字段的一部分。

匹配顺序：先写例外，再写大范围

规则不是“后写的覆盖先写的”，也不会自动把最长或最精确的条目优先排序。对一次需要规则判定的请求，Shadowrocket 从上到下检查，首条命中后采用其策略。因此，精确例外必须放在能覆盖它的大范围规则之前。

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

api.example.com：第一行域名规则已命中，采用 PROXY，不再由后面的后缀规则改为 DIRECT。
www.example.com：未命中第一条，命中第二条，采用 DIRECT。
其他目标：继续检查 GEOIP；不满足该条件时，最终采用 FINAL 的 PROXY。

如果把 DOMAIN-SUFFIX 放到 DOMAIN 前面，api.example.com 会先命中后缀规则，后面的精确例外就没有机会执行。同理，把一个广泛覆盖目标的规则集放在本地例外之前，也可能让本地例外失效。排查时必须连同前面的规则一起看，不能只确认目标条目“存在”。

1 条

一次规则判定采用首条命中结果

3 种

本文基础策略：PROXY / DIRECT / REJECT

/32

IPv4 CIDR 中表示单个地址的前缀长度

PROXY、DIRECT、REJECT 与 FINAL 的职责

规则类型回答“匹配什么”，策略回答“匹配后怎样处理”。PROXY、DIRECT、REJECT 是这里使用的策略；FINAL 则是没有额外匹配条件的兜底规则类型。把这两组概念分开，就不会把 FINAL 误当成一种新的传输协议。

PROXY: 将匹配请求交给代理路径处理。具体连接目标还要核对当前选择及配置中的策略关系；写上 PROXY 不会自动产生可用服务，也不能修复错误的认证参数。
DIRECT: 由当前网络直接访问目标，而不是交给代理路径。直连仍依赖本地网络、DNS 与目标服务本身的可达性，不等于跳过所有网络限制。
REJECT: 拒绝匹配请求。适合对明确不需要的目标作阻断测试；范围过大时可能同时影响登录、图片或应用接口，必须保留撤销方法。

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

这个例子先拒绝 blocked.example.com，再让同一后缀下的其他域名直连，剩余请求交给 PROXY。若把 FINAL 提到第一行，所有需要走到这段规则的请求都会先被它接住，后面的域名规则便无法参与判定。

IP-CIDR、GEOIP 与 DNS：分清地址从哪里来

域名条件与 IP 条件使用的信息不同。DOMAIN-SUFFIX 关注域名，而 IP-CIDR 和 GEOIP 关注目标地址。对一个只有域名、尚无可用目标 IP 的请求，IP 类规则可能涉及 DNS 解析；不能把域名规则没有命中，直接归因于网段写错。

IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
IP-CIDR,192.168.50.10/32,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

上面两条 IP-CIDR 有意展示网段与单地址的区别：第一条已经覆盖 192.168.50.10，若策略相同，第二条通常没有必要保留。若要对该单地址设置不同策略，应把 /32 例外移到 /24 规则之前，而不是追加在后面。

no-resolve 表示不要仅为了这条 IP 规则额外触发域名解析；它不等于禁用整个应用的 DNS，也不表示请求从此没有目标 IP。
如果请求已经具有可用目标 IP，仍可用该地址判断网段。若尚无地址且规则不触发解析，则不能指望这条规则凭域名完成 IP 匹配。
GEOIP,CN,DIRECT 依据 IP 地理归属数据库。CDN 调度、DNS 答案与数据库归属会影响判定，中文页面并不是命中条件。
访问域名时还要注意 IPv6。IPv4 的 IP-CIDR 条目不会自动覆盖 IPv6 地址；发现目标使用 IPv6 时，应另外检查适用的 IPv6 规则。

规则只能使用实际可获得的请求信息。如果应用直接连接 IP，且没有可关联的域名信息，域名规则未必能够命中。排查时记录实际目标域名或地址，比继续叠加宽泛的 DOMAIN-SUFFIX 更有帮助。

修改与验证：一次只改变一个条件

先保留当前可用配置，再做小范围修改。远程配置与本地副本要区分清楚：远程内容更新可能替换本地改动；已有订阅更新通常处理连接条目，不能拿更新成功作为自定义规则已生效的证据。测试前也应确认已有代理连接本身可用。

保留原文件

进入 Config，确认当前使用的配置，保留一份可恢复的副本。若要修改远程来源的内容，先使用可编辑的本地副本，避免下一次更新覆盖测试规则。
编辑规则段

在 Config 中打开待测试文件的编辑内容，找到 [Rule]。把单个精确域名例外放到对应后缀规则之前，确认 FINAL 仍在末尾，保存后选用该配置。
确认分流

回到 Home → Global Routing → Config。核对当前代理选择，不要让 Proxy、Direct 或 Scene 的其他行为混入这次规则测试。
重建请求

关闭目标页面后重新打开，必要时重新建立连接，以减少已有长连接复用带来的干扰。每轮只修改一条规则的顺序或策略，不同时更换 DNS 与代理参数。
记录并恢复

记录目标、命中规则、采用策略与访问现象。结合当前可用的请求记录核对；若结果不符合预期，恢复原配置，再按同一目标复测。

测试记录应区分“实际观察”和“预期行为”。例如，临时把自己控制的测试域名设为 REJECT，预期是相关请求被拒绝；若页面仍有内容，先排除缓存、其他域名和已建立连接，而不是据此断言整个规则系统失效。本文规则片段不代表已在你的网络中取得任何测试结果。

常见问题：从命中结果定位原因

加了 DOMAIN 还是走 DIRECT，哪里写错了？

先在 Home → Global Routing 确认 Config，再到 Config 确认实际选用的文件。随后向上检查是否有更早的 DOMAIN-SUFFIX、IP 类规则或规则集先命中；把精确例外放到覆盖它的规则之前，保存并重新发起请求。

FINAL 写 PROXY，为什么部分请求仍然直连？

FINAL 只接收未命中前序规则的请求。先查目标是否已经命中 DIRECT 条目，例如 DOMAIN-SUFFIX 或 GEOIP；不要把 FINAL 移到最前面。应修改真正命中的条目，或在它前面增加范围更小的例外。

命中了 PROXY 但打不开，还要调整顺序吗？

命中结果已经是 PROXY 时，优先核对当前代理、认证信息、目标端口与 DNS。可临时用 Home → Global Routing → Proxy 作对照；测试结束恢复 Config。策略执行失败与规则未命中是两条排查路径。

一条 REJECT 导致整个应用异常，怎么恢复？

在 Config 中删除刚添加的条目，或恢复备份并重新建立连接。随后根据实际请求域名缩小匹配范围，优先使用 DOMAIN 验证单一目标；不要直接把共享后缀或宽泛网段整体拒绝。

最终核对顺序应保持稳定：当前配置是否正确、Global Routing 是否为 Config、第一条实际命中规则是什么、该策略能否执行。先完成这四项，再考虑扩大规则范围。这样可以保留明确的回退点，也能避免用大量重复规则掩盖配置选择或连接参数的问题。