Shadowrocket（小火箭）自定义规则应在 Global Routing 的 Config 姿态下验证：具体例外放前面，范围规则放后面，FINAL 放最后。本文面向已有可用配置、需要调整分流的用户，依次说明规则语法、策略区别、排列方式与验证步骤；示例使用保留示例域名，不提供任何服务连接资料。
一、规则优先级：先匹配，不是先比较精确度
Shadowrocket 按配置中的顺序检查规则，一条连接命中某条规则后，就执行该条规则指定的策略，不再继续寻找后面“更精确”的规则。域名规则不会天然压过 IP 规则，单域名规则也不会自动排在后缀规则之前。需要例外时，应由规则作者把例外放到前面。
例如，希望 login.example.com 使用 DIRECT，而 example.com 及其余子域名使用 PROXY，应按下面的顺序排列。若把前两行调换，访问登录域名时就会先命中 DOMAIN-SUFFIX，后面的 DOMAIN 无法改变已经作出的选择。
[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT结论：先移动例外，再增加规则
发现一条精确规则没有生效时，先查它上方是否已有覆盖同一目标的规则；把必要例外移到覆盖规则之前，再建立新连接测试，避免不断添加重复行。
二、PROXY、DIRECT、REJECT：决定连接怎样处理
规则前半段回答“匹配什么”，最后的策略回答“怎样处理”。PROXY 表示交给代理路径处理，实际出口还取决于当前选择的服务器或配置中的策略安排；DIRECT 表示直接连接目标，不经过代理出口；REJECT 表示拒绝匹配的连接。它们不是 Shadowsocks、VMess、VLESS 或 Trojan 这样的协议名称，也不是连接质量的等级。
| 策略 | 规则示例 | 需要核对的条件 |
|---|---|---|
PROXY | DOMAIN,api.example.com,PROXY | 已有代理配置有效，所选服务器可用。 |
DIRECT | DOMAIN,printer.example.com,DIRECT | 当前网络能够直接到达目标，域名解析结果正确。 |
REJECT | DOMAIN,blocked.example.com,REJECT | 该域名确实需要阻断，而不是页面登录或资源加载依赖。 |
DIRECT 不等于连接一定成功。目标拒绝访问、本地网络不通或 DNS 返回错误地址时，直连仍会失败。同样，PROXY 命中只说明规则作出了代理选择，不说明远端服务一定能够访问。排查时应把“规则选对路径”和“路径实际可用”分成两项检查。
三、Global Routing：用 Config 验证自定义规则
先在 Home → Global Routing 确认当前姿态，再判断规则有没有效果。Config 按当前配置中的规则分流；Proxy 和 Direct 适合做路径对照，不能用于证明某一条自定义规则已命中。Scene 涉及场景选择，初次排查时不要同时引入场景切换，否则测试条件容易变化。
Config
推荐使用当前启用配置中的规则。规则可以分别选择 PROXY、DIRECT 或 REJECT，未命中的连接由 FINAL 决定。
适合：编辑并验证自定义规则、保留目标之间的分流差异。
Proxy
将流量交给代理路径处理。临时切换后可以检查同一目标经代理是否可达，但这不是当前规则列表的命中测试。
适合：与 Config 结果对照，检查代理路径本身是否可用。
Direct
将流量交给直接连接路径处理。若与 Config 的表现不同，应回到规则与日志检查，而不是立即更换协议。
适合：临时检查当前网络能否直接访问目标。
完成对照后应切回 Config。Settings → On Demand 管理按需连接条件，不负责重新排列规则；启用它也不会让位于 FINAL 后面的规则恢复可达。测试期间保持网络与连接状态稳定，避免把自动连接、网络切换和规则编辑同时进行。
四、常用规则语法：域名、地址段与 FINAL
常见规则以英文逗号分隔字段，不使用中文逗号。域名匹配字段只填写域名，不包含 https://、端口或 URL 路径。例如访问 https://api.example.com:443/v1 时，DOMAIN 对应的目标是 api.example.com，不是整条地址；443 是该示例连接的端口，不属于域名字段。
| 关键字 | 有效写法示例 | 匹配范围与注意事项 |
|---|---|---|
DOMAIN | DOMAIN,api.example.com,PROXY | 匹配完整域名，不自动包含其子域名。 |
DOMAIN-SUFFIX | DOMAIN-SUFFIX,example.com,PROXY | 匹配 example.com 及其子域名；不要写成 *.example.com。 |
IP-CIDR | IP-CIDR,192.168.0.0/16,DIRECT,no-resolve | 匹配 IPv4 地址段；/16 表示前 16 位为网络前缀。 |
GEOIP | GEOIP,CN,DIRECT | 依据 IP 地理数据库判断，不是根据域名后缀判断。 |
FINAL | FINAL,PROXY | 没有目标字段，处理前面均未命中的连接。 |
IP-CIDR 后的 no-resolve 表示不为了匹配这条规则而主动触发域名解析。因此，它不能理解为“所有域名都会先解析，再检查这个地址段”。测试局域网设备时，应分别验证直接访问 IP 与使用设备域名的情况，并留意 DNS 返回的是公网地址还是内网地址。
GEOIP 依赖 IP 归属信息，结果不等同于页面内容、域名后缀或运营主体所在地。若某个业务必须走固定路径，使用明确的域名规则并放在 GEOIP 之前，比依赖地址归属作间接判断更容易核对。
- 字符检查：关键字、英文逗号与策略字段应完整，避免复制时带入全角符号。
- 范围检查：
DOMAIN-SUFFIX,example.com不匹配notexample.com，也不代表某个 URL 子目录。 - 地址检查：
192.168.0.0/16是私有地址段示例，不代表当前局域网一定使用该段。 - 兜底检查：一般保留一条有效 FINAL，并放在有效规则列表最后。
五、推荐排列：具体例外在前，FINAL 在后
下面是一段便于理解顺序的规则示例：先允许一个明确的登录域名直连，再拒绝一个明确域名，随后处理整个域名后缀；接着处理私有地址段和地域规则，最后交给 FINAL。示例表达的是排列方法，不是适用于所有网络的通用配置，应根据实际目标删减。
[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY这个顺序体现了“具体例外优先”，但并不是说域名规则必须永远在地址段之前。如果明确要求所有局域网目标都直连，就要同时检查域名规则是否可能先把解析到局域网的目标送去 PROXY，并结合 DNS 行为调整。顺序服务于实际意图，不能把一种模板当作固定优先级。
- 访问 login.example.com：第一条 DOMAIN 命中，执行 DIRECT，后面的后缀规则不再参与。
- 访问 blocked.example.com：第二条命中，执行 REJECT；将它移到后缀规则下方，就会改变结果。
- 访问 api.example.com：前两条均不匹配，随后命中 DOMAIN-SUFFIX，执行 PROXY。
- 直接访问 192.168.1.1：在前面域名规则不匹配的情况下，命中对应私有地址段并直连。
- 访问其他目标：继续检查 GEOIP，仍未命中才进入 FINAL。
FINAL,PROXY 与 FINAL,DIRECT 都是有效的兜底意图，区别在于未知目标默认走哪条路径。FINAL 不是连接失败后的重试机制：前面命中了 PROXY 但代理连接失败，不会因此跳过该规则再执行 FINAL。需要改变失败目标的路径时，应修改相关规则或修复所选连接。
六、编辑与验证：每次只改一个条件
以下操作以 iPhone / iPad 界面词为参照。规则属于 Config 中启用的配置文件，Home 中服务器列表的变化不等于规则文件也已更新。编辑前保留一份原配置，尤其要分清自己修改的是本地文件还是会被远程更新覆盖的文件。
-
确认姿态
进入 Home → Global Routing，选择 Config。记下当前选中的服务器，测试期间不要同时更换出口。
-
确认文件
进入 Config，核对当前启用的配置文件。保留原内容后再编辑；打开另一份未启用文件作修改，不会改变当前连接的分流。
-
调整顺序
在配置的规则内容中定位 [Rule]，把具体例外放到覆盖规则之前，确认 FINAL 位于最后。只复制规则行时，不要在已有 [Rule] 中重复插入区段标题。
-
保存重连
保存并确认修改后的配置已启用，必要时重新连接。关闭旧测试页面或结束旧连接，再发起新请求，避免复用编辑前已建立的连接。
-
核对结果
在连接记录或日志中查找目标域名、目标 IP 与实际策略。记录测试目标、命中结果和访问现象，再决定是否继续改动。
可以用三类目标建立最小测试集：一项应当 DIRECT、一项应当 PROXY、一项没有专门规则而应当进入 FINAL。若有意加入 REJECT，再增加一个明确的阻断测试。不要只以网页能否打开判断规则正确，因为 DIRECT 与 PROXY 都可能成功，页面还可能复用缓存。
结论：用命中记录区分两类故障
记录中的策略与预期不一致，优先查姿态、启用文件和规则顺序；策略一致但连接失败，转查 DNS、所选服务器与当前网络，不要继续堆叠相同的规则。
七、规则不生效：按现象回查
规则问题通常不是缺少更多规则，而是测试条件没有固定。先保留一个可以重复触发的目标，再按下面的现象逐项检查；需要更完整的网络排查时，可继续查看故障排查。
改了规则，但结果完全没有变化？
先检查 Home → Global Routing 是否为 Config，再检查 Config 中启用的是否为刚编辑的文件。保存后建立新连接；长连接、页面缓存和已存在的会话都可能让旧结果继续出现。
精确 DOMAIN 为什么没有覆盖后缀规则？
检查它是否位于 DOMAIN-SUFFIX 或其他已命中规则之后。规则按位置执行，不按精确程度重新排序。将例外移到覆盖规则前面，然后核对实际请求域名，防止页面跳转到了另一个域名。
FINAL 后面还能再添加例外吗？
不应这样排列。FINAL 会处理所有到达它的未匹配连接，后面的例外没有匹配机会。把新规则插入 FINAL 上方，并再次检查是否还被更靠前的范围规则覆盖。
访问一个网站，为什么有不同策略的连接？
页面可能分别请求登录域名、静态资源域名和接口域名，每条连接独立匹配。检查具体失败请求的域名，不要只根据地址栏中的主域推断全部资源都会使用同一策略。
更新后自定义规则消失，应该检查什么？
区分 Home 中已有订阅的服务器更新与 Config 中远程配置文件的更新。远程配置更新可能替换文件内容；先对照备份确认是哪项内容变化，再决定如何保留本地修改，不要把所有更新行为视为同一操作。
最后确认三个条件：使用 Config、启用了正确文件、例外位于范围规则之前。三项确认后，再用新连接检查最终策略。规则只负责选择处理路径，不能替代用户已有服务的可用性检查，也不会自动修复失效的连接参数。