2026-07-29 · 规则分流 · 约 8 分钟

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

说明规则按从上到下顺序逐条匹配、命中即停止的机制,FINAL 作为兜底的位置要求,以及 PROXY / DIRECT / REJECT 三种策略各自的写法与适用场景。

本文速览

Shadowrocket（小火箭）的规则不是“越精确就自动优先”，而是在当前生效配置中按顺序检查，先命中的规则决定策略。本文面向已有自己的服务商与订阅、希望修改分流行为的用户，依次说明 Global Routing、规则排序、三种策略与 FINAL，并给出可核对的配置片段和验证步骤。

先确认 Global Routing 使用 Config

自定义规则要参与分流，首先应在 Home → Global Routing → Config 选择按配置处理。只修改 Config 中的规则，却把 Global Routing 留在 Proxy 或 Direct，不能用来验证这些规则是否命中。规则决定“走哪条路径”，已有服务信息决定对应路径能否连接，两者需要分别检查。

Config

推荐

依据当前生效配置的规则选择策略。是否直连、代理或拒绝，取决于具体命中的规则，并非固定按地域区分。

适合:日常规则分流、自定义规则验证。

Proxy

将受 Shadowrocket 处理的连接交给当前代理路径，不按 Config 中的分流规则逐条选择策略。

适合:临时检查已有代理路径能否访问目标。

Direct

将受 Shadowrocket 处理的连接直接发往目标，不使用配置中的代理分流结果。

适合:对照目标在当前网络下的直连表现。

Global Routing 中的 Scene 用于按场景设置决定行为，不应直接视为 Config 的同义项。为减少排查变量，本文统一使用 Config。Settings → On Demand 管理的是按需连接触发条件，不是规则列表中哪一行优先；排查排序时，先保持连接状态和当前网络不变。

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

在普通规则列表中，请求从第一条开始接受检查，命中后采用对应策略，不再继续寻找“更具体”的后续规则。因此，一条精确的 DOMAIN 规则如果放在已经覆盖它的 DOMAIN-SUFFIX 后面，仍可能没有机会生效。排序依据是执行顺序，而不是字符串长度。

[Rule]
DOMAIN,metrics.example.com,REJECT
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

以上是语法示例，example.com 及其子域名只用于解释匹配，不是连接服务或可用性测试地址。第一条只处理 metrics.example.com；第二条给 login.example.com 设置直连例外；第三条覆盖 example.com 本身及其子域名；前面均未命中的请求再继续检查 GEOIP，最后交给 FINAL。

请求域名首次命中策略
metrics.example.com第 1 条 DOMAINREJECT
login.example.com第 2 条 DOMAINDIRECT
docs.example.com第 3 条 DOMAIN-SUFFIXPROXY

如果把 DOMAIN-SUFFIX,example.com,PROXY 移到最上面，表中三个域名都会先匹配它，下面的拒绝与直连例外便失去作用。需要优先阻止或放行的明确目标应靠前，覆盖面更大的后缀、地址范围与地域规则随后，兜底规则最后。

PROXY、DIRECT、REJECT 与规则关键字的区别

规则一行通常同时包含“匹配条件”和“处理策略”。例如 DOMAIN-SUFFIX,example.com,PROXY 中，DOMAIN-SUFFIX 是规则类型，example.com 是匹配内容，PROXY 是命中后的处理方式。协议名称和策略不是同一层概念：已有连接使用 Shadowsocks 或 VLESS，并不会改变 DOMAIN-SUFFIX 的匹配顺序。

3 种策略
本文使用 PROXY / DIRECT / REJECT
4 个关键字
重点核对 DOMAIN-SUFFIX / GEOIP / IP-CIDR / FINAL
1 条 FINAL
本文示例只在规则末尾保留一条兜底

判断方法：分开检查条件与出口

先核对请求是否命中预期规则，再核对该策略指向的路径是否可用；不要用“代理连接成功”代替“规则匹配正确”的验证。

策略实际含义检查重点
PROXY使用代理路径。核对当前代理选择；若使用策略组，还要核对组内选项。
DIRECT直接连接目标。当前网络是否能直接到达目标。
REJECT拒绝匹配的连接。目标是否确实应被阻止，有没有误伤必要请求。

如果配置中定义了自命名的策略组，应按照实际配置核对组名与组内选择，不能随意把未知名称当作内置策略。REJECT 也不是访问失败时的自动重试策略；命中它后，请求不会因为失败就继续尝试下面的 PROXY。

DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

IP-CIDR 按目标 IP 所属地址段匹配，192.0.2.0/24 是文档示例地址段。no-resolve 用于避免仅为这条 IP 规则额外发起域名解析，不表示关闭全部 DNS；已有目标 IP 信息仍可能参与匹配。GEOIP,CN,DIRECT 依据 IP 地理数据库判断，不依据域名后缀或运营主体判断，因此不能保证覆盖所有希望直连的网站。

FINAL 兜底：只处理前面没有命中的请求

FINAL 不需要域名或地址参数，常用写法是 FINAL,PROXY 或 FINAL,DIRECT。它是无条件兜底，所以应放在普通规则列表末尾。把它放在前面，后续规则就没有机会处理剩余请求；放两条 FINAL，也不会形成“第一条失败再试第二条”的容错链。

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

FINAL 解决的是“没有任何前置规则命中时怎么办”，不是“前面命中后连接失败怎么办”。若请求已被 DIRECT 规则接管，即使直连超时，也不能期待末尾 FINAL,PROXY 自动接手。此时应检查前面的匹配条件是否过宽，再决定调整顺序还是修改策略。

修改与验证：一次只调整一条规则

开始前保存当前配置副本，并记录正在使用的配置名称。Home 中的订阅负责维护已有服务信息，Config 中的规则负责分流；刷新 Subscribe 不等于修改了规则。远程配置更新也可能替换编辑内容，因此需要区分“更新已有订阅”与“更新规则配置”，并在操作后重新确认生效文件。

  1. 确认路由姿态

    进入 Home → Global Routing → Config。保持已有连接可用，记录当前选择的代理或策略组选项，避免测试中同时更换出口。

  2. 备份当前配置

    进入 Config，确认当前使用的配置，先保存副本，再打开该配置的编辑入口。使用文本编辑方式时，定位到 [Rule] 段。

  3. 插入具体规则

    把需要验证的 DOMAIN 或 DOMAIN-SUFFIX 放在会覆盖它的宽泛规则之前。末尾保留一条 FINAL，保存并确认使用的是刚修改的配置。

  4. 重建测试请求

    停止目标应用的旧请求，再重新发起访问。必要时在保存配置后重新连接 Shadowrocket，避免把修改前已经建立的长连接当作新规则的测试结果。

  5. 核对命中结果

    结合请求记录中可见的目标域名、目标 IP 与策略信息判断。每次只改一项，记录修改前后结果；未命中预期规则时先查顺序，不要立即更换协议。

网页通常同时请求主页面、登录、图片和接口等多个域名。主页面命中 PROXY，不代表所有资源都命中同一条规则。排查“首页能开、登录失败”时，应针对失败请求的实际域名检查，而不是只给浏览器地址栏里的域名添加例外。

判断规则是否生效，应看新请求的匹配和策略；延迟测试只能提供某条测试路径的响应情况，不能证明某个网页请求已命中指定规则。

常见问题：规则不生效时按现象定位

明明写了 DIRECT，为什么还走代理？

先到 Home → Global Routing 确认是 Config，再检查 DIRECT 规则上方是否有覆盖相同域名的 DOMAIN-SUFFIX 或其他宽泛规则。把明确例外移到覆盖规则之前，保存后重新发起请求。

把 FINAL 改了，目标还是打不开？

先检查请求是否真的落到 FINAL。若已命中前面的 REJECT 或 DIRECT，修改 FINAL 不会影响它。若确实命中 FINAL,PROXY，再核对所用代理路径、目标服务与 DNS 解析结果。

规则里有域名，访问 IP 却没有命中？

DOMAIN 与 DOMAIN-SUFFIX 依赖可用的域名信息。直接访问 IP 不等于访问相同域名；需要按地址匹配时，添加范围合适的 IP-CIDR。不要为解决一个目标而直接加入覆盖过大的地址段。

更新之后，刚加的规则怎么不见了？

在 Config 检查当前文件及其内容，确认是否切换了配置或更新了远程配置。用备份对照 [Rule] 段，恢复必要例外并检查 FINAL 位置；不要把 Home 中已有订阅的刷新结果当作规则已经保存的证据。

最后保留一份可解释的最小规则列表：明确例外在前，范围规则居中，FINAL 在末尾。出现异常时先确认 Global Routing 与当前配置，再追踪具体请求。这样可以把排序错误、出口不可达与 DNS 问题分开处理，避免不断添加重复规则后反而更难定位。

App Store 正版核对