Shadowrocket（小火箭）的自定义规则按顺序检查，先命中的规则决定策略；具体例外放在宽泛规则前，FINAL 放在 [Rule] 段末尾。本文适用于 iPhone、iPad、Mac、Windows、安卓与 Linux 用户理解规则文件，界面操作以设备实际显示为准。读完可建立一份最小规则、区分 PROXY / DIRECT / REJECT，并按“当前配置、运行姿态、命中顺序、出站连接”定位问题。
1. 先确认 Config 姿态，再判断规则是否生效
连接开关已打开，不等于自定义规则正在参与分流。以 iPhone / iPad 的界面为例，先在 Config 确认已选择准备编辑的配置，再回到 Home 查看 Global Routing。排查本文规则时应使用 Config，而不是先用 Proxy 或 Direct 测试后，就据此认定规则有误。
本文以用户已经拥有可用的服务配置为前提。规则只决定请求采用哪种处理方式，不能生成连接凭据，也不能修复服务端不可达。本站不提供、不销售、不推荐节点或订阅。修改前请先保留现有配置副本，避免一次替换全部设置后失去对照。
| Global Routing | 排查时的含义 | 适合验证什么 |
|---|---|---|
| Config | 按当前配置中的规则决定策略 | 规则顺序、例外与 FINAL |
| Proxy | 主要使用代理出站，而非本文逐条规则的测试姿态 | 选中的代理连接是否可用 |
| Direct | 主要使用直接连接 | 当前网络的直连可达性 |
| Scene | 按已设置的场景逻辑工作 | 场景选择与切换，不作为本文基准 |
Settings → On Demand 管理按需连接条件，并不改变 [Rule] 的先后关系。若网络切换后连接状态变化，应先核对 On Demand，再检查规则；不要把“隧道没有连接”和“规则匹配错误”当成同一问题。
2. 规则语法：类型、匹配值、策略各占一项
多数规则采用“规则类型,匹配值,策略”的逗号分隔形式，关键字和分隔符使用英文字符。FINAL 没有匹配值，写成 FINAL,PROXY 即可。下面是 [Rule] 段的教学示例，不是包含服务器、DNS 与其他设置的完整配置；请将它放进已有可用配置中核对，不要把它当成可独立连接的文件。
[Rule]
DOMAIN,blocked.example.com,REJECT
DOMAIN,local.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYexample.com 及其子域名用于说明匹配关系；192.0.2.0/24 是文档示例网段，不是可用服务地址。上面的规则说明语法与顺序，不能证明这些地址存在实际服务。验证时应使用自己有权访问的目标，并按真实用途决定是否需要直连或拒绝。
- DOMAIN：精确匹配域名。例如
local.example.com，不会因为名字相近就匹配其他子域名。 - DOMAIN-SUFFIX：匹配指定域名及其子域名。
example.com可覆盖api.example.com，但不等于任意包含这段字符的域名。 - IP-CIDR：匹配 IPv4 地址范围。这里的
/24表示网络前缀长度，不是端口号。 - GEOIP：依据目的 IP 的地域数据库归属匹配。
CN不是按网页语言、域名后缀或用户所在地判断。 - FINAL：接住未命中前序规则的请求，不再附加域名或 IP 条件。
3. 从上到下匹配：具体例外先于宽泛范围
规则不是把全部匹配项收集后，再自动挑选“最精确”的一条。对同一请求，前面的规则先获得判断机会；一旦命中并确定策略，就不继续用后面的常规规则覆盖结果。因此，精确域名即便比域名后缀更具体，放在后面也不会自然获得更高优先级。
例外在前：符合目标
- 第一行
DOMAIN,local.example.com,DIRECT- 第二行
DOMAIN-SUFFIX,example.com,PROXY- 末行
FINAL,PROXY
local.example.com 先命中 DIRECT，其他匹配后缀的请求使用 PROXY。
范围在前：例外被遮住
- 第一行
DOMAIN-SUFFIX,example.com,PROXY- 第二行
DOMAIN,local.example.com,DIRECT- 末行
FINAL,PROXY
local.example.com 已命中第一行，后面的 DIRECT 不会改写这次决定。
结论：先放例外，再放范围，最后放兜底
新增一条“没有效果”的规则时，先向上查找能覆盖同一目标的旧规则。将必要的精确例外移到它前面，再建立新连接复测，比反复切换策略更容易定位原因。
- 写出目标意图：例如仅让
local.example.com直连，其余example.com子域名使用代理。 - 先放精确的 DOMAIN 例外，再放 DOMAIN-SUFFIX 范围；存在拒绝例外时，也按预期优先级摆放。
- 检查是否还有更靠前的规则已经覆盖目标，包括已有配置内引入的其他规则。
- 保存并确认选中的仍是该配置；用新连接验证，不以旧页面中的存量连接作结论。
4. FINAL 为什么必须在最后，兜底该选什么
FINAL 没有额外匹配条件。若把 FINAL,PROXY 放到 [Rule] 开头，前面没有规则筛选，后续的域名或 IP 规则就失去了处理这些请求的机会。同理，放在中间会遮住它后面的规则。维护时保留一条清晰的 FINAL，并将它放在 [Rule] 段末尾，而不是整个配置文件任意位置。
[Rule]
DOMAIN,local.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY这个示例表达的是：先处理明确的域名要求，再让 GEOIP 判断其余目的 IP，最后把仍未命中的请求交给 PROXY。FINAL 不是连接失败后的备用线路，也不是“上一条代理失败就走直连”的容错开关。规则已经选择 PROXY 后，连接失败不会仅因为末尾存在 FINAL,DIRECT 就自动重试直连。
| 兜底写法 | 未命中请求的处理 | 修改前应确认 |
|---|---|---|
FINAL,PROXY | 交给代理策略 | 代理出口可用，并符合未知目标的预期路径 |
FINAL,DIRECT | 直接连接目的地址 | 未列出的目标允许使用当前网络直连 |
FINAL,REJECT | 拒绝其余请求 | 允许访问的范围已列全，否则正常业务也可能被拒绝 |
不要为了让网页暂时打开就频繁改动兜底。先确定希望未列明的目标走哪条路径，再补充必要例外。把 FINAL 当作清晰的默认策略，有助于在规则增多后仍然解释每一次分流结果。
5. PROXY、DIRECT、REJECT 不是三种连接协议
这三个关键字描述处理策略，而不是协议名称。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 属于连接配置所涉及的协议概念；写成 PROXY 并不会把当前连接自动改成某一种协议。若当前配置使用自定义策略组，还要检查该组名称及实际选中的出站，不能把未定义的组名当成可用策略。
| 策略 | 作用 | 常见误解 |
|---|---|---|
| PROXY | 将匹配请求交给代理出站；需核对当前选中的连接或相关策略设置 | 不是自动选择最快线路，也不保证服务端可达 |
| DIRECT | 使用当前网络直接连接目的地址 | 不是停止全部 VPN，也不代表其他请求都直连 |
| REJECT | 拒绝匹配到的请求 | 不是修复连接，也不是降低优先级后等待重试 |
例如，DOMAIN,blocked.example.com,REJECT 会拒绝该精确域名，不会连带拒绝所有 example.com 子域名。若要拒绝整个域名范围，语义应改为 DOMAIN-SUFFIX,example.com,REJECT；这也会扩大影响面，必须检查是否误伤登录、接口或资源域名。
6. IP-CIDR、GEOIP 与 DNS：别把域名请求直接当成 IP 请求
域名规则通常可依据请求中的域名判断；IP-CIDR 与 GEOIP 则需要目的 IP 信息。一个域名可能对应多个地址，地址也可能随网络、解析结果或服务部署变化。把一次看到的 IP 写死成直连规则，未必能覆盖下一次访问，更不能据此断言整个域名都会采用同一策略。
no-resolve 用于避免仅为该 IP 规则的匹配而主动触发域名解析。它不是“禁用 DNS”，也不代表所有域名请求都能按这条 IP 规则判断；如果没有可用于判断的目的 IP，就不能依靠它强行得出网段匹配结果。
- 明确的域名要求：优先使用 DOMAIN 或 DOMAIN-SUFFIX，放在 GEOIP 之前，避免把业务意图绑定到一次解析结果。
- 明确的地址范围：使用 IP-CIDR，并检查 CIDR 前缀。不要把
192.0.2.0/24写成带端口的192.0.2.0:443。 - 地域判断：GEOIP 依赖数据库中的目的 IP 归属，不保证等于服务器实际物理位置；云服务或内容分发场景尤其需要核对。
- IPv6 目标：IPv4 的 IP-CIDR 范围不会覆盖 IPv6。若排查双栈请求，应分别核对实际地址类型，不能只凭一条 IPv4 规则判断全部流量。
HTTPS 常见目的端口为 443，但本文的 DOMAIN-SUFFIX 规则没有端口条件。它按域名匹配，不是只匹配 443。遇到某个接口仍然失败时，应分别检查目标域名、实际地址、目的端口和连接错误，不要把应用服务端拒绝误判成规则没有命中。
7. 保存后如何验证：一次只改一个变量
验证应区分“匹配是否正确”和“所选出站能否完成连接”。前者看请求被分到哪个策略，后者看连接是否成功。规则命中 PROXY 但代理连接失败，仍可能说明规则顺序正确；反过来，页面能打开也不能证明一定走了预期策略。
- 保留基线：复制当前可用配置，记录修改前的 Global Routing、选中连接和要验证的域名。
- 只改一项：先添加一条精确 DOMAIN 规则，或只调整两行顺序，不同时改 DNS、连接协议和 FINAL。
- 确认选中：回到 Config 核对正在使用的配置，再在 Home 确认 Global Routing 为 Config、连接状态正常。
- 建立新连接：关闭旧页面后重新发起请求，必要时结束应用中的存量连接。已有连接可能继续使用建立时的路径。
- 核对记录：在设备可用的连接记录或日志中检查目标、命中规则及策略；记录不显示全部字段时，结合临时精确规则做对照，不猜测结果。
- 恢复与归档：若改动导致异常，先恢复副本；确认有效后再合并到日常配置，并记下规则用途。
加了 DIRECT，为什么这个域名还是走 PROXY？
先检查 Global Routing 是否为 Config，再确认编辑的配置就是当前配置。从该 DOMAIN 行向上查找覆盖它的 DOMAIN-SUFFIX 或其他规则，把必要例外放到范围规则前，保存后用新连接复测。
FINAL 写了 DIRECT，代理失败后怎么没有直连？
FINAL 只处理未命中前序规则的请求，不处理已经命中 PROXY 后发生的连接错误。先看该请求命中的具体规则，再排查当前代理出站；若业务本就要求直连，应添加范围准确的 DIRECT 规则，而不是依赖失败回退。
更新订阅后，自定义规则会不会被覆盖？
先区分 Home 中的连接订阅更新与 Config 中的远程配置更新。前者主要更新连接资料，后者可能重新载入规则内容。编辑前保存本地副本；需要持续更新远程配置时，先核对更新范围，不要只在远程内容上作一次性修改。
开了 On Demand，为什么规则还是没有效果？
在 Settings → On Demand 核对自动连接条件，再返回 Home 检查实际连接状态与 Global Routing。On Demand 负责何时连接，不负责把运行姿态自动解释为 Config，也不会调整规则顺序。
日常维护可遵循同一顺序：具体例外在前、范围规则居中、FINAL 在末尾。遇到问题先看当前配置与命中记录，再查出站可达性；不要通过堆叠重复规则来掩盖一个尚未定位的连接故障。