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

一、规则生效前：确认 Global Routing 与配置文件

规则写在配置文件的 [Rule] 段中。只有请求进入按配置分流的处理路径，调整这一段的顺序才有意义。先到 Home → Global Routing 查看当前选项，不要仅根据顶部连接开关判断规则是否生效。

Config 用于管理配置文件，Home 用于查看连接状态和 Global Routing。Settings → On Demand 管理按条件触发连接的行为，它不负责把 DOMAIN 改成其他匹配类型，也不替代规则排序。排查时应把“是否启动连接”与“请求命中哪条规则”分开记录。

二、DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD 的范围

这三类规则检查域名，不检查网页正文，也不按 URL 路径分流。规则中的域名字段不加 https://，不加 /login，也不把端口写进主机名。访问 https://api.example.com:8443/login 时，用于这里域名匹配的对象是 api.example.com。

DOMAIN 适合单独处理一个完整主机名。DOMAIN-SUFFIX 按域名层级覆盖根域与子域，写 example.com 即可，不需要写成 *.example.com。DOMAIN-KEYWORD 检查域名中的关键词，范围比同一个根域更宽，容易把名称相似但归属不同的域名一起纳入。

三、GEOIP 与 IP-CIDR：匹配目标 IP 而非域名文字

GEOIP 根据目标 IP 在地理位置数据库中的归属进行匹配。例如 GEOIP,CN,DIRECT 表示对数据库归为 CN 的目标地址采用 DIRECT。它不依据页面显示的文字、域名后缀或用户所在位置判断，数据库归属也不等于网站运营主体的所在地。

IP-CIDR 匹配 IPv4 地址段。192.0.2.0/24 表示前 24 位固定的网段，覆盖 192.0.2.0 至 192.0.2.255；192.0.2.8/32 只覆盖一个地址。这里的地址属于文档示例范围，不能拿来验证真实服务是否连通。

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

• no-resolve 表示不要仅为了匹配这条 IP 规则而发起域名解析；已有可用目标 IP 时，仍可进行地址匹配。
• 域名请求走到需要 IP 信息的规则时，DNS 解析可能影响后续判断。解析失败不等于规则关键字拼写错误。
• 网站可能返回多个地址，地址也可能变化。为一个临时解析结果写单 IP 规则，不等于覆盖整个网站。
• IP-CIDR 用于 IPv4。不要把 IPv6 地址直接塞进这一关键字并沿用 IPv4 掩码。

上面示例把单地址规则放在整个网段之前。因此目标为 192.0.2.8 时先命中 REJECT，不会再落到后面的网段 DIRECT。这体现的是书写顺序，不是系统自动赋予 /32 更高优先级。

四、自上而下命中即停，FINAL 放在末尾

对本文列出的普通规则，核心判断是从上往下检查，命中后执行该条策略，不再用后面的普通规则重新选择。精确匹配不会自动越过排在前面的宽泛匹配。需要例外时，把例外规则提前。

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

1. 请求 login.example.com 时，第一条已经命中，采用 DIRECT。
2. 请求 img.example.com 时，第一条不匹配，第二条命中，采用 PROXY。
3. 请求 telemetry.example.com 时，第二条先命中，第三条不会再执行。若要拒绝它，应把相应拒绝规则移到第二条之前。
4. 没有命中前面规则的请求最终进入 FINAL,PROXY。FINAL 没有域名或地址字段，语法只有关键字与策略。

把 FINAL 放在前面，会使后面的普通规则失去被检查的机会。维护配置时只保留一个清楚的最终兜底，并把它放在末尾。不要用不断追加重复规则的方式修复顺序问题，应该先找到已经提前命中的那一条。

上面的配置用于解释匹配顺序，不是通用分流清单。应用到已有配置前，应确认每条策略符合自己的需求，并保留原配置副本。

五、PROXY、DIRECT、REJECT 分别做什么

规则的最后一个主要字段决定命中后的处理方式。关键字负责“匹配什么”，策略负责“怎么处理”，两者不能互换。本文以用户已有自己的服务商与连接配置为前提，不提供、不销售、不推荐节点、订阅或其他连接服务。

PROXY 不是协议名。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 属于连接配置涉及的协议，不能直接代替这里的基础策略写法。规则命中 PROXY 也不能证明目标服务可达，连接参数、DNS 与远端状态仍需分别核对。

DIRECT 不代表不经过 Shadowrocket 的规则判断，而是命中后选择直连出站。REJECT 导致页面或资源加载失败可能正是预期结果；如果误拒绝了登录接口，页面主体打开也不代表整站功能正常。

六、在 Config 中修改，再用新请求验证

建议每次只修改一条规则或一次顺序，先验证再继续。订阅更新主要涉及用户已有的服务器列表，不等于已经修改当前启用配置的 [Rule] 段。远程配置再次更新时也可能覆盖本地改动，因此测试前应先保存副本。

1. 保留原配置

   进入 Config，确认当前启用的文件，先保存一份可恢复的副本。记录原来的 Global Routing，避免测试结束后忘记还原。

2. 编辑规则段

   在 Config 中打开目标文件的编辑入口，找到 [Rule]。将单主机例外放在域名后缀之前，将 FINAL 留在末尾，使用英文半角逗号分隔字段。

3. 确认已启用

   保存后在 Config 确认启用的是修改后的文件。回到 Home → Global Routing，选择 Config，并确认 Home 的连接状态。

4. 重新发起请求

   关闭测试页面再重新打开，必要时重建连接，避免沿用已经建立的长连接。观察连接记录中可获得的目标域名、目标 IP、命中规则与策略信息。

5. 核对命中项

   如果策略与预期不同，从命中位置向上检查更宽的规则。若命中正确但访问失败，再检查 DNS、已有代理参数和目标服务，不要继续盲目调整顺序。

七、规则不生效与访问报错的分层排查

先区分“没有按预期命中”和“命中了但连接失败”。前者优先检查 Global Routing、当前文件与规则顺序；后者检查解析和连接过程。Home → Connectivity Test 的结果不能单独证明某个域名的全部网页请求都能完成。

这些是 Apple 网络错误代码的含义，不是 Shadowrocket 在所有界面都会显示的固定提示。若记录中没有这些原文，应按实际错误信息排查，不要把页面转圈直接归类为同一种错误。