在 Shadowrocket（小火箭）中，自定义规则应先写具体例外，再写范围较大的匹配，最后放 FINAL。本文适合已有可用配置、希望调整分流的用户：先核对 Global Routing 与当前 Config，再按示例理解语法，通过新建连接核对实际命中结果。涉及 PROXY 的操作均以用户已有自己的服务商与订阅为前提。
一、先确认 Config 生效，再检查规则顺序
规则文本保存成功，不等于当前连接正在使用它。先在 Home 检查 Global Routing，按本文逐条规则分流时应使用 Config，再到 Config 核对当前选用的配置文件。编辑另一个未启用的文件，不会改变现用配置的匹配结果。
Global Routing 中的 Proxy、Direct、Config、Scene 是路由姿态，不是四种规则关键字。Proxy 与 Direct 分别用于全局代理、全局直连；Config 按当前配置进行分流；Scene 用于按场景组织路由行为，排查时还需核对实际场景设置。不要把路由姿态与规则行末的策略混为一谈。
- 在 Config 保留当前文件的副本，记录正在使用的配置名称。
- 在 Home → Global Routing 选择 Config，确认不是在其他姿态下观察规则。
- 回到 Config，编辑已选用的配置，保存后重新发起测试请求。
- 查看应用内连接记录中的目标与策略；仍走旧连接时，结束该连接后再测。
二、自上而下匹配：命中后不再寻找“更具体”的规则
常见规则行按列表顺序检查，首条命中规则决定策略，后面的规则不会再为同一请求重新排序。Shadowrocket 不会因为后一条域名更长，就自动把它提升到前面。应由配置作者把例外放到宽泛规则之前。
例如，先写 DOMAIN-SUFFIX,example.com,PROXY，再写 DOMAIN,api.example.com,DIRECT，那么对 api.example.com 的域名匹配会先命中前一条。要让这个子域名直连，应把 DOMAIN 那一行移到前面。以下域名仅作语法说明，不代表可用服务。
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT结论：先移动例外，再添加重复规则
某个域名没有按预期分流时，先检查它上方是否已有覆盖该域名的规则；在列表末尾重复添加同一目标，通常无法改变先前的命中结果。
三、规则语法：匹配条件与策略分开理解
大多数常见规则采用“类型、匹配值、策略”的逗号分隔结构。FINAL 是特殊的兜底行，不需要匹配值。建议使用英文逗号，每行只写一条规则，不要把整段配置粘贴到单个匹配值字段里。
| 规则示例 | 匹配对象 | 核对要点 |
|---|---|---|
DOMAIN,api.example.com,DIRECT | 完整域名 | 只匹配该域名，不等同于它的全部子域名。 |
DOMAIN-SUFFIX,example.com,PROXY | 域名后缀 | 覆盖 example.com 及其子域名，不是任意文本包含匹配。 |
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve | IPv4 网段 | 匹配对应地址范围；no-resolve 不主动为本条 IP 匹配触发域名解析。 |
GEOIP,CN,DIRECT | IP 地理归属 | 按所用地理数据库判断，域名后缀不能作为 IP 地理归属的依据。 |
FINAL,PROXY | 前序规则未命中 | 作为末尾兜底，PROXY 必须具备可用的代理出站条件。 |
域名规则中不填写协议前缀、网页路径或端口。例如，目标地址包含 HTTPS、路径和 443 端口时，DOMAIN 匹配值仍只写主机名；需要依据端口分流时，应使用对应的端口规则，而不是把 :443 拼在域名后面。
四、DOMAIN-SUFFIX、IP-CIDR、GEOIP 怎样排列
没有适用于所有配置的固定类型排序；真正需要保持的是“例外在覆盖它的规则之前”。通常可从精确域名例外开始，再放域名后缀、明确网段、较宽泛的 GEOIP，最后放 FINAL。若某个网段必须优先处理，也可以放在更前面，但要明确它可能覆盖哪些请求。
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN,metrics.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY这份片段只展示顺序，不应直接替换完整配置：api.example.com 作为直连例外排在后缀规则之前；metrics.example.com 作为拒绝例外也在前；其余 example.com 子域名使用 PROXY。192.168.0.0/16 这一行仅覆盖指定私有网段，不代表所有本地网络地址。
- 域名条件：适合表达明确的网站或子域名意图。不要为了一个子域名的例外，直接改动整个后缀的策略。
- IP-CIDR 条件：适合已知地址范围。域名访问能否在该步骤取得 IP，受解析流程及 no-resolve 等选项影响。
- GEOIP 条件：范围通常较大，结果依赖目标 IP 与数据库。同一域名解析到不同地址时，匹配结果可能变化。
- FINAL 条件：放在全部具体条件之后；它前面没有命中的请求才会使用此策略。
no-resolve 并不表示整个应用停止 DNS 解析，也不保证该条规则永远不会命中域名请求。它限制的是为该 IP 类规则匹配而主动触发解析；如果目标本来就是 IP，或流程中已有可用地址，仍需结合实际记录判断。
五、FINAL 选 PROXY、DIRECT 还是 REJECT
FINAL 决定“尚未明确分类的请求”如何处理，不是连接失败后的重试开关。前面的规则已命中 PROXY 后，即使代理连接失败，也不会因此继续走到 FINAL。需要备用出站时，应检查对应策略组的行为，而不是依靠末尾兜底接管失败请求。
| 兜底写法 | 未匹配请求的处理 | 使用前检查 |
|---|---|---|
FINAL,PROXY | 交给代理出站。 | 用户已有的代理可用；需要直连的目标已在前面明确列出。 |
FINAL,DIRECT | 直接连接目标。 | 需要代理的目标已被前序规则覆盖；接受其他目标直接连接。 |
FINAL,REJECT | 拒绝其余请求。 | 已建立足够完整的允许规则，并能排查登录、图片与接口的遗漏。 |
DIRECT 仍可能经过系统建立的 VPN 隧道处理，但出站策略是不使用代理服务器；它不等于关闭 Shadowrocket。REJECT 则是在规则层拒绝请求，不会自动识别请求是否“有用”。同一域名承载多个功能时，拒绝整个域名可能同时影响正常功能。
结论：按未分类流量的预期选择兜底
先写清哪些目标必须例外，再决定剩余请求的处理方式；不要仅为了消除一次报错，就把 FINAL 在三个策略之间反复切换。
六、修改后怎样验证与回退
验证应同时看目标、命中规则和出站策略，不能仅凭页面“能打开”就认定配置正确。浏览器缓存、已有长连接以及页面内多个不同域名的请求，都可能使表面现象与新规则的作用范围不一致。
- 保留基线：修改前保存原配置，记下一个正常访问的目标和当前路由姿态。
- 缩小改动：一次只调整一条规则或一个顺序，保存并确认当前 Config 仍选中该文件。
- 建立新连接：关闭测试页面后重新打开；必要时结束相关应用的旧连接，再发起请求。
- 核对记录：在应用内连接记录中找到实际主机名或 IP，检查匹配规则及最终策略，不只查看网站主域名。
- 恢复基线：出现异常时撤销刚才的规则，或重新选用保留的配置，再以同样目标复测。
如果配置来自远程内容，还要确认更新后是否覆盖了本地修改。服务地址列表更新与 Config 规则文件更新不是同一件事，应分别核对更新对象。需要长期保留的自定义规则，应保存在自己能够管理并回退的配置中。
七、自定义规则常见问题
已经写了 DIRECT，为什么还是走 PROXY？
先到 Home → Global Routing 确认使用 Config，再到 Config 确认编辑的是当前文件。接着检查 DIRECT 上方是否有覆盖同一目标的 DOMAIN-SUFFIX 或其他规则，把具体例外前移，并用新连接复测。
FINAL 放在最前面会怎样？
FINAL 会作为兜底接住到达该位置的请求，使后面的具体规则失去预期作用。把它移到规则段末尾，保留一个清晰的最终兜底，再检查上方条件是否覆盖需要特殊处理的目标。
加了 REJECT 后，为什么登录和图片一起出错？
检查被拒绝的域名是否同时承载登录、图片或接口请求。先撤销刚添加的 REJECT 恢复基线，再根据连接记录缩小匹配范围。DOMAIN-SUFFIX 拒绝的是整组域名，不是某个网页路径。
GEOIP 没按网站所属地区匹配，是规则失效吗？
不一定。GEOIP 判断的是请求目标 IP 在数据库中的归属，而不是运营主体所在地。先核对实际解析地址与命中记录；若需要固定处理某个域名，可在 GEOIP 之前添加明确的域名规则。