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

1. 先选 Config，再讨论规则是否生效

Shadowrocket（小火箭）的规则不是打开连接后就必然逐条执行。先在 Home 查看 Global Routing：要使用当前配置文件里的规则，应选择 Config；同时到 Config 确认实际启用的是刚刚编辑的配置，而不是另一个同名文件。

Home 负责服务器选择与连接，Config 管理配置文件，Settings 提供应用设置。Settings → On Demand 影响按条件建立连接的行为，不会把一条 DOMAIN-SUFFIX 自动改成其他策略。排查时先区分“连接是否建立”和“连接建立后走哪条规则”，不要同时修改两类设置。

2. 规则从上向下，首次命中就决定策略

常见规则行由英文逗号分隔，基本结构是“规则类型、匹配内容、策略”。FINAL 没有匹配内容，结构为“FINAL、策略”。规则按顺序检查，一旦命中便使用对应策略，不会继续寻找后面看起来更精确的规则。因此，“精确例外在前、宽泛范围在后、FINAL 在最后”是组织配置的重要原则。

DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

这三行中，api.example.com 命中第一行并选择 PROXY；www.example.com 不符合第一行，但符合第二行，因此选择 DIRECT。若把第二行移到第一行之前，api.example.com 也会被后缀规则先接住，原来的精确例外就无法执行。顺序错误不会必然产生语法报错，却会直接改变结果。

3. DOMAIN、DOMAIN-SUFFIX 与 DOMAIN-KEYWORD 的边界

域名规则匹配的是连接可用的域名信息，不是完整网页地址。填写匹配内容时不带协议头、端口、路径或查询参数。例如访问一个带有 /account 路径的页面时，DOMAIN 仍然只判断主机名，不能用它区分同一主机下的两个页面。

如果只想让 api.example.com 使用代理，优先用 DOMAIN，而不是用 api 作为 DOMAIN-KEYWORD。后者可能同时覆盖其他无关域名。需要覆盖一个域名及其所有子域时，再选择 DOMAIN-SUFFIX；不要把通配符写成 *.example.com 来代替这里的后缀语法。

• 匹配一个完整主机名：用 DOMAIN。
• 匹配主域名及下属子域：用 DOMAIN-SUFFIX。
• 确实需要按字符串扩大覆盖范围：用 DOMAIN-KEYWORD，并检查误命中的可能。
• 只知道目标 IP、没有可用域名信息时：转而检查 IP 类规则，不要假设域名规则一定参与匹配。

4. IP-CIDR、GEOIP 与 DNS 的关系

IP-CIDR 按地址网段匹配，GEOIP 按 IP 地理数据库的归属结果匹配。它们判断的都是地址信息，不是网页语言、账号地区，也不是域名末尾的国家或地区后缀。某个域名使用了某种后缀，并不能据此断定它会命中 GEOIP 的哪个地区代码。

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

192.0.2.0/24 是文档示例网段，/24 表示前 24 位为网络前缀，覆盖 192.0.2.0 至 192.0.2.255；它不是可用服务器地址。IP-CIDR 匹配整个地址范围，不是只匹配文本里出现的 192.0.2.0。IPv6 网段应使用对应的 IP-CIDR6 规则类型，不要把 IPv6 地址硬写进 IPv4 示例。

当域名规则没有命中、后续 IP 规则需要地址信息时，DNS 状态可能影响匹配过程。GEOIP 的结果也取决于实际目标地址与数据库内容，不能保证覆盖某类网站的全部资源。排查时应记录具体域名、实际地址与命中策略，而不是只记录“某个应用打不开”。

5. 用最小规则集理解 FINAL 与策略结果

下面是用于阅读与试验的完整规则段，不是面向所有网络的配置推荐。使用前保留自己的完整配置与服务器设置，只在副本里调整规则；不要把只有 [Rule] 的片段当作包含全部连接参数的新配置。

[Rule]
DOMAIN,blocked.example.com,REJECT
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
DOMAIN-KEYWORD,metrics,REJECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

• blocked.example.com 首先命中 REJECT，不会再进入后面的 example.com 后缀规则。
• api.example.com 命中第二行，使用 PROXY；实际能否连接还取决于代理服务器状态。
• metrics.example.com 先命中 DOMAIN-SUFFIX，因此使用 DIRECT，而不是后面的 REJECT。
• 其他域名若包含 metrics，且没有被更早规则接住，才会命中 DOMAIN-KEYWORD。
• 前面均未命中的连接由 FINAL,PROXY 兜底；FINAL 不应放在仍需检查的规则之前。

如果想让 metrics.example.com 也被拒绝，可以在后缀规则之前增加精确 DOMAIN 例外；若把整个关键词规则上移，则所有包含 metrics 的域名都可能提前被拒绝。修改时应先明确所需范围，再选择“增加精确例外”或“移动宽泛规则”，避免为了修复一个域名扩大影响范围。

6. 在当前配置中修改并验证

1. 保留原配置

   进入 Config，先保留当前可用配置的副本，再打开待修改文件的编辑入口。记录文件名与原来的 Global Routing，方便回退。

2. 核对规则段

   在配置文本中定位 [Rule]，使用英文逗号逐行编辑；精确例外放在对应宽泛规则前，FINAL 放在最后。不要重复粘贴多个 [Rule] 段来代替整理顺序。

3. 启用并选模式

   保存后，在 Config 确认使用此文件；返回 Home → Global Routing → Config。只保存文件而没有选用它，不能验证刚才的修改。

4. 核对出站

   在 Home 选中已有服务器并运行 Connectivity Test，先确认代理出站具备连接条件。服务器与订阅信息从你的服务商处获取，规则文本不能代替这些参数。

5. 新建连接验证

   重新发起目标请求，在应用的连接记录中核对目标、命中规则与出站策略。一次只改一项；旧连接可能继续复用，必要时停止旧请求，再重新连接测试。

Connectivity Test 检查的是连接能力，不能单独证明某个网站命中了指定规则。规则验证应以具体请求的记录为准。还要区分服务器订阅与规则配置：更新 Home 中的服务器列表，不等于当前 Config 里的规则也随之更新；远程配置重新更新后，本地修改是否保留也应再次检查。

7. 区分规则错误与出站错误

规则已命中 PROXY 但网页仍无法打开，并不必然说明语法错误。下面列出连接日志中常见的网络错误片段；完整错误文本可能带有地址、端口与底层说明，遇到时先核对它发生在目标连接还是代理服务器连接阶段。

例如服务商给出的服务器端口为 443，就应核对服务器设置中的端口是否确为 443；不能因为某份规则示例出现了 443，就擅自替换原有端口。DOMAIN-SUFFIX 本身不包含端口字段，服务器监听端口与域名匹配条件属于不同层次。

8. 规则配置常见问答