Shadowrocket 规则写法入门:DOMAIN、DOMAIN-SUFFIX、GEOIP、IP-CIDR 与 FINAL 各匹配什么

本文速览

Shadowrocket（小火箭）的规则由匹配条件和处理策略组成。本文适合已经有自己的连接配置、准备在 Config 中修改分流规则的用户：先区分域名与 IP 匹配，再检查规则先后顺序，最后用具体请求确认命中结果。示例域名与地址仅用于解释语法，不是可用的连接服务。

一、先确认规则在哪种模式下生效

在 Home 中查看 Global Routing。本文讨论的是选择 Config 后，按当前配置中的规则决定出站的情况。Proxy 以代理为主处理流量，Direct 以直连为主处理流量；不要在这两种模式下，仅凭网页能否打开就判断某条 Config 规则是否生效。Scene 用于场景化选择，需要另行核对场景条件与实际采用的路由设置。

规则决定的是“这次连接交给谁处理”，不是“代理服务器能否连接”。即使规则正确命中 PROXY，已有服务器不可用时，请求仍然可能失败。DIRECT 也只是选择直连，不保证目标网站一定可以从当前网络访问。

请求进入隧道读取目标信息依次检查规则采用命中策略建立出站连接

理解一行规则时，可以先把它拆成三部分。下面的第二段是匹配值，第三段是策略；FINAL 不需要匹配值，因此只有两段。英文逗号是字段分隔符，不要换成中文逗号。

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

DOMAIN：匹配类型，要求目标域名完全一致。
api.example.com：匹配值，不包含协议、端口和 URL 路径。
PROXY：交给代理策略处理，仍需已有可用的代理配置。
FINAL,DIRECT：前面的规则均未命中时，采用直连。

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

这三类关键字都以域名为匹配对象，但覆盖范围不同。拿到一个完整网址时，应先取主机名。例如 https://api.example.com:8443/v1/status 的主机名是 api.example.com；8443 是端口，/v1/status 是路径，不能一起塞进 DOMAIN 的匹配值。

关键字	示例规则	匹配范围
DOMAIN	`DOMAIN,api.example.com,PROXY`	仅匹配 api.example.com，不包含其下级子域。
DOMAIN-SUFFIX	`DOMAIN-SUFFIX,example.com,PROXY`	匹配 example.com 以及 api.example.com 等子域。
DOMAIN-KEYWORD	`DOMAIN-KEYWORD,example,PROXY`	匹配域名中含有 example 字符串的目标，范围更宽。

精确主机、整组子域与关键词

只让一个 API 主机走代理时，先用 DOMAIN；需要覆盖同一域名下的主站、图片站和接口站时，用 DOMAIN-SUFFIX 更容易维护。后缀按域名层级匹配，example.com 不会因此匹配 notexample.com，也不会匹配 example.com.other.test。

DOMAIN-KEYWORD 是字符串包含判断。关键词 example 可以覆盖不同后缀中的同一段文字，也可能把无关域名包含进来。它并不理解网站归属、品牌关系或网页内容。能用精确域名表达需求时，不必为了缩短规则而换成宽泛关键词。

三、IP-CIDR 与 GEOIP 匹配目标 IP

IP-CIDR 根据目标 IP 是否落在指定网段内判断；GEOIP 根据 IP 地理数据库中的归属判断。它们与网页语言、域名后缀、账户地区不是一回事。域名访问可能需要先取得解析结果，才能进行相应的 IP 判断；直接访问 IP 时，则没有可供普通域名规则匹配的主机名。

[Rule]
IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

192.168.50.0/24 表示 IPv4 网段，覆盖 192.168.50.0 至 192.168.50.255 的地址范围，不表示“端口 24”。
no-resolve 表示不要仅为这条 IP 规则主动解析域名；不能把它理解为关闭全部 DNS，也不能把它当作直连开关。
GEOIP,CN,DIRECT 表示数据库将目标 IP 归入 CN 时采用 DIRECT，而不是“中文网站直连”。
IPv6 网段应使用对应的 IP-CIDR6 写法，不要把 IPv6 地址当作 IPv4 网段填写。

上面的局域网网段只是语法示例。实际路由器可能使用 192.168.1.0/24 或其他地址段，应按当前网络填写。不要为了覆盖一个设备而随意加入更大的网段，否则其他地址也会落入同一策略。

GEOIP 的结果依赖数据库与目标 IP。使用 CDN 的网站可能在不同网络下解析到不同地址，DNS 修改后也可能改变归属判断。因此，“昨天走 DIRECT，今天走 PROXY”并不自动说明规则文件损坏，应该同时核对域名、解析结果与命中规则。

四、规则自上而下检查，FINAL 放在最后

在本文这类普通规则列表中，按从上到下的顺序检查，首条匹配的规则决定处理策略。它不是“所有规则里最精确的一条自动获胜”。如果宽泛规则先命中，后面的精确规则便没有机会覆盖它。

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

在上述示例中，api.example.com 先命中 DOMAIN，采用 PROXY；www.example.com 没有命中第一行，但命中第二行，采用 DIRECT。如果把前两行交换，API 主机也会先被 DOMAIN-SUFFIX 捕获。这正是“先写例外，再写通用范围”的理由。

目标	首条命中规则	策略
`api.example.com`	DOMAIN	PROXY
`www.example.com`	DOMAIN-SUFFIX	DIRECT
其他域名，目标 IP 归入 CN	GEOIP	DIRECT
其他域名，且未命中 GEOIP	FINAL	PROXY

只让列出的域名走代理

如果目标是“仅指定网站走代理，其余直连”，可以从下面的最小片段开始。这里没有加入 GEOIP，因为此目标不需要按地区增加另一层判断。规则少并不代表功能不完整，关键是策略能否准确表达需求。

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

五、在 Config 修改后，用新连接验证

开始前应已经有自己的服务商与可用配置。规则编辑不需要重新购买客户端，也不要求更换协议；Shadowsocks、VMess、VLESS、Trojan 等协议负责代理连接，本节关键字负责决定请求是否交给代理。两者处于不同层次。

保留原配置

进入 Config，先保留当前配置副本或导出备份，记录正在使用的配置。远程配置更新可能覆盖本地修改，不要只在唯一副本上反复试验。
编辑规则段

在 Config 中打开目标配置的编辑入口，定位 [Rule]。在已有规则段内调整内容，不要把整个示例重复贴到文件末尾形成多个同名段。
检查字段顺序

使用英文逗号，域名字段去掉 https://、端口与路径。精确例外放在通用规则前，FINAL 放在末尾，确认策略名称没有拼写错误。
启用目标配置

保存并选用刚修改的配置，返回 Home → Global Routing → Config。再确认 Home 中选择的是已有可用服务器，避免把连接故障当成规则问题。
建立新请求

重新建立连接后访问测试目标，在 Data 中核对新请求的目标、策略与命中信息。旧连接可能沿用原有出站，不能只刷新一个持续复用连接的页面就下结论。

每轮只修改一个条件。例如先验证精确 DOMAIN，再扩大为 DOMAIN-SUFFIX，最后才增加 IP 判断。记录预期策略和实际策略，比一次加入几十条规则更容易定位问题。测试示例域名只用于解释语法，实际验证应换成自己确实需要访问的目标。

六、按“是否命中”和“能否连接”分别排查

排查时先看 Data 中的新请求是否采用预期策略，再检查目标能否连接。如果命中策略错误，回查当前 Config、Global Routing 与前置规则；如果策略正确却超时，继续检查代理连通性、DNS 与目标服务器，不要立即把规则改成更宽的关键词。

下列是 Apple 网络错误的标准标识，可能出现在系统或应用的详细错误信息中；不同请求入口展示的文字可以不同。它们描述连接失败，不是 Shadowrocket 规则语法错误提示，也不能单凭错误码判断应该使用 DIRECT 还是 PROXY。

NSURLErrorDomain Code=-1001

原因：请求超过等待时间，可能发生在代理连接或目标响应阶段。

解法：先核对 Data 中采用的策略，再分别验证当前服务器与同一目标的可达性，避免仅通过调整规则顺序掩盖超时原因。

NSURLErrorDomain Code=-1003

原因：无法找到指定主机，优先检查域名拼写与 DNS 解析条件。

解法：确认请求主机名正确，再核查当前 DNS 设置；给域名增加 PROXY 规则并不等于修复了域名解析。

写了 DOMAIN-SUFFIX，为什么还是直连？

先到 Home → Global Routing 确认选择 Config，再核对 Config 中选中的文件。若两项都正确，检查该规则之前是否已有 DOMAIN、其他后缀规则或 FINAL 抢先命中，并用 Data 核对实际请求的主机名。

一个网站打开了，图片却加载不出来？

网页与图片可能来自不同域名。重新加载后查看 Data 中失败资源对应的主机，按实际用途补充精确规则；不要根据页面地址推断全部资源都使用同一个 DOMAIN-SUFFIX。

给 IP-CIDR 加 no-resolve 后怎么不命中了？

如果请求以域名发起、当时没有可用于匹配的目标 IP，这条规则不会为了判断网段而主动解析。明确需要按域名分流时直接写域名规则；确实需要按解析 IP 判断时，再评估是否保留 no-resolve。

改了规则，重连后却又恢复成原来的内容？

先确认编辑的是当前启用文件，再核对是否发生了远程配置更新。连接订阅与规则配置不是同一份内容；应保留本地修改副本，并在更新后检查规则差异。Settings → On Demand 控制按需连接，不负责保存或恢复规则。

最终检查可以收敛为四项：Global Routing 处于 Config、当前配置确实包含修改、首条命中规则符合预期、对应出站能够建立连接。按这个顺序验证，才能分清语法、顺序、DNS 和线路状态各自造成的影响。