· 进阶配置 · 约 9 分钟

小火箭自定义规则优先级:从上到下匹配、FINAL 兜底与 PROXY/DIRECT/REJECT

以配置文件 [Rule] 段为例,解释规则自上而下首条命中即停止的匹配顺序,FINAL 的兜底作用,以及三种策略的选择与常见排序错误。

本文速览

Shadowrocket（小火箭）的规则不是按“写得更具体”自动排序，而是在当前请求可用的匹配信息下，从上到下检查，首条命中后采用对应策略。本文适合已有配置、需要增加域名例外或检查分流结果的用户：先确认 Global Routing 使用 Config，再把具体例外放在宽泛规则之前，将 FINAL 留在最后，并用新连接核对实际命中结果。

先确认 Config，再判断规则有没有生效

[Rule] 段用于描述请求如何选择策略。排查“自定义规则不生效”时，第一步不是继续添加规则，而是确认应用正在使用哪一份配置，以及当前的 Global Routing 状态。若正在使用 Proxy 或 Direct，不能把结果当作 Config 下逐条匹配的验证结果。

  1. 打开 Home → Global Routing，确认当前选择为 Config，再返回 Home。
  2. 进入 Config，核对当前选中的配置。若存在多份配置，先确认编辑对象与使用对象一致。
  3. 在该配置的编辑入口检查 [Rule] 段，保存改动，并确认修改后的配置仍处于选中状态。
  4. 回到 Home，按需要重新建立连接，再对目标域名发起一次新请求；不要只刷新仍在复用旧连接的页面。

本文只讨论 Config 下的规则顺序，不展开 Scene 的场景设置。Settings → On Demand 管理按条件连接的行为，也不等于规则优先级设置；自动连接成功，只能说明连接被触发，不能证明某条域名规则已命中。

先保留可恢复的配置

修改前保留原配置副本。本文的代码只用于解释规则语法与排序，不包含完整连接参数，也不代替用户已有的配置。已有服务与订阅由用户自行管理，本站不提供、不销售、不推荐节点或订阅。

从上到下匹配：具体规则不会自动排到前面

规则中的匹配条件和策略是两件事。以 DOMAIN-SUFFIX,example.com,PROXY 为例，DOMAIN-SUFFIX 是规则类型，example.com 是匹配内容，PROXY 是命中后采用的策略。域名后缀匹配可以覆盖该域名本身及其子域名，因此后面的某个子域名例外可能根本没有机会被检查。

新请求匹配条件首条命中采用策略停止检查

下面是一个容易误判的顺序。访问 docs.example.com 时，上面的后缀规则已经可以匹配，请求会采用 PROXY；后面的精确域名规则不会因为“更具体”而覆盖它。

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

如果目标是让 docs.example.com 单独使用 DIRECT，而其他匹配该后缀的域名使用 PROXY，应当把精确例外移到前面。这里的优先级来自位置，不来自关键字的名称，也不来自规则的添加时间。

[Rule]
DOMAIN,docs.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY
3 种
本文讨论的策略：PROXY / DIRECT / REJECT
4 类
下文示例条件：DOMAIN / DOMAIN-SUFFIX / IP-CIDR / GEOIP
1 条
末尾 FINAL：承接此前未命中的请求

结论：先找更靠上的覆盖规则

新增例外没有效果时，先搜索同域名及其上级后缀，将例外移到第一条可能覆盖它的规则之前；不要通过重复追加同一条规则来提高优先级。

PROXY、DIRECT、REJECT：命中后的三个结果

策略决定“命中后怎么处理”，不决定“先检查哪一行”。把 PROXY 改为 DIRECT 不会让该行自动获得更高优先级；将一条 REJECT 放在宽泛的允许规则之后，也无法阻止已经被前面规则接走的请求。

策略处理含义验证重点
PROXY交给代理策略对应的出站处理。核对当前代理选择及其可用性；命中规则不代表远端必然可达。
DIRECT不经代理服务器，直接连接目标。核对当前网络是否能直接访问目标；它不是“断开整个 VPN”的指令。
REJECT拒绝该规则匹配的连接。核对被拒绝的域名是否为页面必需资源，避免过宽条件影响正常功能。

规则中的策略也可以涉及配置里已有的策略组。复制片段前应核对引用名称在当前配置中的含义，不能把任意文字当成已经存在的策略。本文统一使用 PROXY、DIRECT、REJECT 解释基础行为，不创建额外策略组，也不指定任何服务。

FINAL 的作用：兜底，不是自动重试

FINAL,PROXY 表示此前规则都没有命中时，使用 PROXY。它没有域名或网段条件，因此应放在规则段最后。若把 FINAL 提前，后面的常规规则便没有机会接到尚未命中的请求。

代理兜底的规则布局

精确例外
DOMAIN,docs.example.com,DIRECT
后缀策略
DOMAIN-SUFFIX,example.com,PROXY
最终兜底
FINAL,PROXY

未被前两条匹配的请求交给 PROXY；是否可达另行验证。

直连兜底的规则布局

精确阻止
DOMAIN,blocked.example.com,REJECT
后缀策略
DOMAIN-SUFFIX,example.com,PROXY
最终兜底
FINAL,DIRECT

未被前两条匹配的请求直接连接；不会因为直连失败而回到上一条。

FINAL 不是“前面的代理连接失败后换一种方式再试”。一旦某条规则命中，后续连接即使超时，也不意味着匹配流程会自动往下走。若请求已经命中某条 PROXY 规则，应检查该策略对应的连接，而不是在末尾增加第二条 FINAL 期待故障回退。

  1. 先决定未分类流量应由 PROXY 还是 DIRECT 承接。
  2. 检查现有配置是否已经有 FINAL，修改原来的兜底策略，而不是盲目追加。
  3. 将需要保留的规则整理到 FINAL 之前，确认后面没有遗留的有效规则。

把域名、网段和 GEOIP 放进同一份示例

以下片段展示一种可阅读的排序：明确阻止项、精确域名例外、域名后缀、指定网段、GEOIP，最后是 FINAL。这是示例布局，不是固定的类型优先级。如果业务要求相反，例如某个网段必须始终直连，就需要重新评估其位置以及请求是否具备可匹配的 IP 信息。

[Rule]
DOMAIN,blocked.example.com,REJECT
DOMAIN,docs.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

example.com 及其子域名用于说明域名关系；192.0.2.0/24 是文档示例网段，不应把它当作真实业务地址。GEOIP,CN,DIRECT 展示按目标 IP 地理数据库分类的写法，不表示所有用户都应该采用这项策略。

规则关键字匹配对象本例注意事项
DOMAIN完整域名。只给明确的单个域名设置例外，不自动覆盖其所有子域名。
DOMAIN-SUFFIX域名本身及其子域名。若先写该行，后面的同后缀精确例外可能无法命中。
IP-CIDR目标 IPv4 地址所属网段。no-resolve 表示不为该条匹配主动触发域名解析，不能理解成关闭全部 DNS。
GEOIP目标 IP 在地理数据库中的分类。判断依据不是网页语言、域名后缀或网站所属公司的地址。
FINAL此前未命中的请求。放在末尾，仅承担兜底，不检查目标可用性。

域名规则依赖可用的域名信息，IP 规则依赖目标 IP；两者不能仅靠“看起来是同一个网站”互相替代。一个页面还可能请求多个资源域名。主页面命中 DIRECT，并不能推出图片、视频或登录接口也使用 DIRECT。排查时应记录具体请求的目标，而不是只记录浏览器地址栏。

结论：每次只调整一个匹配条件

先用一个明确域名验证位置与策略，再逐步引入后缀、网段或 GEOIP。若同时改动 DNS、Global Routing 和多条规则，即使结果变化，也难以判断是哪项调整起作用。

修改后的验证顺序与常见问题

验证规则应分开看“有没有命中”和“命中后能不能连接”。前者检查配置、顺序和目标信息，后者检查 DIRECT 的网络可达性或 PROXY 对应的连接。只凭网页打开速度判断策略，容易把缓存、连接复用和服务端响应差异误认为规则效果。

  1. 记录基线：记下当前配置、Global Routing 状态、目标域名和预期策略。修改前保留原规则位置。
  2. 保存并应用：确认正在使用修改后的配置，必要时重新连接。不要只编辑一份未选中的文件。
  3. 建立新连接：结束原来的访问再重试，避免长连接继续沿用建立时的处理结果。
  4. 查看连接记录：在应用提供的请求或连接记录中核对目标、策略与可用的命中信息。若没有记录，先检查请求是否进入当前连接。
  5. 一次只改一项：先验证规则位置，再验证策略。若失败，恢复副本后重测，不要连续叠加未经核对的例外。

规则加在最后了，为什么还是走原来的策略？

先检查新增规则是否位于 FINAL 之后，再向上搜索能覆盖目标的 DOMAIN-SUFFIX 或其他规则。将新规则移到第一条覆盖规则之前，保存并用新连接测试。不要依赖重复添加来改变结果。

已经设置 DIRECT，为什么仍然打不开？

先核对请求记录是否确实采用 DIRECT。若已采用，继续检查当前网络能否直接访问该目标，以及域名解析是否正常；DIRECT 只规定出站方式，不保证目标在当前网络可达。

设置 REJECT 后，整个页面都异常了怎么办？

暂时移除刚加的 REJECT 规则并重新请求，确认异常是否随之消失。若有关联，将宽泛的 DOMAIN-SUFFIX 收窄为需要阻止的精确 DOMAIN，再核对页面依赖的其他资源域名。

更新配置后，手动写的规则不见了？

先区分更新的是 Home 中已有订阅的服务器列表，还是 Config 中的远程配置。重新获取远程配置可能覆盖本地编辑内容；更新前保存副本，更新后比较 [Rule] 段，并重新确认当前选中的配置。

需要回到基础设置时，可查看使用说明；涉及 Global Routing 的状态核对，可查看功能介绍中的 Global Routing 说明。完成验证后保留必要的例外，删除重复规则，让下一次检查仍能从上到下读懂整段配置。

获取 ShadowrocketApp Store 正版核对