Shadowrocket 规则按列表从上到下检查,第一条命中决定去向,FINAL 处理此前未命中的请求。本文适合在 iPhone / iPad 上使用 Shadowrocket(小火箭)、已有自己的服务商与配置、准备编辑 Config 的用户;Mac、Windows、安卓、Linux 用户也可参考匹配原理,但具体编辑入口应以当前平台界面为准。读完可以区分六类条件,写出带例外与兜底的规则,并用新建连接验证结果。
1. 规则结构与 Global Routing 前提
规则不是连接参数,也不是按应用名称自动识别用途的清单。它读取当前请求可用的域名、目标 IP 等信息,选出一个策略。要让配置文件中的规则参与分流,在 iPhone / iPad 的 Home → Global Routing 中选择 Config;仅修改 Config 文件、却保持 Proxy 或 Direct,并不能按本文预期验证规则。
[Rule]
DOMAIN,example.com,DIRECT
DOMAIN-SUFFIX,example.org,PROXY
FINAL,DIRECT
多数条件规则由“类型、匹配内容、策略”三部分组成,使用英文逗号分隔。FINAL 没有匹配内容,因此写成两部分。DIRECT 表示直接连接;PROXY 表示交给代理路径,不是把用户已有服务器的地址或密码写在这一列。引用配置中的自定义策略名称时,名称必须与实际定义一致。
结论:先确定默认去向,再写例外
先决定未匹配请求应当 DIRECT 还是 PROXY,把对应 FINAL 放到末尾,再在它上方添加范围明确的例外;不要用大量关键词规则代替明确的默认策略。
- Config:按当前启用配置中的规则选择去向,是本文操作的前提。
- Proxy:全局代理姿态,不用于验证某条 DIRECT 规则是否生效。
- Direct:全局直连姿态,不用于验证某条 PROXY 规则是否命中。
- Scene:按已配置的场景条件切换,排查时需要继续确认场景最终使用的配置与策略。
2. DOMAIN、DOMAIN-SUFFIX 与 DOMAIN-KEYWORD
三种域名规则的差别在于匹配边界。DOMAIN 要求完整域名一致;DOMAIN-SUFFIX 匹配指定域名本身及其下级子域名;DOMAIN-KEYWORD 检查域名中是否包含指定字符串。它们都不用于匹配 URL 路径,因此不能靠加入 /video/ 来区分同一域名下的网页栏目。
| 写法 | 会命中 | 不会命中 |
|---|---|---|
DOMAIN,example.com,DIRECT |
example.com |
www.example.com |
DOMAIN-SUFFIX,example.com,PROXY |
example.com、cdn.example.com |
notexample.com、example.com.other.test |
DOMAIN-KEYWORD,example,PROXY |
example.com、notexample.net |
sample.test |
例如,希望整个 example.com 使用代理,但让它的登录主机直连,应当先写完整域名例外,再写后缀规则。DOMAIN-SUFFIX 不需要写成 *.example.com;星号不是这里表达子域名范围的必要语法。
[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT
这段配置中,login.example.com 在第一行已经命中,不会继续交给第二行。img.example.com 不符合第一行,但符合第二行。若把两行对调,后缀规则先接管请求,完整域名例外便失去作用。所谓“精确规则优先”,是编辑者安排的顺序,不是系统自动替所有规则排序。
3. GEOIP 与 IP-CIDR:目标地址条件
GEOIP 根据目标 IP 在所用地理数据库中的记录进行匹配。GEOIP,CN,DIRECT 表示对被数据库归入 CN 的目标 IP 使用 DIRECT,不表示按设备位置或域名后缀判断。域名使用了分布式部署时,不同解析结果可能落在不同地区,规则结果也可能随之变化。
[Rule]
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY
IP-CIDR 按地址段匹配。192.168.0.0/16 覆盖从 192.168.0.0 到 192.168.255.255;10.0.0.0/8 覆盖从 10.0.0.0 到 10.255.255.255。这两行只举例说明部分私有 IPv4 网段,并不是完整的本地网络规则集。
| 条件 | 所需信息 | 检查要点 |
|---|---|---|
GEOIP,CN,DIRECT | 目标 IP 与地理数据库记录 | 数据库记录不等于实时物理位置证明。 |
IP-CIDR,192.168.0.0/16,DIRECT | IPv4 目标地址 | 检查实际目标是否在指定前缀范围内。 |
no-resolve | 匹配时已经可用的目标 IP | 避免仅为了该条 IP 规则额外触发域名解析。 |
no-resolve 不是“禁止所有 DNS 查询”,也不是“始终直连”的开关。当请求只有域名、尚无可用 IP 时,带这个选项的 IP 规则不会为了匹配主动解析域名,请求可能继续向后检查。IPv6 地址段需要使用对应的 IP-CIDR6 规则,不能把 IPv6 前缀直接当成上述 IPv4 示例的匹配对象。
- 某个固定内网地址要直连:先确认真实地址,再使用适合的 IP-CIDR 范围。
- 某个域名必须按指定策略处理:优先写域名规则,不依赖它当前解析到哪个地区。
- IP 规则没有命中:同时核对目标地址、地址族、解析时机与前面是否已有命中规则。
4. FINAL 位置与完整规则片段
FINAL 是无条件兜底,必须放在规则列表末尾。放在中间时,后续条件即使写得正确,也没有机会处理此前已经被 FINAL 接走的请求。FINAL 选择 DIRECT 或 PROXY,是默认路由策略的区别,不存在适合所有配置的统一答案。
[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example-cdn,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY
这是覆盖本文六种类型的语法示例,不包含服务器与策略组定义,也不代表可直接连接的完整配置。示例域名只用于说明语法;测试时应换成自己明确知道用途与实际地址的域名。PROXY 能否建立连接,仍取决于用户已有代理配置的有效性。
login.example.com:第一条命中,选择 DIRECT。static.example.com:第二条命中,选择 PROXY,不再检查 GEOIP。192.168.1.20:若此前没有域名规则命中,进入私有网段规则,选择 DIRECT。- 其他请求:先尝试其余条件,全部不匹配时由 FINAL 选择 PROXY。
5. 在 Config 中修改与验证
以下步骤按 iPhone / iPad 的 Home、Config 界面说明。操作前保存现有配置副本;不要把整个配置替换成只有 [Rule] 的片段。如果现有配置已经包含该段,应在原段内调整,不重复新增同名段。远程配置再次更新时可能覆盖本地修改,需要先分清正在编辑的是本地副本还是更新来源。
-
保存副本
进入 Config,找到当前使用的配置,先保存原内容。记录文件名称,后续确认启用与编辑的是同一个文件。
-
编辑规则
在 Config 打开目标配置的编辑入口,定位
[Rule]。加入一条明确域名规则,并确认 FINAL 仍在列表最后。 -
启用配置
保存后在 Config 确认选中修改过的配置,再回到 Home → Global Routing → Config,避免仍处于 Proxy、Direct 或其他场景状态。
-
新建请求
断开后重新连接,关闭测试页面的旧连接,再访问目标域名。检查连接记录中的目标、匹配规则与最终策略;不要只看网页能否打开。
-
逐项复核
分别验证精确域名、同域子域名和未匹配域名。每轮只改一个条件或顺序,记录差异;发生异常时恢复副本,再缩小测试范围。
已有 TCP 长连接或复用连接可能继续沿用建立时的路径,规则保存后不一定会立刻迁移它们。浏览器显示的页面还可能来自缓存。因此,“刷新一次页面看起来没有变化”不足以证明规则未生效,应该结合新建连接的记录判断。
- 订阅与规则分开核对:在 Home 更新已有 Subscribe 内容,通常是刷新服务器资料,不应据此认定当前 Config 的规则也已更新。
- 自动连接与分流分开核对:Settings → On Demand 管理自动连接条件,不等于选择了 Config 分流姿态。
- 协议与匹配分开核对:Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 描述不同的连接协议;域名规则不会把某种协议自动转换为另一种协议。
6. 不命中与连接报错的排查顺序
先区分“规则选择错了”和“选对路径但连接失败”。目标网页可能同时请求主站、图片、登录与接口等多个域名;只给主站写 DOMAIN,并不保证资源域名也走相同策略。遇到部分内容加载失败,应从失败连接的实际目标域名开始核对,而不是直接扩大为关键词匹配。
报错:connection refused
原因与解法:这类底层连接错误表示连接被拒绝,可能是目标端口未监听或路径上的设备主动拒绝——先核对失败连接的实际地址、端口和已选策略;若已正确命中 PROXY,再检查用户已有服务器的连接参数,不要只修改 DOMAIN 规则。
报错:i/o timeout
原因与解法:这类底层超时表示相应网络操作未在期限内完成,不能单凭它判定规则语法错误——先在连接记录确认走 DIRECT 还是 PROXY,再分别检查 DNS、目标可达性与所选代理路径;日志完整措辞可能随协议与平台而不同。
上述错误只有在实际连接记录出现时才用于对应排查,它们不是“规则未命中”的专用提示。如果记录显示 FINAL,说明前面的条件没有接管这个请求;应检查实际域名是否一致、请求是否直接使用 IP、IP 条件是否受解析时机影响,以及配置是否真正启用。
| 观察到的现象 | 优先检查 | 具体调整 |
|---|---|---|
| 所有请求都走代理 | Home → Global Routing 是否为 Proxy | 切换为 Config,再用新连接验证。 |
| 登录域名例外没有生效 | DOMAIN-SUFFIX 是否排在例外之前 | 把精确 DOMAIN 放到后缀规则上方。 |
| 所有请求都显示 FINAL | 实际目标、启用文件、FINAL 位置 | 确认文件选中,移除前置 FINAL,并检查目标信息。 |
| 域名能匹配,IP 规则不命中 | 解析结果、地址族与 no-resolve | 核对实际目标 IP,不把 IPv6 当成 IPv4 测试。 |
| 修改后短时间仍走旧路径 | 旧连接复用与页面缓存 | 重建连接后查看新的匹配记录。 |
需要继续扩展时,可查阅规则参考,但先保留一份小而可解释的规则列表。每新增一条都明确其匹配对象、预期策略与放置理由,比一次加入大量无法核对来源的规则更便于定位问题。