· 规则分流 · 约 12 分钟

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

逐条拆解六类规则关键字各自匹配什么、规则自上而下的匹配顺序，以及 FINAL 兜底规则为什么必须放在最后一行。

本文速览

本文适合已经在 iPhone 或 iPad 上使用 Shadowrocket、拥有自己的服务器信息或订阅，但不清楚规则为什么命中或失效的用户。先核对 Global Routing 与当前配置，再区分域名匹配、IP 匹配和 FINAL 兜底；读完可以写出一份最小规则片段，并按请求记录检查实际去向。所有示例域名与保留地址仅用于说明，不提供连接服务。

一、规则生效的前提：Global Routing 与当前配置

Shadowrocket（小火箭）的规则不是服务器列表。Home 中选择的服务器决定代理连接所用的出口，Config 中的配置承载规则等设置；导入或更新自己的订阅，并不等于已经切换到预期的规则配置。排查前需要分别核对这两部分。

在 Home 查看 Global Routing。本文讨论的是选择 Config 后，由当前配置逐条判断请求的情况。Proxy 与 Direct 是全局路由姿态，不能拿它们的访问结果直接证明某一条配置规则已经命中。Scene 按所选场景设置工作，也不应当作 Config 的同义项。

设置项核对含义本文测试方式
Config按当前配置执行规则分流。选择此项，再检查当前配置是否正确。
Proxy采用全局代理路由姿态。可用于隔离出口问题，不作为逐条规则验证结果。
Direct采用全局直连路由姿态。可对照直连表现，测试结束后恢复 Config。
Scene按场景配置决定相应行为。先确认场景设置；初次测试规则时改用 Config。

二、规则语法与顺序：先命中，先执行

常见规则由英文关键字、匹配内容和策略组成，字段之间使用半角逗号。FINAL 不需要匹配内容，因此只有关键字和策略两个主要字段。DIRECT 表示直接连接；下文的 PROXY 表示交给代理出站，使用前仍须确认当前代理选择有效。如果填写自定义策略组名称，该名称必须能在配置中找到。

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

这只是说明语法的片段，不是可直接连接的完整配置。Shadowrocket 按从上到下的顺序检查规则，遇到第一条满足条件的规则便采用对应策略，不会继续寻找“更具体”的另一条。因此，精确规则并不会自动获得比宽泛规则更高的优先级。

请求进入逐条匹配首条命中执行策略建立连接

以上例为例，当请求带有域名 login.example.com 时，第一行已经命中，结果为 DIRECT。若把 DOMAIN-SUFFIX 放到 DOMAIN 前面，login.example.com 会先被后缀规则命中并交给 PROXY，下面的精确规则便没有机会处理这次请求。

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

这三种关键字都针对域名，但覆盖范围不同。规则里填写的是主机名或关键字，不是完整网址：不要附上 https://、网页路径、查询参数或端口。访问 login.example.com 的 443 端口，并不意味着 DOMAIN 的匹配内容要写成 login.example.com:443。

规则示例能够命中不会命中
DOMAIN,example.com,DIRECTexample.comwww.example.com、example.com.test
DOMAIN-SUFFIX,example.com,PROXYexample.com、www.example.com、a.b.example.comnotexample.com、example.com.test
DOMAIN-KEYWORD,example,PROXYexample.com、myexample.test、example.net不包含 example 的域名

DOMAIN：只处理一个完整主机名

需要把 api.example.com 与 www.example.com 分开时，使用 DOMAIN 最容易审阅。它不会隐含覆盖子域，DOMAIN,example.com,DIRECT 不会顺带处理 api.example.com。为一个应用写规则时，还应注意应用可能同时请求登录、接口、图片等多个主机名，不能只凭首页域名推断所有请求的去向。

DOMAIN-SUFFIX：按域名层级覆盖

DOMAIN-SUFFIX,example.com,PROXY 同时覆盖根域和其下各级子域，不需要添加通配符。它不是任意字符串后缀搜索：notexample.com 虽然末尾包含相同字母，但缺少域名层级边界，不属于 example.com 的子域。

DOMAIN-KEYWORD：按包含关系扩大范围

DOMAIN-KEYWORD 不要求关键字位于某一层域名边界，适合确实需要覆盖包含某字符串的多个域名的情况，也更容易产生意外命中。例如 example 会匹配 myexample.test。只想处理 example.com 这一组域名时，应优先使用 DOMAIN-SUFFIX，而不是用更宽的关键字代替。

四、GEOIP 与 IP-CIDR：匹配的是目标地址

GEOIP 按目标 IP 在地址数据库中的地区归属进行判断。GEOIP,CN,DIRECT 的含义是：目标 IP 被数据库归类为 CN 时使用 DIRECT。它不检查域名注册地或用户所在地区，也不保证某个品牌的所有服务始终使用同一地区地址。

IP-CIDR 则针对明确的 IPv4 网段。IP-CIDR,192.0.2.0/24,DIRECT 覆盖 192.0.2.0 到 192.0.2.255；其中 /24 表示前 24 位为网络前缀，不是端口号。192.0.2.0/24 是文档保留地址范围，此处只用来解释匹配，不能当作可用服务器。

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

IP 规则是否需要先解析域名，会影响排查过程。可选参数 no-resolve 表示不要仅为这条 IP 规则主动发起域名解析；若已经掌握目标 IP，仍可按地址判断。因此它不是“关闭 DNS”，也不表示网页从此不再需要解析。若尚无目标 IP，该条规则可能跳过，让后续规则继续判断。

五、FINAL 为什么必须放在最后

FINAL 是兜底规则：前面的规则都没有命中时，采用它指定的策略。它没有域名或网段限制，因此把它放到中间，会截住所有走到这一行的请求，使下面的规则无法再参与判断。“最后”指整个有效规则序列的末尾，不只是当前编辑窗口里看起来的最后一段。

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

FINAL,PROXY 与 FINAL,DIRECT 都是明确的兜底选择，不存在适合所有人的固定答案。前者让未分类请求交给代理，后者让未分类请求直连。采用前者需要有效代理出口；采用后者则要接受未知目标直接连接的结果。修改前应先确认自己的使用目标，而不是只看能否打开一个网页。

“规则写得更精确，为什么还是没命中？”

先查看它上方是否已有 DOMAIN-SUFFIX、DOMAIN-KEYWORD 或 FINAL。把需要优先处理的 DOMAIN 例外移到宽泛规则前，再重新发起连接核对。

“FINAL 后面能再补一条规则吗？”

文本可以继续添加，但该规则不会处理已经被 FINAL 接住的请求。把新增规则移到 FINAL 前，并保留一条清晰的最终兜底。

“把 FINAL 改成 DIRECT 就算修好了吗？”

不一定。这可能只是绕开了不可用的代理出口。回到 Home 核对当前服务器，再检查预期域名是否应由更具体的规则处理。

“订阅更新后，规则也会一起变吗？”

服务器订阅更新与规则配置更新是不同操作。先在 Config 确认当前配置，再检查更新的到底是服务器列表还是配置文件；不要把列表刷新成功当作规则已更新的证据。

六、最小验证步骤：一次只改一条规则

验证要同时记录“预期策略”和“实际请求”。网页能打开只能说明某次请求成功，不能单独证明它走了 DIRECT 还是 PROXY。以下步骤不要求更换自己的订阅，也不要求调整协议参数；Shadowsocks、VMess、VLESS 等出口协议与规则关键字属于不同层面。

  1. 保留原配置

    在 Config 确认当前配置，修改前保留可恢复的副本或原始文本。记录原来的 FINAL 策略，不直接覆盖唯一可用配置。

  2. 确认路由姿态

    在 Home → Global Routing 选择 Config，再回到 Config 确认启用的是准备测试的配置，而不是另一份同名或远程配置。

  3. 添加精确例外

    在当前配置的规则部分，为自己能够核对的真实目标添加一条 DOMAIN 规则，放在宽泛规则与 FINAL 前。本文的 example.com 仅作语法说明，不作为代理连通性测试目标。

  4. 重新发起请求

    保存并确保配置生效后，结束目标应用已有连接，再发起新请求。保持 Home 中选择的服务器不变，避免连接复用或出口变化干扰判断。

  5. 核对请求记录

    在请求记录或日志中核对主机名、目标 IP、命中规则及实际策略，以界面提供的字段为准。记录不足时先启用相应记录功能，再重复同一请求，不凭延迟数值推断出口。

七、规则命中后仍失败：按错误层次排查

规则负责选择去向，不保证目标、DNS 与代理服务器始终可用。请求记录已经显示预期规则命中时，应继续检查后面的连接环节。下列是网络诊断中可能遇到的错误原文，不是规则语法错误提示；具体显示形式取决于错误来自哪一层，不能只凭一行文字认定是规则问题。

报错：Connection refused

原因：某一连接端点拒绝了连接，可能是目标端口或代理服务器端口没有对应服务。

解法：先从记录确认被连接的地址与端口，再核对 Home 中该服务器的端口是否与自己已有的服务信息一致；若失败发生在目标端，检查目标服务而不是扩大域名规则。

报错：Operation timed out

原因：相关操作没有在等待时间内完成，可能涉及网络链路、代理连接或目标响应，单凭超时无法确定是哪一段。

解法：结合错误前后的连接记录定位阶段，在 Home → Global Routing 临时切换 Proxy 或 Direct 作对照，完成后恢复 Config，并保持测试目标相同。

报错：No route to host

原因：连接使用的网络路径无法到达目标地址，不等于 DOMAIN 或 FINAL 的字段写错。

解法：核对当前网络是否可用、实际目标 IP 与地址族是否符合预期，再检查请求最终走的是 DIRECT 还是代理出口，按对应路径处理。

如果是域名解析阶段失败，应先核对 DNS 请求是否成功；如果是服务器认证失败，应核对自己的服务器参数。不要通过把所有请求都改成 DIRECT 来掩盖这些问题，也不要为了某一个报错同时重写整份规则。保留对照条件，才能确定修复是否真正生效。

App Store 正版入口先核对，再购买