Shadowrocket 规则手册

02 / 运行前提

General、DNS 与 Global Routing

General 中的设置为连接和名称解析提供基础条件，Rule 则在这些条件下决定请求策略。遇到“规则正确但访问失败”时，不能只看 Rule：域名是否解析成功、服务器本身是否可达、系统是否已将连接交给 Shadowrocket，都可能先于目标规则影响结果。理解这些前提，可以把规则问题与网络问题分开，避免通过增加更多规则掩盖真正原因。

三种运行模式分别检查什么

Global Routing 中的 Config、Proxy、Direct 是运行姿态，不是三个可以同时启用的规则段。配置姿态 Config 按当前配置进行分流；代理姿态 Proxy 将普通转发流量交给代理路径；直连姿态 Direct 使用直连路径。系统路由、排除项以及具体连接限制仍可能影响实际流量，所以模式名称不能代替请求记录。测试 Rule 时应明确选择 Config，再观察目标请求的处理结果。

例如，同一目标在 Proxy 可以访问，在 Config 却失败，检查重点应转向命中策略、所用策略对应的服务器以及解析差异。若两种姿态都失败，先确认已有服务器信息和基础连接，不宜直接认定是 DOMAIN-SUFFIX 写错。Direct 的成功也只说明直连路径在当时可用，不代表某条代理规则已经正确生效，更不代表所有相关资源都采用了相同路径。

DNS 设置不是策略替代品

[General]
dns-server = system

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

dns-server = system 表示使用系统提供的解析设置，是理解配置结构的简单起点，并非对所有网络的统一推荐。实际解析行为还与其他 DNS 选项、请求类型和当前连接环境有关。维护已有配置时，不应为了复制这个片段而删除原有 DNS 设置；应先记录现值，再用单一改动比较结果，必要时恢复。一次同时修改 DNS、规则与服务器，会失去判断依据。

域名规则比较的是名称，地址规则比较的是地址，两者之间可能出现解析过程。如果日志只显示地址，不能据此假定客户端始终掌握原始域名；如果日志显示域名，也不能据此认为后续连接不会失败。应把解析结果和连接结果分别记录。出现域名无法解析时，先检查解析链路；出现解析正常但连接超时时，再检查策略出口和目标连通性。

绕过项与按需连接的边界

已有文件中的绕过或排除设置可能让部分流量不进入预期的规则路径。这类设置与 Rule 中的 DIRECT 不完全相同：DIRECT 是规则命中后的策略，而排除可能发生在规则处理之前。修改前应阅读相关选项的应用内说明，确认它控制的是系统路由、代理例外还是其他范围。不要仅凭选项名称相似，就把其中一个当成另一个的替代。

On Demand 主要管理何时建立或恢复连接，不能替代 Rule 决定某个域名采用哪条策略。用户可能看到连接自动打开，却发现请求仍然直连；这种情况应先确认当前 Global Routing 和命中记录，而不是重复修改 On Demand。反过来，规则文件完整但连接没有建立，也不能期望 Rule 自行接管流量。连接时机与连接后的分流，是两层独立的问题。

调整 General 时，优先保留能说明原因的最小改动记录：原值是什么、改为哪一项、使用什么请求验证、结果有什么变化。连接恢复后再复测依赖局域网或其他名称解析的目标，避免只验证一个网站。General 的参数作用范围通常比单条域名规则更大，修改成功的判断应覆盖正常场景与例外场景，而不是只看首页能否打开。

先确认模式，再判断规则

本手册的 Rule 示例以 Config 为测试前提。若正在使用 Proxy 或 Direct，应先恢复这一前提，再比较规则结果。

04 / 地址与特征

GEOIP、IP-CIDR、IP-CIDR6 与 USER-AGENT

地址规则解决的是“目标地址属于哪一段范围”，不是“用户正在使用哪个应用”。当请求直接访问地址、域名信息不可用，或者需要为明确的内部网段设置例外时，地址规则很有价值。但地址可能由不同业务共享，也可能随解析结果变化，因此不宜仅凭一次观察就把某个大型地址段长期固定到某条策略。先确认地址来源与维护责任，再决定是否写入配置。

IP-CIDR：地址和前缀长度共同定义范围

[Rule]
IP-CIDR,192.0.2.20/32,DIRECT,no-resolve
IP-CIDR,198.51.100.0/24,PROXY,no-resolve
FINAL,DIRECT

IPv4 的 IP-CIDR 字段由网络地址和前缀长度组成。/32 表示单个地址，/24 表示一段地址范围；数字不是端口，也不是优先级。上例使用文档示例地址，不能用于判断真实网络可达性。实际维护时，应确认填写的是需要覆盖的网络边界，而不是随意把一个目标地址后面加上较短前缀，否则可能扩大到许多不相关的目标。

no-resolve 是地址规则的可选参数，用来避免仅为检查这条规则而触发域名解析。它不表示关闭全部 DNS，也不意味着该规则必然命中。请求已经具备可用于比较的地址时，仍可进行地址匹配；只有域名信息而没有相应地址时，不能期待它主动完成解析再命中。排查这类规则时，要同时记录请求携带的是名称还是地址。

IP-CIDR6：单独检查 IPv6 路径

[Rule]
IP-CIDR6,2001:db8::20/128,DIRECT,no-resolve
IP-CIDR6,2001:db8:1::/48,PROXY,no-resolve
FINAL,DIRECT

IP-CIDR6 使用 IPv6 网络前缀，/128 可表示单个 IPv6 地址。示例中的 2001:db8:: 属于文档用途。只写 IPv4 地址规则，并不等于同一域名通过 IPv6 建立连接时也会命中；如果网络和目标同时提供两类地址，测试应覆盖实际使用的地址族。不要因为一次 IPv4 测试成功，就认定整个目标的地址分流已经完整。

出现同一目标在不同网络下策略不同的情况，先检查解析返回值及实际连接地址，再看配置是否只有其中一种地址规则。直接关闭某类地址能力可能暂时改变表现，却不能证明规则范围合理。若需求本质上针对一个稳定域名家族，优先考虑域名规则；若需求针对自己管理的明确网段，再使用相应地址规则表达，维护成本通常更可控。

GEOIP：按地址数据库归类

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

GEOIP 根据地址数据库对目标地址进行归类。GEOIP,CN,DIRECT 表示匹配数据库归入 CN 的地址后采用 DIRECT，不代表按照网页语言、域名后缀或用户所在地判断。数据库归类与业务归属不一定一致，使用分布式基础设施的目标尤其如此。明确的业务例外应放在 GEOIP 前面，不宜依赖地址归类去推测一个域名应当采用的路径。

GEOIP 还依赖可用的地址信息。某次请求没有命中预想的地域条件时，应检查实际目标地址、数据库归类和前置规则，而不是只修改国家或地区代码。将 GEOIP 与 FINAL 组合时，还要清楚未命中部分会走哪里：上例把其他请求交给 PROXY，与 FINAL,DIRECT 的默认方向相反。复制片段前应读完最后一行。

USER-AGENT：请求特征不是应用身份

[Rule]
USER-AGENT,ExampleClient*,DIRECT
FINAL,PROXY

USER-AGENT 根据可获取的 User-Agent 信息匹配请求，示例用 ExampleClient* 表达以该文字开头的特征。它不是按应用名称分流的通用方式：多个应用可能使用相同标识，同一个应用也可能在不同请求中使用不同标识。对加密请求，如果没有可读取的请求头信息，就不能期待仅凭这条规则识别内部的 User-Agent。

使用 USER-AGENT 前，应先确认记录中确实能看到相应特征，再用一个明确的测试请求验证。不要为了让这条规则生效而随意增加解密范围，也不要把请求头匹配失败误判成代理服务器故障。名称、地址、请求头属于不同层面的证据；只有明确知道当前请求提供了哪种信息，才适合选择相应关键字。

07 / 组合示例

常见分流写法与修改步骤

组合示例应当从需求开始，而不是从规则数量开始。先确定默认策略，再列出必须例外处理的目标，最后决定需要精确域名、后缀还是地址条件。下面每份片段都是独立思路，不应把它们连续粘贴到同一个 Rule 中。合并多个方案时，必须重新处理 FINAL、例外顺序与重复条件，否则后粘贴的部分可能完全不参与判断。

指定网站采用代理，其余直连

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

这类配置适合需求边界清楚、只希望名单内目标采用代理的场景。先放需要直连的账户主机，再放两个示例域名家族，剩余请求交给 DIRECT。实际添加时，先用一个目标确认服务器与规则都正常，然后逐步补充该业务依赖的其他主机。不要因为页面缺少一个资源，就把 FINAL 改为 PROXY；那会改变所有未列出的请求，不再是原来的小范围方案。

维护名单时，应把用户输入的页面地址与实际资源请求分开记录。业务可能将静态文件、接口和登录流程放在其他域名下，后缀规则不能自动推断这些关系。补充时只加入观察到且确有需要的目标，同时验证一个不在名单中的常用站点仍然直连。详细操作可结合只让指定网站采用代理的规则说明阅读。

明确例外直连，其余采用代理

[Rule]
DOMAIN,portal.example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
FINAL,PROXY

这份片段采用相反方向：把明确主机和常见私有 IPv4 地址段作为直连例外，其余交给代理。私有地址规则只能覆盖相应地址条件，不能保证所有局域网发现、广播或特殊网络功能都按预期工作。当前网络若使用其他范围或 IPv6，还需要根据实际情况单独分析。不要把几条私有地址规则当作完整的系统网络配置替代品。

采用 FINAL,PROXY 前，应确认已有代理路径能够处理自己的日常需求，并检查身份认证、局域网服务和必要的直连例外。某个服务需要直连时，先为它写范围明确的条件，再测试是否影响共享基础设施上的其他请求。若一个业务拥有大量动态域名，应持续依据记录维护，而不是猜测一个宽关键词后期待它长期准确。

阻断明确主机，保留同域其他请求

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

这里仅阻断一个精确主机，不把整个后缀全部拒绝。第一次测试 REJECT 时，最好选择可以确认用途且不影响关键流程的目标，随后检查页面、登录与接口是否仍正常。请求失败是该规则预期效果的一部分，但用户看到失败不一定能判断来源，因此应保留清楚注释。发生误伤时，撤销这条规则比继续增加多个补丁更容易恢复。

若被阻断主机还承载其他必要业务，规则无法仅凭域名区分其内部用途。此时应重新评估需求，不要把更宽的阻断范围当作补救。某条请求被 REJECT 后，应用可能改用其他目标或重试，记录中出现新请求并不意味着原规则失效。应比较每次请求的实际名称与策略，确认是同一目标重试，还是业务发起了另一条连接。

把新规则安全并入已有文件

先复制原配置，再找到现有 Rule 和末尾 FINAL。将新例外放到可能覆盖它的宽规则之前，不要另起第二个 Rule 段来猜测合并效果。若现有文件包含规则引用，应先理解其范围，再决定插入到引用前还是后。保存后选择这份副本，确认 Global Routing 为 Config，最后产生新请求并核对命中结果。验证失败时回到原副本，避免在不确定状态上继续叠加修改。

1. 用文字写出目标、默认策略和需要保留的例外。
2. 记录当前配置、服务器选择和 Global Routing。
3. 只加入本次必要规则，检查字段、策略名称与 FINAL 位置。
4. 分别测试应命中、应排除以及日常依赖的请求。
5. 确认结果后保存备注；未达预期就恢复原文件继续定位。

订阅更新可能改变已有服务器列表，但不能替代上述规则验证。若当前策略所依赖的服务器发生变化，需要重新检查代理路径；若只是服务器显示名称变化，也不能据此推断规则内容已变。管理多个订阅时，可参考多个订阅的分组与整理，将来源管理与规则维护分开，避免把重复服务器问题误写成规则例外。