Shadowrocket 规则类型详解:DOMAIN、DOMAIN-SUFFIX、GEOIP、IP-CIDR、FINAL 的匹配范围

1. 规则生效条件：Config 与首条命中

规则类型描述“用什么条件匹配”，行末策略描述“匹配后怎样处理”。两者必须分开看：DOMAIN,example.com,DIRECT 的条件是完整域名等于 example.com，结果是直连，并不是把该域名加入某个固定的代理名单。

本文讨论 Home → Global Routing → Config 下的分流。Proxy 与 Direct 分别用于全局代理、全局直连，不能用它们验证这里的规则顺序；Scene 属于按场景选择路由的另一种姿态，也不纳入本次测试。Config 页中还需要选用实际修改的配置，仅保存一个未被选用的文件不会改变当前分流。

在本文的普通规则示例中，匹配到第一条满足条件的规则后就执行该策略，不会继续寻找“更精确”的下一条。精确匹配没有自动高于宽泛匹配的优先级，优先级由排列位置决定。

2. DOMAIN、DOMAIN-SUFFIX 与 DOMAIN-KEYWORD

三种规则都以域名为匹配对象，不用于匹配网页路径或查询参数。访问 https://example.com/docs?q=test 时，域名是 example.com，不能把 /docs 或 ?q=test 填进 DOMAIN 来筛选页面。

DOMAIN：限制到一个完整名称

只希望 api.example.com 走代理，而其他子域名保持原策略时，优先使用 DOMAIN。规则值只写域名，不加协议头、不加端口号，也不加通配符。HTTPS 常用的目标端口 443 不属于域名字符串，因此 DOMAIN,example.com:443,PROXY 不是本文所需的写法。

DOMAIN-SUFFIX：覆盖主域名及其子域名

需要覆盖整个域名树时使用 DOMAIN-SUFFIX。它按域名层级边界匹配，不是任意字符后缀比较；example.com 能覆盖 static.example.com，却不会把 notexample.com 算进来。值中通常直接写 example.com，不要写成 *.example.com。

DOMAIN-KEYWORD：按域名中的片段匹配

DOMAIN-KEYWORD 的范围比后缀规则更难控制，因为字符串出现在域名任意位置都可能命中。只有确实需要按名称片段归类、并接受误匹配风险时才使用。若真实目标只有一个主域名及其子域名，DOMAIN-SUFFIX 更容易审核。

3. GEOIP 与 IP-CIDR：检查目标 IP

域名规则检查名称，GEOIP 与 IP-CIDR 检查地址。GEOIP 按本地 IP 地理数据库分类，例如 GEOIP,CN,DIRECT 表示对数据库归入 CN 的目标 IP 使用直连。它不检查网页语言、域名注册地，也不保证识别出服务器的物理所在地。

[Rule]
DOMAIN,api.example.com,PROXY
IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

IP-CIDR 用网络前缀描述 IPv4 地址范围。192.168.50.0/24 覆盖 192.168.50.0 至 192.168.50.255；若只针对一台设备，可使用 192.168.50.10/32。示例中的局域网地址不是远程服务地址，应按实际网络修改。

• 直接访问 IP：目标已经是地址时，可以直接检查是否落入 IP-CIDR 范围。
• 访问域名：评估 IP 类规则可能需要先取得解析结果；DNS 结果、缓存和连接复用都可能影响观察。
• no-resolve：表示不要仅为判断这条 IP 规则而主动进行域名解析，不代表关闭整个应用的 DNS，也不保证该条规则会获得一个地址供匹配。
• IPv6：本文 IP-CIDR 示例只讨论 IPv4。目标实际使用 IPv6 时，应检查相应地址族规则，不能用 IPv4 网段推断结果。

同一域名可能有多个解析地址，地址也可能随网络环境变化。若需求是“这个网站始终走某策略”，通常先考虑域名规则；只有明确需要按目标网段或地址归属分类时，再使用 IP 类规则。

4. FINAL 与顺序：先例外，再一般，最后兜底

FINAL 不填写域名或网段，它负责接住前面都未命中的流量。FINAL,DIRECT 表示剩余请求直连，FINAL,PROXY 表示剩余请求走代理。两者适用于不同目标，没有一种能脱离配置目的被称为固定正确答案。

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,DIRECT

这份规则实现“只有接口域名走代理，同站其他域名直连”。请求 api.example.com 会先命中 DOMAIN；请求 www.example.com 不满足第一条，但会命中 DOMAIN-SUFFIX；请求 example.net 则落到 FINAL。

如果加入 DOMAIN-KEYWORD,example,PROXY，还要检查它是否提前覆盖了原本需要直连的域名。审核规则时不要只搜索有没有目标域名，还要从文件前部往后检查所有可能抢先命中的条件。

5. 在 Config 中修改并验证规则

以下片段只演示 [Rule] 段，不是可直接替代现有配置的完整文件。PROXY 使用现有代理选择；若配置引用了自定义策略组名称，还必须确认对应组确实存在。客户端买断 ≠ 线路套餐，购买应用不会自动补齐代理连接参数。

1. 保留原配置：进入 Config，先保留当前文件副本或导出备份，记录当前选用的是哪一份配置。
2. 编辑目标文件：打开需要修改的配置进行编辑，找到现有 [Rule] 段，把一条明确的 DOMAIN 测试规则放在可能覆盖它的规则之前，不要再追加一个重复段落。
3. 保存并选用：确认 Config 当前选用的是修改后的文件，再回到 Home → Global Routing → Config。
4. 准备连接：确认 Home 已选择用户已有的可用连接。若目标策略为 PROXY，可先运行 Connectivity Test，但测试通过不等于网站全部资源可访问。
5. 建立新请求：关闭旧网页后重新打开目标页面；必要时在允许中断连接的情况下重连。已建立的长连接不适合验证刚修改的规则。
6. 核对记录：查看本次请求对应的连接记录，核对目标域名、目标 IP、命中规则及实际策略；每次只改一项，再发起新请求进行比较。

本文使用 example.com 说明语法边界，表格展示的是规则逻辑推演，不是实际网络测速。正式测试应换成用户有权访问且确实使用的目标域名。不要根据页面打开快慢单独判断分流，网络延迟不能证明命中了哪条规则。

6. 访问失败：先分清 DNS、连接与规则

网页报错不等于规则语法错误。先看请求是否命中了预期策略，再检查该策略对应的解析与连接路径。下面两项是 DNS 响应中的标准错误标识，不是 Shadowrocket 固定弹窗文案；应在实际诊断结果出现它们时按相应分支处理。

若已经解析到 IP，连接却超时，应继续区分 DIRECT 与 PROXY 两条路径。命中 DIRECT 时，检查当前网络到目标的可达性；命中 PROXY 时，先确认当前代理可连接，再检查它到目标的路径。把 FINAL 来回切换只能作为受控对照，不能替代定位。

• 命中错误：查 Global Routing、当前配置、规则先后顺序及真实请求域名。
• 命中正确但无法连接：查 DNS、目标端口、已有连接的可用性与目标服务状态。
• 部分页面资源失败：查失败资源各自的域名，不要只检查地址栏中的主域名。

7. 规则写法常见问题