· 规则分流 · 约 10 分钟

Shadowrocket 自定义规则写法:从上到下匹配、FINAL 兜底与 PROXY/DIRECT/REJECT 策略

先讲规则的匹配机制:从上到下逐条比对,命中即停,FINAL 负责兜底。再说明 PROXY、DIRECT、REJECT 三种策略的区别,并用 DOMAIN-SUFFIX、IP-CIDR 示例演示调整规则顺序的效果。

本文速览

在 Shadowrocket（小火箭）中，自定义规则是否生效，先看 Global Routing，再看当前配置文件，最后看规则顺序。本文面向已有自己的服务与连接配置的用户，用保留域名和文档示例网段说明规则写法、兜底策略与验证方法。示例只用于理解语法，不是可直接替换日常配置的完整方案。

先核对 Global Routing，再修改规则

修改规则前，在 Home → Global Routing 核对当前选项。要让当前配置文件中的规则参与分流，应使用 Config。若停在 Proxy 或 Direct，继续调整规则顺序通常不能解决预期的分流问题，因为这两种姿态不是按当前文件的规则逐条决定出口。

Config

推荐

按当前生效配置的规则选择策略。是否直连、代理或拒绝，由命中的规则决定，并不等于“未命中就直连”。

适合:编写、验证与日常使用自定义规则

Proxy

对交由应用处理的连接采用全局代理姿态。可用于对照代理连接是否可用，但不能拿这一姿态下的结果证明某条规则已经命中。

适合:临时对照代理路径与规则路径

Direct

对交由应用处理的连接采用直连姿态。Direct 不是关闭系统 VPN 配置的同义词，也不是删除当前配置文件。

适合:对照目标在当前网络下的直接连接结果

Global Routing 中还可能使用 Scene；它涉及场景选择，排查本文示例时先明确切换到 Config，避免把场景变化与规则变化混在一起。还要区分两个同名词：Global Routing 的 Config 是运行姿态，底部 Config 是管理配置文件的位置。文件存在于列表里，不代表它就是当前正在使用的文件。

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

配置文件的规则写在 [Rule] 段内。常见的条件规则由“类型、匹配值、策略”组成，字段用英文逗号分隔。中文逗号、误加空格的策略名称、把规则写进其他段落，都可能导致解析或匹配不符合预期。以下四种关键字需要分清：

关键字示例核对重点
DOMAIN-SUFFIXDOMAIN-SUFFIX,example.com,PROXY匹配 example.com 本身及其子域名，不填写 URL 路径。
IP-CIDRIP-CIDR,192.0.2.0/24,DIRECT匹配 IPv4 网段；/24 表示前 24 位为网络前缀。
GEOIPGEOIP,CN,DIRECT按目标 IP 的地理数据库归属判断，不是按域名文字判断。
FINALFINAL,PROXY没有匹配值字段，用于前面条件均未命中的兜底。

DOMAIN-SUFFIX,example.com,PROXY 可以匹配 api.example.com，但不会因为另一域名的字符串末尾恰好出现“example.com”就自动匹配；这里有域名层级边界。不要填写 https://example.com/path，也不要在匹配值中附加 :443。这条规则按域名匹配，不按网页路径或端口匹配。

IP-CIDR 与 GEOIP 依赖可用的目标 IP 信息。域名连接是否触发解析、何时进行 IP 判断，还受配置中的 DNS 与规则选项影响。不要把 GEOIP 结果当成网站经营者所在地，也不要期待一个域名永远解析到同一网段。

4 种
本文规则关键字：DOMAIN-SUFFIX / IP-CIDR / GEOIP / FINAL
3 种
本文目标策略：PROXY / DIRECT / REJECT
256 个
192.0.2.0/24 包含的 IPv4 地址数量

从上到下匹配：更具体的例外放前面

规则按顺序逐条判断，命中后使用该条策略，不再继续寻找“更合适”的后续规则。系统不会自动把更长的域名后缀或更小的网段提到前面。因此，应先写明确例外，再写覆盖范围较大的条件，最后放兜底。

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

在这个例子中，api.example.com 及其子域名先命中第一条而直连，www.example.com 则命中第二条。若交换前两条，api.example.com 已经满足较宽的 example.com 条件，便会先走 PROXY；下方的 DIRECT 例外没有机会参与这次判断。

IP 网段也遵守相同的顺序

[Rule]
IP-CIDR,192.0.2.128/25,REJECT,no-resolve
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXY

192.0.2.128/25 包含在 192.0.2.0/24 之内。对目标 IP 已知的连接，192.0.2.130 先命中 REJECT，而 192.0.2.20 会继续向下命中 DIRECT。交换这两条，较大的 /24 就会先覆盖整个范围，原本的拒绝例外随之失效。

PROXY、DIRECT、REJECT 与 FINAL 的关系

前三个词回答“命中后怎样处理”，FINAL 回答“前面都没命中怎么办”。它们并不是四种同级匹配条件。尤其要注意，FINAL,PROXY 本身不包含域名或地区判断，放得过早就会截住后面的规则。

如果只希望列出的域名走代理，其余直连，可以在完整检查规则后使用 FINAL,DIRECT；如果希望未列出的目标继续走代理，则使用 FINAL,PROXY。两者不存在脱离需求的统一答案。修改 FINAL 会改变所有前面未命中连接的去向，影响范围往往比添加一条域名规则更大。

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

此处先拒绝特定子域名，再让其余 example.com 域名走代理，其他目标直连。它只展示三种处理结果如何组合，不是完整的隐私或网络访问方案。复制到自己的配置前，应保留已有必要规则，并核对代理策略引用是否与当前配置一致。

修改与验证：一次只改一个变量

不要直接覆盖仍在使用的配置。先保留原文件，再编辑副本；若文件来自远程更新，还要考虑后续更新可能覆盖本地修改。操作顺序如下，界面里的文件名以你实际保存的名称为准：

  1. 确认姿态

    打开 Home → Global Routing → Config，记下当前所选代理。先不同时修改 DNS、代理选择或 On Demand。

  2. 保留原文件

    进入底部 Config，核对当前生效文件，在编辑前通过文件操作保留副本或导出备份，避免失去可恢复的基线。

  3. 修改规则

    在 Config 中打开待修改文件的编辑界面，定位 [Rule] 段。只新增一条例外或交换两条规则，保留末尾 FINAL，保存后确认使用的是修改后的文件。

  4. 重新发起请求

    回到 Home 确认连接状态，结束目标应用中的旧请求，再发起新连接。已有长连接不会因为改了文本就自动变成另一条新连接。

  5. 核对连接记录

    在 Data 查看对应时间的连接记录，结合目标域名或 IP、匹配规则与实际策略判断。记录测试目标和改动前后的结果，不只看网页能否打开。

例如验证域名例外时，应分别检查一个例外子域名与一个普通子域名；验证 FINAL 时，应选择明确不属于前面条件的目标。若使用自有测试服务，HTTPS 常见端口是 443，HTTP 常见端口是 80；本文的域名后缀规则本身并不按这两个端口区分流量。

无法访问并不能单独证明规则失败：命中 PROXY 后代理路径不可用，命中 DIRECT 后本地网络不可达，或命中 REJECT 后请求被拒绝，都可能呈现类似的页面错误。验证顺序应是“是否命中预期条件 → 是否采用预期策略 → 该路径是否可达”，不要反过来根据页面结果猜规则。

常见问题：规则写了，为什么结果没变？

改了规则，怎么所有目标还是走代理？

先到 Home → Global Routing 核对是否选了 Proxy，再到 Config 确认当前生效文件。若已经使用 Config，就从第一条规则向下检查是否有过宽的条件提前命中，或 FINAL 被放在例外规则上方。

DIRECT 放在下面，为什么没有覆盖前面的 PROXY？

规则不是后写覆盖前写。把更具体的 DIRECT 条件移到覆盖它的 PROXY 条件前面，保存并重新发起连接；同时确认你修改的是规则顺序，而不是只改了列表中的显示名称。

加了 IP-CIDR，域名访问却没命中？

检查实际目标 IP 是否落在网段内，并检查是否使用了 no-resolve。域名可能返回多个地址，也可能使用 IPv6；IPv4 的 IP-CIDR 示例不能覆盖 IPv6。若需求本来就是按域名分流，优先用明确的域名条件表达。

更新后自己添加的规则不见了，怎么办？

先在 Config 核对更新的是远程配置文件还是其他项目，再与备份比较。订阅中的服务器列表与配置文件的规则不是同一层数据。保留独立的本地修改副本，恢复后重新确认生效文件，避免反复改到会被远程内容覆盖的文件。

为什么连接关掉后又自动打开？

到 Settings → On Demand 核对按需连接条件。On Demand 管理何时建立连接，不负责替代 [Rule] 的逐条匹配；先固定连接状态，再检查 Global Routing 与规则，避免同时排查两层不同的行为。

最终保留一份能说明目的的最小改动：例外在前，宽泛条件在后，FINAL 在末尾；每次验证都记录当前姿态、生效文件、目标与命中策略。规则数量增加并不自动提高准确性，能解释每条规则覆盖什么、为什么排在这里，才便于后续维护。更多界面与连接概念可查阅术语手册；持续异常时按故障排查逐项核对。

App Store 正版核对 →