Shadowrocket
规则与配置大全

配置文件结构与编辑入口

Shadowrocket 的配置文件承载规则和相关运行设置，常见文本以 .conf 为扩展名。它不是服务器订阅本身，也不等于 Home 中当前选中的服务器。理解这三者的分工，是查阅规则前的第一步：服务器信息描述连接到哪里，订阅负责汇集和更新已有服务器条目，配置文件则描述请求应按什么条件选择处理方式。只有把它们分别核对，才能避免把线路故障误认为规则错误。

配置段决定后续各行的含义

方括号包围的标题是配置段名，例如 [General] 和 [Rule]。一个段名之后的内容属于该段，直到下一个段名出现。General 常见的是键值设置，Rule 使用逗号分隔的匹配表达式，Host 用于指定主机名映射，URL Rewrite 则按请求地址执行重写。不能因为两条内容都涉及域名，就把 Host 映射或重写表达式放进 Rule；解析器先根据段落理解一行，再读取这一行的参数。

[General]
bypass-system = true
dns-server = system

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

[Host]
example.com = 192.0.2.10

[URL Rewrite]
^http://example\.com/old$ http://example.com/new 302

上面的片段只用于说明段落边界，不建议整段照搬。Host 中的地址属于文档示例地址，不能用来访问实际服务；重写行也只是演示语法。正式修改应取出当前问题需要的那一小段，放入自己的配置副本。若只是验证域名分流，不必同时添加 Host 和 URL Rewrite，否则一次引入多个变量，结果即使改变，也难以判断是哪一处修改产生作用。

先辨认选中的配置，再打开编辑

进入 Config 后，先确认当前使用的是哪一份配置，再查看或编辑其内容。列表中存在某个文件，不等于它已经被选为当前配置；同名副本也可能来自不同的保存位置。建议先记录配置名称、来源，以及修改前某条关键规则的内容。完成保存后回到 Config 再核对选择状态，避免把编辑副本的动作误当成切换配置。界面入口位置应以设备上实际显示为准。

修改前保存一份可恢复的副本，并使用能区分用途的名称，例如“日常规则副本”。备份不能只依赖记住几行文本，因为原文件还可能包含策略组、规则引用或与 DNS 有关的其他设置。若原配置来自可更新的来源，需要先了解更新是否会覆盖本地编辑；不能把远程更新与本地保存视为同一个动作。重要修改应在更新后再次检查，而不是假定内容会永久保留。

文本格式与片段使用边界

规则中的逗号、方括号和等号应使用英文半角字符。中文说明若写在独立注释行，可以使用中文标点；但把中文逗号混入规则字段，可能使本应分开的参数成为一个整体。复制片段后应检查行首行尾，避免带入排版用引号、列表序号或不可见空格。长规则在编辑器里折行显示通常不代表实际换行，真正的规则仍应保持一条记录一行。

本手册中的代码块可能是独立段，也可能只是供合并的几条规则。合并时应找到现有的对应配置段，而不是反复追加同名段落；兜底规则也应集中管理。若原文件包含额外配置，不能仅凭本页出现的几个段就删除其余内容。先理解现有用途，再决定是否保留，能减少因“整理文件”而破坏已正常工作的设置。

如果尚未理解 Home、Config 与 Settings 的职责，可以先阅读界面英文词对照。配置编辑的目标不是让文件尽可能短，而是让每个段落的作用可解释、每次变更可撤回。能准确指出当前配置、修改位置和验证目标，才具备继续检查匹配行为的基础。

General 与 Global Routing

General 描述一组通用运行设置，Global Routing 决定当前使用哪一种整体处理姿态。两者都影响连接，但属于不同层次。排查“规则没有生效”时，先检查 Global Routing，再检查配置文本；如果当前并非 Config，持续修改 Rule 可能并不会得到预期结果。相反，临时切换姿态后恢复正常，只说明问题范围发生变化，不能据此断定服务器或整份配置完全正确。

三种姿态如何用于查阅与验证

表中使用“主要请求”，是因为系统绕过、局域网条件以及客户端的其他设置仍可能影响具体流量。Global Routing 不是覆盖一切系统行为的保证，也不等于连接开关。切换到 Proxy 后仍需要可用的已有服务器，切换到 Direct 也不代表当前网络一定能访问某个目标。做对照时应保持同一目标、同一网络和相近时间，避免把外部变化当成姿态差异。

配置姿态下，界面显示的 Config 与配置段 [Rule] 共同参与分流；规则行末尾的 PROXY 则是该条规则指定的策略。三者名称相关但不能互换。将规则行末尾写成 Config，不会自动表达“按配置处理”的意思；同样，界面选择 Proxy，也不能说明某条 PROXY 规则确实被命中。必须分别观察整体姿态和单个连接的处理结果。

理解两个常见 General 设置

[General]
bypass-system = true
dns-server = system

bypass-system = true 表示启用系统相关的绕过行为。它属于连接处理的边界设置，不应被当作某个域名策略的替代品。保持已有默认值时，应先从 Rule 查找普通业务流量的分流原因；只有明确怀疑系统流量或特定网络服务受影响，才把绕过设置列为测试变量。随意切换可能同时改变多类请求，使原本单一的问题变得难以复现。

dns-server = system 表示使用系统提供的 DNS 设置。这里的 system 是值，不是可替换为任意中文说明的占位词。使用系统 DNS 的结果可能随 Wi-Fi、蜂窝网络及其他系统网络设置变化，因此“同一配置换个网络后解析不同”并不一定是规则内容发生变化。若原配置指定了其他 DNS，应先记录原值，再评估是否需要测试系统 DNS。

不要为了得到看似完整的配置而复制大量不理解的 General 参数。设置项之间可能有前提关系，来源不同的片段也可能对同一问题采用不同假设。更稳妥的做法是保留可工作的基础设置，围绕明确现象只改一个参数，并写下修改理由。若设备上已有相关选项，需同时核对应用内设置与当前配置，不能仅靠文件里是否出现某个键判断实际行为。

连接开关、按需连接与规则不是同一件事

On Demand 控制符合条件时的连接触发，不负责替代域名规则。连接尚未建立时，检查域名是否命中 Rule 并不能解决授权或启动问题；连接已建立但目标走错路径时，反复改变 On Demand 也通常不能修正规则顺序。应先确认 VPN 配置授权、连接状态和当前网络，再讨论具体请求的处理。这样可以把“连接何时存在”与“连接中的流量如何选择策略”分开。

首次连接出现的系统提示与规则文件不是同一个配置层，相关说明见VPN 配置权限提示说明。如果问题是后台触发频繁或耗电变化，应查阅On Demand 与电池使用，不要通过删减 Rule 来处理所有后台现象。不同层次的问题需要使用各自的证据。

完成 General 检查后，应得到一份明确的运行基线：当前网络、当前配置、Global Routing、所选已有服务器，以及是否启用了 On Demand。此后测试规则时保持基线不变，只有这样，新增的一条规则与访问结果之间才有可解释的联系。

DOMAIN 系列域名规则

域名规则按连接关联的主机名选择策略，不按网页标题、应用名称或完整地址栏文本匹配。编写前先明确目标究竟是一个完整主机名、整个域名树，还是名称中包含某个片段的一组主机。三种需求分别适合 DOMAIN、DOMAIN-SUFFIX 和 DOMAIN-KEYWORD。选择过宽的条件会把无关请求一起纳入，选择过窄则可能只覆盖页面入口，漏掉实际加载资源的其他域名。

DOMAIN：只指定一个完整主机名

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

第一条仅针对 api.example.com，不会自然扩展到 example.com 或 v2.api.example.com。第二条说明同一主域下的两个主机可以使用不同策略。精确规则适合已确认的例外：例如大部分请求采用统一路径，但某个主机必须单独处理。填写字段时不要附带协议前缀、路径、查询参数或端口，这些都不是 DOMAIN 的主机名内容。

若日志里看到的请求不是预想的主机，先核对重定向和资源加载过程。输入一个地址后，页面可能继续访问登录、图片或接口域名；对入口主机添加 DOMAIN，并不意味着相关请求都会命中。应该先观察失败请求的主机，再决定是否追加规则，而不是根据网页表面名称扩大匹配范围。每新增一个域名，都应能说明它与故障的关系。

DOMAIN-SUFFIX：覆盖域名与子域名

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

DOMAIN-SUFFIX,example.com,PROXY 用于匹配 example.com 及其子域名。它按域名边界理解后缀，而不是简单查找任意字符串，因此与 DOMAIN-KEYWORD 的覆盖范围不同。上例先放精确例外，再放后缀规则，让 local.example.com 使用 DIRECT，其余匹配的主机使用 PROXY。如果把后缀规则放到前面，精确例外通常没有机会生效，因为前面的规则已经匹配。

后缀规则不需要加 *.，也不应把它写成正则表达式。写入 example.com/path 不能表达“只处理这个路径”，因为域名与路径属于不同对象。对于多个不相关的主域，应分别写规则，而不是用一个过短的后缀替代。规则越接近实际边界，后续查看日志时越容易解释，也越不容易误伤其他服务。

DOMAIN-KEYWORD：范围更宽的名称片段

[Rule]
DOMAIN-KEYWORD,example,PROXY

DOMAIN-KEYWORD 根据域名中是否包含指定片段匹配。上例不仅可能覆盖 example.com，也可能覆盖其他含 example 的域名，因此不能把它当作 DOMAIN-SUFFIX 的简写。关键词越短，覆盖范围越难预测。若目标是一个组织明确控制的域名集合，通常应先考虑精确主机名或后缀；只有确实需要跨不同域名匹配共同片段时，再评估关键词规则。

域名匹配还依赖客户端能够取得与连接相关的主机信息。如果应用直接使用 IP，或者观察记录只显示目标地址，就不能假定某条域名规则一定有匹配依据。此时应先确认连接记录中可见的信息，再考虑地址规则，而不是重复添加同一个域名的多种写法。解析后的地址与原始域名之间也并非永远是一对一关系。

验证一条域名规则时，先选一个确定的测试主机，关闭旧页面并建立新请求，再检查处理策略。浏览器缓存、应用连接复用和后台请求可能使旧结果延续。只有新的对应连接确实使用了预期策略，才算验证了这一条规则；网页整体能打开只是结果之一，并不能单独证明规则覆盖范围正确。

IP、GEOIP 与请求条件

地址规则以目标 IP 或地址归属信息为条件，适合处理明确网段、直接使用地址的连接，以及域名规则未覆盖的后续分类。它们不等于域名规则的备用拼写。一个域名可能对应多个地址，同一个地址也可能承载多个域名；只按地址分流可能影响同地址上的其他服务。因此，先按域名表达明确需求，再在适当位置补充地址规则，通常更容易控制范围。

IP-CIDR：理解前缀而不是字符串

[Rule]
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

CIDR 中斜杠后的数字表示网络前缀长度，不是端口，也不是地址数量。前缀越长，覆盖范围通常越小。上例列出常见私有 IPv4 网段，但并不意味着你的局域网一定使用其中全部地址。写规则前应在设备网络信息中确认实际环境，尤其是连接到组织网络或个人 VPN 时，目标地址可能不属于当前 Wi-Fi 的本地网段。

对于单个 IPv4 地址，可使用 /32 表示单地址范围。不要为了绕过一个目标，把前缀从较长改成很短；这会同时改变大量地址的处理方式。若实际问题是本地设备发现失败，还应区分设备发现使用的流量与后续访问设备的连接。仅添加一个私有网段规则，并不能保证所有本地发现机制都按预期工作。

IP-CIDR6 与 no-resolve 的边界

[Rule]
IP-CIDR6,fd00::/8,DIRECT,no-resolve
IP-CIDR6,2001:db8::10/128,DIRECT,no-resolve

IP-CIDR6 面向 IPv6 地址，不能用 IPv4 规则代替。第二行使用文档示例地址，只演示单地址前缀写法。设备同时获得两类地址时，同一目标的不同连接可能使用不同地址族；只有 IPv4 规则而没有核对 IPv6，可能造成“有时走这条规则、有时没有”的表象。应根据实际连接记录判断，而不是仅看域名解析结果中出现了哪一个地址。

no-resolve 用来避免为了匹配这条地址规则而额外触发域名解析；它不表示系统停止 DNS，也不保证应用不进行解析。若连接本来就以 IP 为目标，仍可直接比较地址。若当前只有域名且没有可用地址信息，这个选项可能使地址规则无法按预想命中。测试时应明确需要“按已知地址判断”，还是需要允许解析后再判断。

GEOIP：按地址库分类而非按语言分类

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

GEOIP 根据目标地址在地理数据库中的归类匹配，CN 是该规则使用的地区代码。它不能根据网页语言、域名后缀或机构名称推断匹配结果。内容分发网络的地址调度会变化，数据库归类也可能与用户直觉不同。若某个主机需要固定策略，应将明确的域名规则放在 GEOIP 前面，不要依赖某次解析恰好落在预期地区。

若使用带 no-resolve 的 GEOIP 规则，同样需要理解可用地址信息的限制。无法命中时，应先检查目标 IP 和域名信息是否可见，再讨论数据库归类。盲目交换 GEOIP 与 FINAL 的位置不是解决办法：FINAL 应处于兜底位置，放在 GEOIP 前面会使后者失去正常匹配机会。

USER-AGENT：依赖可见的 HTTP 信息

[Rule]
USER-AGENT,ExampleClient*,DIRECT

USER-AGENT 的条件来自 HTTP 请求头，不是设备中显示的应用名称。上例用虚构的请求头前缀说明通配匹配，不能据此识别某个实际应用。加密连接中，客户端未必能读取这项内容，因此不能把它当作适用于所有请求的应用级分流规则。请求头还可能随应用更新或请求类型改变，长期稳定性需要单独验证。

选用规则类型的关键，是证据是否足够：有确定主机名时用域名，有明确地址范围时用 CIDR，确需地址归类时用 GEOIP。只有确认请求内容可见且条件稳定，才考虑 USER-AGENT。按可观察信息选择规则，能避免在不同条件之间反复试写，却始终无法解释结果。

策略、匹配顺序与 FINAL

规则通常由类型、匹配值和策略构成，FINAL 则不需要普通匹配值。类型决定检查什么，策略决定命中后怎么处理。PROXY、DIRECT、REJECT 是本页使用的三种基础策略；它们与 Global Routing 的界面姿态属于不同层次。读规则时应先读条件，再读结果，最后检查该规则是否有机会被执行，而不是只在文件中搜索期望的策略词。

PROXY、DIRECT、REJECT 各表达什么

PROXY 不会自动生成可用服务器信息，也不保证目标连接成功。即使命中规则，仍可能因服务器不可达、协议参数不符或远端无法连接目标而失败。DIRECT 同样不是“必定成功”的策略，它只表达直接访问的选择。REJECT 是明确阻止连接，不应作为无法判断时的临时通用答案；误拒绝认证或接口请求，可能使整个应用呈现异常。

现有配置还可能使用命名策略组。遇到行末不是这三种关键字时，应回到原配置查看该名称的定义与当前选择。不能随意把组名改成 PROXY 后，继续假定原有选择逻辑不变。来自其他配置的组名也不能单独复制使用，因为规则引用需要有对应定义；拼写、空格和名称不一致都可能造成引用问题。

首条命中优先，不按“更具体”自动排序

[Rule]
DOMAIN,local.example.com,DIRECT
DOMAIN,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

普通规则按排列顺序检查，前面的匹配结果决定后续是否还有机会参与。上例将精确例外置于后缀之前，再处理私有网段与地址归类，最后兜底。它不是所有环境的固定模板，而是展示一种可读的排列方式。如果把宽泛后缀放在第一行，即使后面有更精确的 DOMAIN，也不会因为“更具体”就自动获得更高优先级。

地址规则与域名规则之间也可能有顺序关系。若把一条覆盖范围很大的地址条件放得过早，后续域名例外可能无法发挥作用；反过来，某个域名被前面的规则接住后，其解析地址属于哪里便不再决定这一轮的普通规则结果。排错时应沿着文件从上往下找第一条符合条件的规则，不能只检查你刚添加的那一条。

重复规则容易掩盖真正问题。两条完全相同条件却指向不同策略时，后面的那条通常不会按预想接管。删除重复项前，应先看是否来自不同管理区段或可更新来源，再决定在哪一层修正。对于大配置，可以临时把单个精确测试规则放到前面进行定位，但测试结束后必须回到原来的组织方式，避免留下无法解释的优先级补丁。

FINAL 是兜底，不是必须使用 PROXY

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

这份片段表示匹配 example.com 的请求使用 PROXY，其余走 DIRECT。若将最后一行改成 FINAL,PROXY，就改变了未被前面规则覆盖的全部普通请求。两种写法都可能用于不同需求，关键是先说明默认路径是什么，再添加例外。不要因为某段示例使用 PROXY 兜底，就直接改变自己配置的整体访问假设。

FINAL 应位于普通规则的末尾，并在整理时保留清晰的一处兜底。若在它后面继续追加 DOMAIN 或 GEOIP，很可能出现“保存成功但规则没用”的现象，因为流量已经在前面被接住。检查文件尾部尤其重要：复制多个片段时，最容易把一个片段的 FINAL 留在中间，再把新规则加到它下面。

当规则与实际意图一致，却仍然无法访问时，应停止继续堆叠同类规则，转向路径排查。相关步骤见连接失败排查顺序。规则层负责解释为什么选择这条路径，连接层负责解释这条路径为何成功或失败，两者分开后才容易得到可复现的结论。

Host 映射与 DNS 判断

Host 用于为主机名指定地址映射，Rule 用于决定连接采用什么策略，两者不能互相代替。把一个域名映射到某个地址，并不等于要求它走 DIRECT；给域名写 PROXY，也不等于固定其解析地址。排查时先分别记录“请求的主机名”“实际目标地址”“采用的策略”，再判断是哪一层出现偏差。只看网页打开与否，往往无法分辨这三种变化。

Host 的基本写法与使用边界

[Host]
example.com = 192.0.2.10
api.example.com = 192.0.2.20

左边是需要映射的主机名，右边是指定地址。这里使用文档示例地址，不代表可访问的服务器。Host 条目不使用 Rule 的三字段逗号格式，也不在末尾追加 PROXY 或 DIRECT。添加后应核对是否真的需要固定地址，以及该地址是否由目标服务的管理者明确提供；不能仅凭某次查询到的结果，就把动态服务长期绑定到一个地址。

固定映射会绕开正常解析中一部分动态选择。对于使用内容分发、负载均衡或故障切换的服务，地址可能随地区、网络和时间变化。旧映射有时短期有效，之后却表现为超时、证书异常或部分资源失败。出现这类现象时，应把 Host 中相关条目列为检查对象，先恢复正常解析做对照，而不是立即增加更多域名分流规则。

Host 通常也不应被理解为修改请求中的所有身份信息。对于 HTTPS，证书校验与所请求的主机名仍有关联，指定了一个 IP 不表示可以接受任意站点证书。遇到证书错误时，应检查目标域名、映射地址和设备时间，不应通过降低信任要求来掩盖映射问题。若证据不足，撤回映射比继续扩大修改范围更容易恢复基线。

DNS 与规则之间的关联

DNS 将名称转换为地址，域名规则可以在有主机信息时按名称判断，地址规则则需要适当的地址信息。两者关联紧密，但不是所有连接都会以相同顺序向外暴露同样信息。应用缓存、系统缓存以及代理路径中的解析方式，都可能影响你看到的结果。因此，“系统查询得到这个地址”与“这次实际连接使用这个地址”应分开记录。

[General]
dns-server = system

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

这个片段用于说明判断层次：第一条按明确域名处理，第二条仅对已有地址信息匹配示例网段，最后兜底。它不是 DNS 故障的通用修复方案。若 api.example.com 已被第一条接住，不能仅因为它解析到示例网段就认定应走第二条。相反，若请求直接使用地址而没有相关主机名，观察到的匹配路径又可能不同。

解析故障应如何分支检查

如果所有域名都无法访问，而已知地址连接表现不同，应先检查当前网络的解析能力、General 中的 DNS 设置和是否存在 Host 覆盖。若只有一个域名异常，优先查看拼写、过期映射、服务自身状态以及是否存在拒绝规则。不能把“某个页面空白”直接归为 DNS 失败，因为页面入口可能已成功，真正失败的是后续接口或认证请求。

在 Wi-Fi 与蜂窝网络之间切换时，应把网络变化记录下来。系统 DNS、IPv6 可用性和局域网访问条件都可能随之改变。若配置相同而表现不同，应检查这些输入条件，而不是复制两份互相矛盾的规则来“适配”。对照测试的目标是找出差异来源，最终配置应能解释差异，而不是只记住在哪个网络上碰巧可用。

修改 Host 或 DNS 后，应重新建立测试连接；旧连接仍可能继续使用之前的地址。必要时关闭目标应用后再打开，并观察新的请求记录。不要把刷新页面视为必定刷新全部网络状态，也不要同时清理多种设置后只记下“重启解决”。保留变更顺序，才能知道是新解析、旧连接结束还是其他操作改变了结果。

DNS 排查最终应留下可以核对的事实：异常主机、当时网络、是否存在映射、实际使用地址，以及最终策略。如果这些信息还不完整，继续修改其他 General 参数只会扩大不确定性。常见连接与解析问题也可结合常见问题逐项核对。

URL Rewrite 与匹配边界

URL Rewrite 针对可见的请求地址执行改写或重定向，与 Rule 的路径选择不是同一功能。Rule 解决“连接采用什么策略”，URL Rewrite 解决“符合条件的请求地址如何处理”。如果需求只是让 example.com 使用 PROXY，应写域名规则，而不是增加重写表达式。只有确实需要改变请求地址，并且理解目标行为时，才应使用重写段。

一条重定向表达式的组成

[URL Rewrite]
^http://example\.com/old$ http://example.com/new 302

这一行包含匹配表达式、替换地址和处理方式。示例使用 302 表达临时重定向：当可见请求地址与左侧表达式匹配时，返回指向右侧地址的重定向结果。这里故意使用 HTTP 与完整、精确的路径，避免把 HTTPS 可见性或复杂路径捕获混入基础语法讲解。示例域名仅用于说明，不代表需要实际访问的测试服务。

表达式中的 ^ 锚定开头，$ 锚定结尾，\. 表示字面上的点。若省略转义，点在正则表达式里通常具有更宽的匹配含义；若省略结尾锚点，带有额外路径或查询内容的地址也可能进入匹配范围。编辑时应逐个解释符号，不能只根据表达式“看起来像网址”就认为它与普通地址文本等价。

右侧地址也需要完整、明确。把 HTTP 改为 HTTPS，并不代表目标服务一定在对应位置提供相同内容；改变主机名或路径，还可能影响登录状态、跨域请求和接口行为。重写只能改变指定的请求处理，不能替目标服务创建页面。应用若不接受重定向，浏览器中看似可用的表达式，也可能在该应用请求中失败。

先约束范围，再增加复杂条件

初次测试时应从单个主机、单个路径开始，避免直接使用覆盖所有域名的模式。确认精确匹配能够按预期工作后，再逐步考虑是否需要允许子路径或查询参数。每放宽一次表达式，都应列出新增会匹配的请求类型。对于需要保留查询内容的场景，必须明确参数如何进入替换地址，不能假定它们会自动按原样传递。

正则表达式里的捕获组、转义与配置文本是多个层次的问题。直接在配置文件里编辑，与把同样文本嵌入其他格式时，需要的转义处理可能不同。不要把某个说明页面显示的双重转义直接当作配置需要的反斜杠数量。本页代码展示的是配置文本本身；复制后应在编辑器里逐字符检查，而不是再加一层引号或转义。

同一重写段中存在多个表达式时，应避免条件相互重叠，并按由具体到一般的方式组织。不要照搬 Rule 的 FINAL 到 URL Rewrite，它们不是同一种语法。若现有配置包含复杂的重写组合，应先停用相关组合的副本来做对照，再单独启用目标表达式验证，不能一次追加多条来源不明的规则后只检查页面是否打开。

HTTPS、证书与请求内容可见性

HTTPS 保护请求内容，不能因为知道某个域名，就假定客户端能读取其完整路径并执行任意重写。是否能够处理相关请求，还取决于实际功能设置和连接条件。本页示例不要求开启 HTTPS 解密，也不把安装证书作为规则参考的前置步骤。若需求可以通过域名分流解决，应优先使用影响范围更明确的 Rule。

涉及证书与信任的变更应独立评估，尤其不能为了让一个重写片段“生效”而接受无法说明来源的配置。证书错误、连接被应用拒绝和重写未匹配，是不同现象。先记录系统或应用实际报错，再判断请求是否到达可处理层；否则容易将可见性限制误判成正则错误，并不断扩大匹配范围。

识别循环与缓存带来的假象

若替换后的地址再次满足原表达式，就可能形成重复重定向。浏览器表现可能是多次跳转、错误页面或无法完成加载。排查时应分别写出起始地址、替换地址和替换地址是否仍会匹配。验证通过后也应保留足够具体的条件，而不是依赖浏览器恰好停止继续请求来避免循环。

重定向结果还可能被应用缓存，停用表达式后旧行为未必立刻消失。应使用新的请求并记录地址变化，必要时结束目标应用的旧会话。若恢复原配置后仍有异常，先查缓存与目标服务响应，不应立即认定配置保存失败。能够解释从原地址到最终地址的每一步，才算完成了重写排查。

配置验证与故障定位顺序

配置排错的目标是找到足以解释现象的最小原因，而不是反复切换全部设置。开始前记录当前网络、Global Routing、配置名称、已有服务器和目标请求。再写出一个具体预期，例如“api.example.com 的新连接应使用 PROXY”。目标越具体，验证越容易；“所有功能都恢复正常”适合最终检查，却不适合作为单条规则测试的第一标准。

从连接基线开始，不先改规则

首先确认 Shadowrocket 已完成 VPN 配置授权且连接能够建立。如果连接本身无法启动，优先查系统提示和连接状态；如果连接建立但已有服务器不可达，先核对服务器信息与网络。只有基础连接具备可测试条件，才继续判断 Rule。Connectivity Test 可以提供连接线索，但某项测试通过不代表每个域名、每种协议请求和每条规则都已经验证。

其次确认 Config 确实是当前 Global Routing，并检查正在使用的配置是否就是刚编辑的文件。保存到一个副本、却继续使用原配置，是常见的误差来源。对照文件中一条容易辨认的规则内容，再执行保存和必要的重新连接操作。若应用提示解析错误，应先处理文件语法，不能在无效配置上继续推断匹配结果。

按条件、顺序、策略逐层检查

1. 确认请求实际关联的主机名或目标地址，与规则字段是否一致。
2. 从 Rule 开头向下检查，寻找更早匹配的条件。
3. 确认 FINAL 没有提前截断后续普通规则。
4. 核对命中的策略或命名策略组，以及对应的实际路径。
5. 使用新连接复测，并把结果与修改前的记录对照。

如果请求主机与规则不同，先处理匹配对象；如果主机一致但结果走了其他策略，先处理顺序或配置选择；如果策略正确却连接失败，转查路径与目标。这种分支能避免常见的循环：连接失败就添加域名规则，仍失败就改 DNS，再失败就扩大关键词。每次测试都应回答一个问题，而不是同时试图证明所有设置。

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

这份最小片段仅用于解释定位方法，不应覆盖整份现有配置。实际测试应在保存好的副本中，暂时用一个精确条件排除宽泛规则的干扰。若精确条件能够产生预期策略，再逐步恢复原配置中的规则块；若仍不能，则检查请求信息是否可见、配置是否生效，以及当前姿态是否正确。这样得到的结论比不断添加同义规则更可靠。

把现象分成可复查的几类

对于间歇性问题，应记录每次失败的时间、网络和目标，而不是只保留成功的一次。某个页面可能复用旧连接，某个服务也可能改变解析地址；重复请求不一定使用相同输入条件。观察记录时以与测试操作对应的新连接为准，避免把后台同步或其他应用产生的流量当作测试结果。

如果需要查看 Data 或相关诊断记录，只收集与目标请求有关的必要信息。完整记录可能包含域名、路径、查询内容和个人标识，分享前应清理。向他人描述问题时，可以提供已去除敏感信息的规则片段、当前姿态和可复现步骤，而不是直接交出整个配置与订阅地址。能让别人重现判断过程，比提供大量无关记录更有帮助。

恢复、整理与后续查阅

确认原因后，只保留解决该问题所需的修改，撤回用于定位的临时宽泛规则、Host 映射或重写表达式。再检查日常使用的其他目标，尤其是之前被例外规则保护的请求。最后保存新的可恢复副本，并记录修改目的。配置可更新时，还要在下一次更新后核对关键内容，确认本地调整没有被替换。

日常导入与首次连接继续使用快速上手教程；购买、应用 ID 与开发者核验查看正版核验说明；常见操作疑问查阅常见问题。本页的规则参考负责解释配置如何表达意图，实际结果仍应通过当前设备上的新连接与可观察记录逐项确认。