适合已经在 Shadowrocket（小火箭）中导入自己的配置、需要调整特定域名走向的读者。下文用可核对的规则示例说明逐条匹配、三种常见策略和 FINAL 兜底，并给出规则未按预期生效时的检查顺序。
先确认规则模式：Config 与逐条匹配
在 Home 查看 Global Routing。选择 Config 时，连接按当前配置文件中的规则处理；选择 Proxy 或 Direct，则分别采用对应的全局路由姿态，不适合用来检验某一条自定义分流规则。Scene 是另一种按场景选择路由的姿态，也不能与 Config 下的逐条规则测试混为一谈。开始排查前，记下正在使用的配置文件与所选代理，避免改的是一个文件、测试的却是另一个文件。
规则匹配的基本读法是：从规则列表顶部开始，检查请求是否符合当前行的条件；一旦命中，就采用该行指定的策略，不再继续查找后面的规则。域名后缀、目标 IP 所属网段与地理位置是不同的判断条件，不应仅凭它们在文件中的名字猜测优先级。若同一请求可能符合两行，排在前面的命中行决定结果。
规则一行怎么写：条件、目标与策略
一条常见规则以英文逗号分隔字段。DOMAIN-SUFFIX,example.com,PROXY 表示域名为 example.com 或以 .example.com 结尾时采用 PROXY；GEOIP,CN,DIRECT 表示符合该 IP 地理位置条件时采用 DIRECT。这里的 example.com 是文档示例域名，不代表需要导入的服务地址。编辑时保持关键字、逗号和策略名的英文写法，不要把中文标点混入规则。
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-SUFFIX,ads.example.com,REJECT
IP-CIDR,192.0.2.0/24,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY上面五行用于展示结构，并非建议直接覆盖现有配置。192.0.2.0/24 是文档示例网段：IP-CIDR 的斜杠后数字表示前缀长度，实际编辑时应填入自己确实需要匹配的目标网段。REJECT 表示拒绝符合条件的请求，DIRECT 表示不经所选代理直接连接，PROXY 表示交由当前配置所指向的代理路径处理。DIRECT 能否访问目标，仍取决于当前网络与目标本身是否可达。
域名与地址条件
- DOMAIN-SUFFIX
- 匹配指定域名及其子域名
- IP-CIDR
- 匹配指定的目标 IP 网段
- GEOIP
- 按目标 IP 的地理位置条件匹配
域名条件与 IP 条件检查的对象不同，调整前先确认请求实际访问的目标。
策略与兜底
- PROXY
- 交由所选代理路径处理
- DIRECT
- 直接连接目标
- REJECT
- 拒绝该请求
- FINAL
- 为此前未命中的请求指定策略
策略写在条件后；FINAL 不需要再填写域名或网段。
先写特例，再写宽泛条件
假设希望 ads.example.com 被 REJECT，而其余 example.com 域名走 PROXY，就必须把更具体的子域名放在较宽泛的后缀规则之前。若按上一个代码块的顺序排列，请求 ads.example.com 会先命中第一行 DOMAIN-SUFFIX,example.com,PROXY，第二行 REJECT 根本不会被检查。规则名称看起来更精确，并不会使后面的规则自动插队。
- 在 Config 打开当前使用的配置文件，找到需要修改的规则区域，并保留一份修改前的规则文本以便对照。
- 把只针对
ads.example.com的规则放在example.com后缀规则上方；保存后重新检查列表显示顺序。 - 保持 Global Routing 为 Config，重新发起目标请求，再结合应用内的连接记录核对目标与实际采用的策略。
DOMAIN-SUFFIX,ads.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY同一原则也适用于网段：如果一个较小的 IP-CIDR 范围需要 DIRECT，而覆盖它的较大范围需要 PROXY，应先放较小范围。修改顺序时只移动确实存在交集的规则，不要为了某个域名问题大面积重排整个配置。测试还应使用新发起的请求；已经建立的连接不能用来可靠判断刚保存的规则排列。
判断顺序：先找第一条可能命中的行
看到结果与预期不符时，沿列表从顶部查找同样能覆盖目标的规则；先修正这条规则与目标规则的相对位置，再考虑修改策略。
FINAL 为什么放最后
FINAL,PROXY 为前面都未命中的请求指定 PROXY。它的用途是收尾，不是提高 PROXY 的优先级。因为 FINAL 不再限定某个域名或网段，将它放在需要检查的具体规则之前，会使后续规则失去匹配机会。要让未分类请求直接连接，可以按自己的配置目标使用 FINAL,DIRECT；两种写法没有脱离网络环境的通用优劣，关键是明确未命中流量要去哪里。
- 特定目标：先列出需要单独处理的域名或 IP-CIDR，交集越明确，越容易核对先后顺序。
- 较宽范围：再放通用域名后缀、GEOIP 等条件，检查它们是否提前覆盖了特例。
- 最后一行：用 FINAL 为剩余请求收尾；如果修改了兜底策略，连同那些未列出专门规则的目标一起复测。
例如列表只有 DOMAIN-SUFFIX,example.com,DIRECT 和 FINAL,PROXY 时，匹配该后缀的请求走 DIRECT，其他未命中的请求走 PROXY。若在两行之间加入 GEOIP,CN,DIRECT，符合该条件且未先命中域名规则的请求才由 GEOIP 行处理。这样逐行描述结果，比单说“国内直连、其他代理”更准确，因为列表前方还可能存在其他命中条件。
规则保存后没有按预期生效：按次序排查
先区分“规则没被用到”和“选定的路径无法连通”。前者要查 Global Routing、当前配置文件和更靠前的规则；后者要检查所选代理或直连路径是否可用。Shadowrocket 处理规则，但规则本身不会让不可达的目标变得可达。用户已有自己的服务商与订阅时，还应确认正在使用的配置及其连接信息与自己准备测试的对象一致；这里不需要为排查而更换订阅来源。
- 回到 Home，确认 Global Routing 为 Config，并确认正在编辑、正在使用的是同一个配置文件。
- 从列表第一行向下查找目标可能命中的条件，尤其检查宽泛的 DOMAIN-SUFFIX、IP-CIDR 与 FINAL 是否排在目标规则之前。
- 核对请求的实际域名或目标 IP。网页可能同时请求多个域名，测试页面显示异常不等于页面主域名对应的规则未命中。
- 保存修改后发起新连接，查看应用内记录；若命中 PROXY 仍无法访问，再分别检查所选代理与目标的可达性。
已经写了 REJECT，为什么请求仍走 PROXY？
从顶部查找是否先有覆盖该目标的 DOMAIN-SUFFIX 或 FINAL。把具体的 REJECT 规则移到宽泛规则之前，保存后用新请求复测。
改了 FINAL，指定域名的走向为什么没变？
FINAL 只处理此前未命中的请求。先找该域名在 FINAL 之前命中的第一行；如需改变它的走向，应检查那一行的策略或位置。
设置了 GEOIP,CN,DIRECT，为什么有的网页仍走 PROXY？
先核对该连接对应的目标及前方规则。GEOIP 判断的是目标 IP 条件，不是网页使用的语言；若请求先命中域名规则，就不会继续检查 GEOIP。
切到 Proxy 后，怎样验证刚写的规则？
先把 Home 的 Global Routing 切回 Config，确认当前配置文件，再发起新请求。Proxy 全局姿态下的访问结果不能用来证明 Config 中某条规则已命中。
如果排查的是订阅带来的规则，先弄清本地编辑的位置与订阅更新后的配置内容。更新可能改变所使用的规则文本，复测前应重新查看目标行是否仍存在、顺序是否仍正确。对于 PROXY 策略，还要把规则命中与代理连接状态分开核对：命中只说明请求被分配到该路径，不保证这条路径当时可用。