2026-10-14 · 规则与分流 · 约 8 分钟

Shadowrocket 自定义规则写法与优先级:从上到下匹配与 FINAL 兜底

介绍 DOMAIN-SUFFIX、IP-CIDR 等规则的写法与排列顺序,以及 PROXY、DIRECT、REJECT 策略和 FINAL 兜底规则怎么配合。

本文速览

自定义规则先确认 Global Routing 使用 Config，再按“具体例外在前、宽泛条件在后、FINAL 最后”排列。本文适合已经有自己的服务商与接入信息、需要调整 Shadowrocket（小火箭）分流行为的用户；下面给出可核对的规则语法、编辑步骤与验证方法，不提供任何服务入口。

先确认 Config，再判断规则是否生效

规则内容正确，不代表当前连接正在使用这份规则。排查前先到 Home → Global Routing 查看当前姿态，再到 Config 确认选中的配置文件。本文讨论的是配置文件中 [Rule] 段的顺序匹配，不是服务列表的排列顺序，也不是延迟测试结果的排序。

Config

推荐

使用当前配置的规则决定连接策略。本文的 DOMAIN-SUFFIX、IP-CIDR 与 FINAL 示例都在这个前提下验证。

适合：编写、验证和长期使用自定义分流规则。

Proxy

以代理方式处理连接，不按本文这套配置规则逐条选择策略。临时切换后恢复访问，只能说明需要继续检查分流路径，不能直接证明某条规则写错。

适合：短时间对照代理路径是否可用。

Direct

以直接连接方式处理连接。此时修改配置中的 PROXY 规则，并不是验证规则效果的有效方法。

适合：对照当前网络的直接连接情况。

Global Routing 中还有 Scene，用于按场景设置决定使用方式。若当前选择 Scene，应先核对实际生效的场景；为了让测试条件单一，验证本文示例时可暂时切到 Config，完成后再恢复原来的选择。Settings → On Demand 控制按需连接，不能代替规则对目标连接选择策略。

规则语法：类型、匹配值与策略分别写什么

多数常用规则按“规则类型、匹配值、策略”的顺序书写，字段使用英文逗号分隔。FINAL 是例外：它没有匹配值，因此写成 FINAL,DIRECT 或 FINAL,PROXY。不要把中文逗号、网页地址中的路径或端口一起填进域名匹配值。

规则类型语法示例匹配范围
DOMAINDOMAIN,api.example.com,PROXY只匹配这个完整域名。
DOMAIN-SUFFIXDOMAIN-SUFFIX,example.com,DIRECT匹配 example.com 及其子域名，不匹配 notexample.com。
IP-CIDRIP-CIDR,192.168.0.0/16,DIRECT,no-resolve匹配指定 IPv4 网段；此处覆盖 192.168.0.0 至 192.168.255.255。
GEOIPGEOIP,CN,DIRECT按目标 IP 的地理数据库归属匹配，不按网页语言或域名后缀判断。
FINALFINAL,PROXY前面的规则都未匹配时，采用这里指定的策略。

例如，目标域名是 api.example.com 时，DOMAIN 规则的匹配值只写这个域名，不附加 https://、/login 或 :443。同一域名的 HTTPS 连接常使用 TCP 443，但 DOMAIN-SUFFIX 本身不检查端口；需要区分端口时，不能仅靠改变域名字符串实现。

3 个字段
DOMAIN-SUFFIX：类型、域名后缀、策略。
2 个字段
FINAL：类型与兜底策略，没有匹配值。
256 个地址
IPv4 的 /24 网段包含 256 个地址位置。

no-resolve 是 IP 类规则的可选参数，用于避免仅为匹配该条规则而触发域名解析；它不是关闭整个应用的 DNS。若连接只有域名、尚无可用于匹配的目标 IP，带这个参数的规则可能不会命中。按域名表达的需求，应优先使用域名规则，而不是期待 IP 规则始终覆盖。

从上到下匹配：具体例外放在宽泛规则前

在本文使用的基本规则中，连接按顺序寻找匹配项，命中后执行该条策略。规则不会因为“写得更精确”就自动跳到前面，也不会将多条命中的策略合并。最常见的问题是：前面已经匹配了整个域名后缀，后面的单独子域名例外再也没有机会执行。

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

这是一段说明顺序的 [Rule] 示例，不是包含全部连接参数的完整配置。域名均为演示值；接入参数仍需使用用户已有的信息。若原文件已有 [Rule]，应在原段内编辑，不要再追加一套重复段落。

  • api.example.com 先命中第一条，使用 PROXY；虽然它也符合后面的域名后缀条件，但不会因此改成 DIRECT。
  • blocked.example.com 命中第二条，执行 REJECT；把这一条移动到 DOMAIN-SUFFIX 后面，就失去了这个例外效果。
  • www.example.com 不匹配前两条，命中第三条，使用 DIRECT。
  • 目标为 192.168.1.20 的连接可命中第四条；没有匹配前面条件的其他连接才交给 FINAL。

结论：先移动例外，再增加规则

发现某个子域名没有按预期分流时，先检查它上方是否已有覆盖整个后缀的规则；把具体例外移到宽泛条件之前，比重复添加同一条规则更有效。

同样的原则也适用于 IP 网段。若只想让一个目标 IP 使用不同策略，可把该地址对应的 /32 规则放在覆盖它的 /24 或 /16 规则前。GEOIP 这样的宽泛条件通常放在具体域名和具体网段之后，避免提前接管原本应单独处理的连接。

PROXY、DIRECT、REJECT 与 FINAL 如何配合

规则类型回答“匹配什么”，策略回答“匹配后怎么处理”。PROXY 表示交给代理路径，DIRECT 表示直接连接，REJECT 表示拒绝连接。PROXY 能否完成请求仍取决于当前选用的代理及其连接状态；规则命中不等于远端服务一定可达。

PROXY
把匹配的连接交给代理路径。验证时同时检查 Home 中当前选用的服务，以及它自己的连接是否正常。
DIRECT
由当前网络直接连接目标。它不是“自动选择更快线路”，也不保证当前网络能够访问该目标。
REJECT
拒绝匹配的连接。若写在范围过大的域名后缀或网段规则上，相关页面与资源都可能受影响。
FINAL
未命中前面规则时的最终规则。它本身不是一种代理服务，而是将剩余连接交给指定策略。

FINAL,DIRECT 适用于“只把明确列出的目标交给代理，其余直接连接”的规则设计；FINAL,PROXY 适用于“明确列出的目标直接连接或拒绝，其余交给代理”的设计。两者没有脱离使用需求的统一答案，也不要仅凭某一网站暂时打不开就反复切换兜底策略。

此外，网页可能同时连接多个域名：主页面、图片、登录接口与媒体资源可以各自命中不同规则。给主域名写一条 DIRECT，并不等于页面上的所有连接都采用 DIRECT。应根据实际请求域名补充必要例外，而不是把所有无法识别的目标直接归入 REJECT。

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

动手前先保留当前配置副本，并记下 Home → Global Routing 的原选择。Config 中的订阅配置、远程配置与本地副本要分清：更新服务列表不等于更新规则，远程配置更新也可能覆盖直接在原文件上做的改动。需要长期保留的个人调整，应放在自己可维护的配置副本中，并在每次更新后核对。

  1. 确认姿态

    进入 Home → Global Routing → Config，使本次验证使用配置规则；同时记下当前选中的代理，测试期间不要更换。

  2. 定位文件

    进入 Config，确认当前选中的配置文件。先保留副本，再打开该文件的编辑入口；使用文本编辑时定位到 [Rule]，核对已有 FINAL 的位置。

  3. 插入例外

    把需要测试的 DOMAIN 或 DOMAIN-SUFFIX 放到相关宽泛规则之前，确保位于 FINAL 上方。一次只添加或调整一条，避免同时改动 DNS 与连接参数。

  4. 建立新连接

    保存并确认仍选中这份配置，返回 Home 重新建立连接。关闭目标页面后重新打开，让测试请求建立新连接，不以旧的持续连接作为判断依据。

  5. 核对结果

    查看应用内连接记录，核对实际请求域名、目标地址与所用策略。若结果不符，先找它之前可能命中的规则，再决定是否修改匹配值。

可以用“目标、预期、实际、改动”四项保存测试记录。例如：目标为自己的某个接口域名，预期 PROXY，实际 DIRECT，本轮只将该 DOMAIN 规则移到 DOMAIN-SUFFIX 前面。这样能够区分“规则没有命中”和“已经命中但连接失败”，也方便在验证结束后撤销临时设置。

  • 命中错误：实际策略不是预期策略，优先查 Global Routing、选中的配置文件及规则顺序。
  • 命中正确但失败：已使用 PROXY 却超时，继续核对已有服务的可用性与协议参数，不必立即重写整套规则。
  • 局部资源失败：主页面正常但图片或登录失败，检查失败资源自己的域名，不只查看地址栏中的域名。

常见问题：规则没生效时先查什么

我已经写了规则，为什么还是全部走代理？

先到 Home → Global Routing 确认不是 Proxy，再到 Config 核对选中的文件。若已使用 Config，检查前面是否有范围更大的 PROXY 规则，以及 FINAL 是否被误放在自定义规则之前。

DOMAIN-SUFFIX 要不要写星号？

匹配 example.com 及其子域名时写 DOMAIN-SUFFIX,example.com,DIRECT，不写 *.example.com，也不写协议前缀。只想匹配某一个完整域名时，改用 DOMAIN。

IP-CIDR 加了 no-resolve，怎么反而没命中？

先确认连接记录中是否已有可匹配的目标 IP。no-resolve 不会为了这条规则主动解析域名；若需求本来就是指定域名分流，应增加域名规则，而不是假定该参数能补齐地址信息。

更新后自定义规则不见了，怎么办？

先在 Config 检查当前文件是否被远程内容替换，或是否切换到了另一份配置，再与保存的副本对照恢复。Home 中的服务订阅更新与 Config 中的配置更新不是同一个操作，排查时要分别记录。

能用 FINAL,REJECT 代替逐条检查吗？

只有明确采用允许列表、并准备好维护所有必要目标时才考虑这种设计。它会拒绝所有未被前面规则接管的连接；普通排障先保留原有兜底策略，用具体 DOMAIN 例外验证，避免一次阻断大量资源。

完成验证后，恢复临时改动过的姿态，删除测试用规则，再确认 FINAL 仍在末尾。规则维护的重点不是条目数量，而是每个例外都有明确目标、每次更新都能核对差异、每个失败连接都能区分匹配问题与连接问题。

App Store 正版核对