Shadowrocket 规则写法入门：DOMAIN-SUFFIX、GEOIP、IP-CIDR 与 FINAL 匹配逻辑

一、先确认 Global Routing，再讨论规则是否命中

规则文件存在，并不等于当前连接正在按该文件分流。Home 管理连接与所选出站，Config 管理配置文件，Settings 管理应用设置。排查前先记下 Home → Global Routing 的当前选择，再到 Config 核对正在使用的文件；不要把“文件已下载”和“文件已启用”视为同一步。

Settings → On Demand 管理按条件建立连接的行为，不是规则列表的优先级开关。系统显示 VPN 已连接，也只说明隧道处于连接状态；某次请求是否经过代理，仍需结合路由姿态、命中规则与最终策略判断。

二、读懂一行规则：类型、匹配值与策略

常见规则使用英文逗号分隔。以 DOMAIN-SUFFIX,example.com,DIRECT 为例，第一项指定匹配方式，第二项是匹配对象，第三项决定匹配后如何处理。配置文件中的普通规则放在 [Rule] 段，不能只把一行规则随意贴到文件末尾而不检查它所在的段落。

[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,DIRECT

这是一段语法演示，不是可满足所有使用需求的完整配置。192.0.2.0/24 是文档示例网段；所有规则都指向 DIRECT，是为了先观察匹配行为，不引入尚未定义的代理策略。不要直接用它覆盖已有配置。

• DIRECT 表示直接连接，并不表示这次请求一定成功；目标服务仍可能不可达。
• 规则中使用 PROXY 或自定义策略名时，先核对当前配置中对应策略或策略组是否可用，拼写应与配置一致。不要把任意单词当作已经存在的出站。
• FINAL 没有域名或网段字段，通常写成 FINAL,DIRECT，不要套用三字段格式。
• 使用半角英文逗号。域名字段不带 https://、端口、路径或查询参数。

例如，浏览器访问 https://docs.example.com:443/help 时，域名规则关注的是 docs.example.com。这里的 443 是连接端口，/help 是 URL 路径；二者都不是 DOMAIN-SUFFIX 的匹配值。协议连接参数与分流规则也属于不同层次，不应在域名字段里填写协议名称。

三、DOMAIN、DOMAIN-SUFFIX 与 DOMAIN-KEYWORD 的边界

三个关键字都围绕域名匹配，但范围不同。需要精确例外时优先考虑 DOMAIN，需要整个域及其子域时再考虑 DOMAIN-SUFFIX。DOMAIN-KEYWORD 的范围更宽，应确认不会把只是包含相同文字的其他域名一并纳入。

DOMAIN-SUFFIX 根据域名层级边界判断，不是任意字符串结尾匹配。通常直接填写 example.com，不需要加 *.。如果目标只是 api.example.com，写 DOMAIN 能避免把同域下其他主机一并纳入。

四、IP-CIDR、GEOIP 与 DNS 的关系

IP-CIDR 匹配目标 IP 地址是否落在指定网段内，而不是匹配域名文本。192.0.2.0/24 表示该 IPv4 网段，192.0.2.18/32 表示一个 IPv4 地址。前缀数字不是端口，也不是优先级；数字越大，网段范围通常越小，但不会因此自动排到列表前面。

IP-CIDR,192.0.2.18/32,DIRECT,no-resolve
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECT

GEOIP 使用目标 IP 在地址数据库中的归属信息。例如 GEOIP,CN,DIRECT 针对数据库归属为 CN 的地址，不表示匹配中文网页，也不是匹配域名是否以 .cn 结尾。内容分发、地址变化与数据库信息都可能使实际结果不同于按网站名称作出的猜测。

• 请求带域名时：检查某些 IP 类规则可能需要解析地址，因此 DNS 结果可能影响后续判断。
• 使用 no-resolve 时：该 IP 类规则不为了匹配而主动触发域名解析；它不是全局关闭 DNS 的设置。
• 请求本身就是 IP 时：可以直接检查网段或地址归属，但不能假设一定能恢复出原来的域名。
• 测试地址变化时：同一域名可能解析到多个地址，IPv4 与 IPv6 的实际路径也可能不同，需要检查本次连接的目标地址。

因此，“域名看起来属于某地区”与“GEOIP 应该命中”之间不能直接画等号。排查顺序应是先确认实际目标，再看解析结果与数据库判断。若尚未获得可供判断的地址，带 no-resolve 的 IP 类规则可能不匹配，流量会继续检查后面的规则。

五、自上而下匹配：精确例外在前，FINAL 在后

普通规则按配置中的顺序检查，命中后使用对应策略，不会继续向下寻找“更精确”的另一条。DOMAIN 并不会天然高于 DOMAIN-SUFFIX，单个地址规则也不会天然高于大网段规则；要让例外优先，必须把它写在覆盖范围更大的规则之前。

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

这段示例的前提是当前配置已有可用的 PROXY 策略。访问 login.example.com 时第一条已经命中，直接连接；访问 img.example.com 时第一条不匹配，第二条命中并交给 PROXY。若把第二条移到第一条前面，登录域名也会先命中后缀规则，后面的精确例外将失去作用。

1. 先放明确的主机例外，例如单个登录域名。
2. 再放域名后缀、关键词或按需要整理的其他规则，留意相互覆盖的范围。
3. 安排地址类规则时，核对是否允许为匹配进行解析，以及是否会覆盖后续规则。
4. 把 FINAL 留在最后，作为前面的规则都不匹配时的最终处理方式。

FINAL 不是失败后的备用连接。某条规则命中 PROXY 后，如果对应连接超时，不会因此继续往下走到 FINAL。连接失败后的切换行为取决于所用策略组及其设置，不能靠在 FINAL 后追加另一条规则实现。

六、从备份到验证：一次只改一条规则

以下步骤以用户已经持有自己的连接配置为前提。修改前保留原文件，先验证一条目标明确的域名规则，再考虑批量整理。远程配置更新可能覆盖本地修改，因此要区分自己编辑的副本与后续会重新获取的文件。

1. 保留原配置

   进入 Config，确认当前使用的配置文件，保留可恢复的副本。记录原来的 Global Routing 选择及目标规则顺序，不先删除整个规则段。

2. 修改规则段

   在 Config 中打开待修改文件的编辑操作，找到 [Rule]，加入一条针对自己测试域名的 DOMAIN 规则。保存后确认当前启用的是修改后的文件；编辑入口的具体呈现以应用内为准。

3. 确认路由

   回到 Home → Global Routing → Config。确认连接已开启，所引用的代理策略也有可用出站；若使用 Scene，先记录场景设置，避免把场景切换误判为规则变化。

4. 发起新请求

   让目标应用重新建立连接，再检查连接记录中的目标域名、地址、命中规则及策略。已有长连接可能沿用原路径，仅保存文件不一定使旧连接立即重建。

5. 对照后恢复

   将实际结果与预期逐项对照：先看命中，再看连接成败。完成测试后移除临时规则或恢复原文件，并恢复原来的 Global Routing 选择。

不应只用 Home 中的延迟测试作为规则正确的证据。延迟测试针对选定出站的测试目标，浏览器请求却可能涉及另一个域名、不同地址与不同端口。记录“目标域名、目标端口、命中规则、最终策略、错误现象”这五项，比反复切换所有设置更有助于复现问题。

七、连接错误与规则错误分开排查

下面列出网络诊断中常见的英文错误文本。具体界面可能显示更完整的上下文，不应假设每次都会使用相同措辞。先确定请求已经命中了哪条规则，再沿着它选择的路径排查；不要看到超时就立即把所有请求改成同一个策略。

如果文件无法正常保存或加载，先检查段落名、英文逗号、策略名和字段数量；如果文件能用但命中错误，先检查顺序与匹配范围；如果命中正确但无法访问，才继续检查连接链路。这三个层次的处理方向不同。