Shadowrocket 规则手册
配置结构与匹配参考

01 配置文件结构与启用范围

配置与订阅是同一份内容吗？

不是。订阅通常用于维护一组服务器连接信息；配置文件则描述请求如何处理，例如选择什么策略、使用哪些域名规则，以及是否需要特定的解析或重写行为。导入已有订阅后，服务器列表出现条目，并不等于某份规则配置已经启用。排查时应分别核对 Home 中可选的服务器、Config 中当前使用的配置，以及 Global Routing 的状态，不能用其中一项替代另外两项的检查。

应先看哪部分？先识别方括号包围的分区名，再读取分区内的行。不同分区采用不同语法：General 常见的是键值设置，Rule 是按行排列的匹配条件，Host 是域名与地址的映射，URL Rewrite 则使用匹配表达式和动作。不要把一行域名规则粘贴到 General，也不要因为文本可以保存，就认为它一定被解释成了预期功能。

[General]
dns-server = system

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

[Host]
portal.example.com = 192.0.2.10

这个最小片段表达了什么？

它在 General 中使用系统 DNS 设置，在 Rule 中先处理示例域名后缀，再检查地址归属，最后指定兜底策略；Host 中的地址来自文档示例地址范围，仅演示映射格式。这里没有服务器连接凭据，也没有展示所有可用设置。PROXY 能否实际建立连接，仍依赖当前选择的服务器及其参数。复制片段时应连同分区位置一起理解，不要只看某个英文关键字。

如何建立可回退的编辑流程？在 Config 中找到当前使用的配置，先保留原件，再创建可辨认的副本。记录修改前的 Global Routing、当前服务器和准备验证的目标域名。每次只更改一个逻辑单元，例如增加一条 DOMAIN 规则，而不是同时更换 DNS、服务器与兜底策略。保存以后再次确认正在使用的是副本，避免编辑了文件甲，却用文件乙进行测试。

General 中的设置要全部照抄吗？

不需要。General 属于基础行为设置，应该根据具体问题逐项确认。现有配置可能已包含 DNS、连接处理或网络相关选项，完整替换会改变原先正常工作的部分。对不熟悉的键，先在应用内编辑界面核对名称与允许值；无法确认含义时保留原值。手册只给出能清楚解释的片段，不建议通过堆叠参数寻找所谓通用配置。

远程配置更新会怎样影响本地修改？如果当前文件来自远程来源，更新后是否保留编辑，应按应用内实际操作结果核对，不能预设所有修改都会自动合并。更稳妥的方式是保留原始来源和本地测试副本，更新后对照自己改过的规则位置。发现行为变化时，先比较启用文件、规则顺序和基础设置，而不是立即判定服务器失效。

哪些内容适合写入备注？可以记录规则目的、测试目标和回退方法，但不要把自己的订阅地址、密码或其他连接凭据写进准备公开分享的示例。分享排查信息时，保留分区名、关键字和先后关系即可；把敏感字段移除以后，再检查截图或文本中是否还藏有查询参数。配置是可执行的网络行为说明，不只是方便收藏的文本列表。

03 IP、GEOIP 与 USER-AGENT

IP-CIDR 的斜杠数字是什么意思？

它表示网络前缀长度，用来确定一个地址范围，不是端口，也不是规则优先级。IPv4 中 /32 表示单个地址，/24 常用于包含二百五十六个地址的网络块。范围越宽，可能覆盖的目标越多。编写前应确认自己要处理的是单台主机还是整个网络，不应根据地址看起来相似就随意缩短前缀。范围错误可能把无关请求也导向同一策略。

[Rule]
IP-CIDR,192.0.2.25/32,DIRECT
IP-CIDR,198.51.100.0/24,PROXY
IP-CIDR6,2001:db8::/32,DIRECT
FINAL,DIRECT

这些地址能用来测试服务吗？不能，它们是文档示例地址。第一行说明单地址规则，第二行说明 IPv4 网络范围，第三行说明 IPv6 前缀。IP-CIDR6 与 IP-CIDR 分别处理不同地址族，写了一条 IPv4 规则不会自动覆盖同一服务的 IPv6 地址。如果设备同时获得两类地址，测试时应检查实际使用的目标，避免将地址族变化误认为规则随机失效。

什么时候考虑 no-resolve？

IP 类规则可能涉及为域名取得地址再判断范围。no-resolve 用于表达不为该规则额外触发域名解析的意图；它不等于整个应用停止 DNS，也不保证请求永远不会出现地址信息。若请求本来就是 IP，或已有可用地址，仍应根据实际条件理解匹配。使用前先想清楚：这条规则是只处理已知地址，还是希望域名解析后也纳入范围。

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

为什么不在每条地址规则后都加相同选项？因为它会改变域名请求到达此处时的处理条件。对于希望通过解析结果识别的目标，限制额外解析可能使后续 FINAL 更常被使用；对于仅处理已有 IP 的例外，则可能符合目的。应在一个目标上比较修改前后的记录，不要用“选项越多越完整”的方式编写配置。可用语法还应在当前应用内核对。

GEOIP 是否表示网站属于哪个地区？

不是。GEOIP 根据目标 IP 的地理归属数据进行判断，不能从网页文字、注册信息或页面内容推导结果。使用 CDN 的域名可能解析到不同地址，网络切换后归属结果也可能变化。GEOIP,CN,DIRECT 的含义是让匹配到相应地址归属的请求使用 DIRECT，不是“所有中文网站直连”，也不是“某个域名以后永远走同一策略”。

什么时候应让域名规则排在 GEOIP 前面？当某个域名需要确定策略，而不希望解析地址变化影响决定时，应把明确的域名例外放在较前位置。GEOIP 适合承担较宽的地址分类，不适合替代所有精细规则。如果同一服务在不同网络表现不同，先比较它的解析地址和命中规则，再决定是否增加域名例外，避免不断调整地理范围。

USER-AGENT 能可靠地按应用分流吗？

不能把它当作通用的应用身份识别。USER-AGENT 匹配的是请求中可见的对应字段，而不是系统里的应用名称。加密连接中字段是否可见、具体请求是否携带该字段，都影响规则是否有机会工作。并且多个应用可能使用相同字符串，同一应用也可能产生不同字符串。应先确认实际字段，再讨论匹配表达式。

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

这条演示只说明 USER-AGENT 的位置和通配写法，不代表存在名为 ExampleClient 的实际请求。若记录里没有可核对的字段，优先使用已确认的域名或地址条件。不要仅为使这种规则命中而扩大对加密流量的处理范围；规则条件不可见与服务器不可用是两类问题，应该分别验证。

05 匹配顺序、例外与 FINAL

规则是按类型自动排序的吗？

不是。理解 Rule 的核心是自上而下检查，命中后采用对应策略。DOMAIN 不会仅仅因为更精确就自动跳到 DOMAIN-SUFFIX 前面，某条规则写在后面也不会天然覆盖前面的规则。编辑时应把文件看成有顺序的判断过程，而不是一组会自动计算最佳结果的标签。解释任何命中结果，都应先沿着文件从上往下寻找第一条符合条件的规则。

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

应如何逐行阅读这个片段？先问目标是不是 api.example.com；若是，使用 PROXY，不再靠后缀规则改变结果。否则检查目标是否属于 example.com 的域名范围，再考虑地址例外与 GEOIP。前面都没有匹配时，才由 FINAL 接收。这个阅读过程也提示了维护方法：特殊例外在前，范围归类在后，兜底收尾；每一层都要能说明为什么放在这里。

FINAL 为什么必须认真决定？

FINAL 是未命中前序规则时的最终策略，不是注释，也不是只有出错才使用的备用项。配置覆盖不完整时，大量请求可能到达这里。FINAL,DIRECT 与 FINAL,PROXY 表达两种不同的默认选择，没有脱离场景的统一答案。选择以前应确定自己的规则主要列举哪一类目标，并判断未列出的请求应该采取什么路径，而不是照抄一行看起来熟悉的结尾。

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

这份极简配置是怎样的思路？只为列明的示例域名选择代理，其余交给 DIRECT。如果意图改成“只有明确允许的目标直接连接”，就需要重新组织前面的规则并选择相应兜底，而不是单改 FINAL 后假定全部行为仍然符合预期。兜底改变会影响所有尚未被列出的目标，测试范围也应随之扩大，至少覆盖一个例外和一个未列出的目标。

重复规则会让匹配更可靠吗？

不会。前面已经存在同条件规则时，后面的重复行通常不能修复它；若策略不同，反而造成维护者误以为后面的设置有效。删除重复前，应先确认两行条件是否真的一致，例如 DOMAIN 与 DOMAIN-SUFFIX 并不是重复。可以将规则按目的分组，记录“精确例外”“域名范围”“地址范围”“最终策略”，但不要仅为视觉整齐而改变已经验证过的优先关系。

新增规则后怎样检查遮挡？用目标域名从第一行开始模拟，找出新增规则之前是否已经有宽范围条件会命中。若存在，判断应该把新规则上移，还是缩小旧规则范围。不要把所有新规则统一放在文件末尾，尤其不能放到 FINAL 之后再期待它参与正常兜底前判断。对范围重叠的规则，应在修改说明里写清楚哪一条是例外以及为何优先。

为什么新顺序没有立即改变旧连接？

规则判断与连接建立有关，已建立的长连接或连接复用可能延续先前的处理结果。保存配置后，应重新发起测试请求，必要时在确认不会影响重要任务的前提下重新连接。不要仅刷新一个仍在复用连接的页面，就判定保存失败。比较时要控制请求、网络和服务器不变，同时区分“旧连接继续存在”与“新连接仍然命中错误规则”。

怎样证明调整没有造成旁路影响？除验证目标例外外，还要测试同后缀的另一个子域名、一个无关域名以及一个地址目标。只验证最关心的那一个请求，容易漏掉宽规则带来的变化。维护记录应保留修改前后的片段，而不是整份含有敏感信息的配置；这样下次出现差异时，能直接判断是范围变化、顺序变化，还是环境变化。

07 URL Rewrite 的用途与限制

URL Rewrite 与 Rule 分别改变什么？

Rule 主要决定连接使用哪种策略；URL Rewrite 针对匹配到的 URL 执行相应重写动作。把请求从一个网址重定向到另一个网址，不等于指定它走 PROXY；为域名指定 DIRECT，也不等于修改页面路径。需要按路径处理时，应先确认是否真的需要重写，而不是把完整 URL 填进 DOMAIN。两种分区可以同时存在，但应分别验证效果。

[URL Rewrite]
^http://example\.com/ https://example.com/ 302

这行片段表达了什么？开头是匹配表达式，中间是目标地址，最后是重定向状态码。它演示将以 http://example.com/ 开始的可见请求重定向到指定 HTTPS 地址。点号前的反斜杠让表达式按字面域名点号匹配，开头的 ^ 限定从 URL 起始位置检查。该例只用于说明结构，不应该推断成可以直接应用于任意网站的通用规则。

为什么表达式必须控制范围？

正则表达式中的点号、星号、括号等符号有自己的含义，并不总是代表可见字符本身。没有转义的点号可能匹配任意字符，缺少起始边界可能在意外位置命中。编写前应列出应当匹配和不应匹配的样例，逐一检查。域名看起来接近，不代表表达式只作用于那个域名；范围越宽，对登录、接口和资源加载的影响越难追踪。

目标地址为什么也要认真检查？重定向改变了请求接下来访问的位置，目标域名、路径和查询参数都可能影响页面行为。若规则将一个路径统一送往首页，原有页面定位与参数可能不再保留。只有确实需要保留捕获内容时，才进一步使用应用支持的替换语法，并在小范围副本中验证。不要把不理解的表达式整体粘贴到长期使用的配置。

HTTPS 路径能直接被普通规则读取吗？

不能预设可以。HTTPS 会加密请求内容，普通的域名路由信息不等于完整 URL 路径可见。某条针对路径的重写没有生效时，首先应判断当前请求是否满足可见性条件，而不是不断扩大域名匹配范围。不同请求的处理条件要在应用内核对；本页不把解密相关设置当作普通分流的必要步骤，也不建议为一次重写随意改变系统信任设置。

如果需求只是让某个域名使用代理，应该怎么做？回到 Rule，使用明确的 DOMAIN 或 DOMAIN-SUFFIX 即可，不必加入 URL Rewrite。只有确实需要改变请求 URL、并且能够验证请求可见性和目标行为时，才考虑相应分区。功能越接近请求内容，越需要谨慎控制影响范围；简单的路由目标应优先由简单的路由规则表达。

重定向循环与路径变化怎样排查？

先暂时移除新加的重写行，在配置副本中确认原请求是否恢复。如果重写目标再次被同一表达式匹配，可能产生反复重定向；即使表达式本身没有循环，服务端也可能按自己的规则跳回原地址。不要只观察页面最后显示了什么，还应记录开始 URL、重定向目标和失败发生的位置。每次仅保留一条候选重写，便于确定责任范围。

将 HTTP 改为 HTTPS 为什么不是任何情况下都能成功？目标服务必须实际支持对应域名与路径的 HTTPS，且证书与服务配置正确。重写不会给一个服务自动增加协议能力。遇到跳转后连接失败，应分别测试目标地址本身，再判断表达式是否有误。此处失败不应通过更改 FINAL 或 GEOIP 来掩盖，因为网址修改和连接策略是两条独立的验证线。