CONFIG / RULE / POLICY

Shadowrocket 规则与配置参考大全

本页是 Shadowrocket 官方手册的系统查阅部分，侧重配置结构、匹配依据与故障定位。首次导入已有订阅并连接，请先读使用说明；完成基本连接后，再按本页目录调整规则。

所有示例均用于解释语法，域名与地址为教学值。操作前应具备用户自己的订阅或服务器信息，并保留当前可用配置。

一、Config 文件结构与配置边界

区分服务器信息、订阅与配置文件

Shadowrocket 中的服务器信息、订阅和配置文件解决不同问题。服务器条目描述连接目标所需的地址、端口、认证与协议参数；订阅用于批量维护用户已有的服务器条目；配置文件则组织解析、匹配和处理请求的规则。三者可能在同一使用流程中出现，但不能互相替代。导入服务器订阅后，仍需检查当前使用哪份配置；选中一份配置，也不表示已经具备可用服务器。排错时先拆开这两层，能够避免反复修改与故障无关的部分。

配置通常是按分段组织的文本。方括号标识一个分段的开始，该段内容持续到下一处分段标题之前。常见的 [General] 保存通用设置，[Rule] 保存有先后顺序的匹配规则，[Host] 保存指定主机名的地址映射，[URL Rewrite] 保存针对可见请求地址的改写规则。分段标题不是说明文字，不能改成中文。规则中的逗号、等号和参数位置也属于语法，编辑时应使用英文半角符号。

分段主要职责核对重点
[General]通用行为与解析相关设置参数名称、取值及系统交互
[Rule]按条件选择连接策略规则顺序、条件与策略名
[Host]指定主机名的地址映射映射目标是否仍然有效
[URL Rewrite]按表达式改写可见请求地址匹配范围、目标和动作

从最小片段理解各段关系

下面的片段展示通用设置与规则怎样分开书写。dns-server = system 表示使用系统提供的解析设置；它不是对所有网络都更快的承诺。两条域名规则描述不同去向，最后一条承接尚未匹配的请求。这只是结构示例，不是适合直接覆盖现有文件的完整方案。尤其是 PROXY 的实际连接目标，仍要结合应用中当前选择的服务器核对，不能从这几行文字推断。

[General]
dns-server = system

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

阅读一份较长的配置时，建议先标出所有分段，再查找最后的默认规则，然后回看域名和地址规则。这样的顺序先确定文件的整体边界，再确认例外条件。不要一开始就复制其中某一大段到另一份文件：同名策略、已有规则和通用设置可能不同，单独看语法正确的片段，合并后仍可能改变请求去向。遇到不认识的设置，应先查明用途，再决定保留或删除。

保存、选用与保留恢复点

在 Config 中编辑前，先复制当前文件并用可辨认的名称保存。编辑完成后检查保存状态，再确认实际选用的是修改后的那一份。仅打开编辑器查看内容，不等于已经切换当前配置。随后还应核对 Global Routing，因为配置中存在规则与请求实际按规则处理是两个条件。首次操作可以对照快速上手主线完成选择，再回到本页查语法。

远程维护的配置还涉及更新边界。若直接在会被远程内容替换的文件中添加个人规则，后续更新可能覆盖这些改动。比较稳妥的做法是保留原始来源副本，另存个人工作副本，并记录每次修改的目的。订阅更新、配置更新和应用更新也应分开理解：前者主要涉及已有服务器条目，中间一项涉及规则文本，应用本身的获取与更新则通过 App Store 进行。

二、Global Routing 与连接策略

先确认模式，再解释规则结果

Global Routing 是判断规则是否参与处理的第一项。配置姿态对应 Config，代理姿态对应 Proxy，直连姿态对应 Direct。在通常的规则排查中，应先切回 Config，再检查文件内容。若处于其他姿态，仅修改域名规则往往不能得到预期结果。这里讨论的是连接路由的总体选择，不表示应用会绕过系统限制，也不表示所有系统流量都具有完全相同的可见性。

模式名称与规则中的策略关键字处于不同层级。Proxy 是界面上的模式名，PROXY 是规则中的策略值；Direct 与 DIRECT 也有类似区别。两者字面相近，但不要把改变模式误认为只是改变某条规则的策略。遇到整批请求去向同时变化，应优先检查模式和当前选用的配置，而不是逐条猜测域名规则是否全部失效。

姿态界面词使用与诊断重点
配置Config按当前配置检查匹配条件和策略
代理Proxy按代理方向验证服务器连接能力
直连Direct对照本地网络直接访问的表现

PROXY、DIRECT 与 REJECT 的实际含义

PROXY 表示交给代理方向处理，但它本身不是服务器地址。能否成功连接，仍取决于选中的服务器、协议参数和网络可达性。规则正确命中 PROXY 后出现超时，并不能反推规则写错；应继续核对服务器是否有效、是否支持当前请求所需的传输，以及认证是否一致。将所有错误都归因于规则，会掩盖真正发生在连接建立阶段的问题。

DIRECT 表示直接连接目标，不代表跳过名称解析，也不代表目标必然可达。本地网络的路由、防火墙、解析结果和目标自身状态仍然会影响结果。REJECT 表示拒绝符合条件的连接，适合明确需要阻止的范围。拒绝发生后，请求通常不能继续完成，但应用展示的错误可能只是加载失败，而不是直观写出规则名称，因此应结合命中记录判断。

[Rule]
DOMAIN,service.example.com,PROXY
DOMAIN,intranet.example.com,DIRECT
DOMAIN,blocked.example.com,REJECT
FINAL,PROXY

示例中的三个主机名刻意分开，目的是让每种策略的边界容易辨认。实际配置不要先写一条覆盖整个后缀的拒绝规则，再在后面添加某个主机名的允许规则；前一条若已命中，后面的例外便没有机会执行。也不要把 REJECT 当作服务器故障时的备用线路，它负责阻止请求，不会替用户寻找另一条连接路径。

选中服务器不等于所有请求都经由该服务器

在 Config 姿态下，服务器选择与规则策略共同决定结果。某个请求命中 DIRECT，即使当前选中了有效服务器，它仍按直连方向处理。反过来，默认策略写为 PROXY，也不意味着前面的直连和拒绝规则被忽略。因此查看服务器名称只能回答“代理方向准备使用哪个目标”，不能独立回答“这个请求为什么走了这里”。

需要对比代理与直连时，应选定同一个测试目标，分别记录模式、网络类型和测试时间段，完成后恢复原有的 Config 姿态。不要同时更换服务器、改动 DNS 和切换模式，否则结果改善时无法知道是哪项变化起作用。若只有代理方向失败，可继续查阅节点超时与连接失败的核对顺序；若只有某个域名失败，则应把注意力重新放回匹配条件与解析结果。

三、DOMAIN 系列规则与域名范围

DOMAIN：匹配一个明确的主机名

DOMAIN 用于精确域名匹配。规则中的条件应是主机名，而不是完整网页地址，因此不要带入协议前缀、路径、查询参数或端口。一个网页地址可以同时包含这些组成部分，但域名规则只关注其中的主机名。若希望只处理某个网页路径，应考虑其他适用机制，不能把路径直接接在域名后面，期待精确域名规则理解整段地址。

例如下方第一条只针对 api.example.com，不会因为它属于同一组织就自动覆盖 www.example.com。精确规则适合范围已经确认的单个服务入口，也适合放在宽泛规则之前表达例外。编辑时从请求记录复制主机名比凭页面名称猜测更可靠，因为页面展示的品牌名与实际请求域名未必相同，静态资源和认证请求也可能使用其他主机名。

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

DOMAIN-SUFFIX：按域名层级覆盖后缀

DOMAIN-SUFFIX 适合一个根域名及其下级域名需要相同策略的情形。条件写为 example.com 时，覆盖根域名及相应子域名，但不是任意包含这段字符的名称。域名层级有明确边界，这一点与关键字匹配不同。通常不需要在条件前添加星号；把浏览器或其他语法中的通配符习惯直接搬进来，可能使规则失去原本想表达的含义。

后缀规则减少了逐个维护子域名的工作，但也扩大了影响范围。若同一后缀下既有需要代理的接口，又有只在本地网络开放的服务，直接统一指定策略可能影响其中一类。合理方法是在前面列出范围更小的例外，再放后缀规则。上方示例中的登录主机名先命中 DIRECT，其余同后缀请求再由后续规则处理，顺序是配置意图的一部分。

DOMAIN-KEYWORD：字符串条件与误匹配

DOMAIN-KEYWORD 判断域名中是否包含指定关键字，适用范围比完整域名后缀更宽。它不会理解关键字的业务含义，也不会判断某个名字是否确实属于广告、分析或更新服务。使用过短的条件容易误伤无关域名，尤其是常见字母组合。下面的片段只是说明写法，不能把其中的关键字视为经过验证的屏蔽清单，更不应未经测试就追加到日常配置。

[Rule]
DOMAIN,downloads.example.com,DIRECT
DOMAIN-KEYWORD,ads,REJECT
FINAL,PROXY

示例先给明确主机名保留例外，再演示关键字拒绝。即便如此，其他带有相同字符的域名仍可能被拒绝。出现部分图片不加载或登录流程中断时，应先查看实际失败请求的主机名，再检查是否被这类宽泛条件覆盖。若只是想处理一个已知域名，优先使用精确或后缀规则，通常更容易解释，也更容易在日后维护时确认影响范围。

把一个页面拆成多个连接观察

网页加载不是只有一个请求。主页面、脚本、图片、认证和接口可能分别连接不同域名；为地址栏中的域名写好规则，不能保证所有资源都走相同方向。验证时应区分“主页面能打开”与“完整功能可用”，并通过新建请求确认各个关键域名。不要因为一张图片失败就把整个站点的规则扩大到更宽的关键字，也不要把暂时出现的第三方资源域名一律加入同一个后缀。

域名规则的前提是匹配阶段能够获得域名信息。若请求以地址形式发出，或现有连接已经复用，观察结果可能与刚编辑的域名规则不同。此时先关闭测试页面并重新发起访问，再看记录中实际呈现的目标。能够稳定复现后，才有条件决定应补充域名规则、处理地址规则，还是排查 DNS。相关名称也可在概念速查中交叉查阅。

四、IP、GEOIP 与 USER-AGENT 规则

IP-CIDR 与 IP-CIDR6 的地址范围

IP-CIDR 按 IPv4 地址范围匹配，IP-CIDR6 按 IPv6 地址范围匹配。斜杠后的数字表示网络前缀长度，不是端口，也不是地址数量。前缀越长，所描述的范围通常越小。规则应使用正确的网络地址与前缀组合；仅想匹配单个 IPv4 地址时可以使用完整主机前缀，不能随意省略前缀并假定所有写法具有相同意义。

下面将常见私有地址范围与 IPv6 本地地址范围作为语法示例。是否需要这些规则，应结合实际网络与已有通用设置判断。某些系统流量或通用绕行设置可能在进入普通规则匹配之前就已得到处理，因此看不到某条地址规则的命中，不一定是规则语法错误。尤其在局域网服务排查中，应把设备实际地址、网关和当前网络类型一起记录。

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR6,fc00::/7,DIRECT,no-resolve
IP-CIDR6,fe80::/10,DIRECT,no-resolve
FINAL,PROXY

no-resolve 控制什么

no-resolve 用于避免仅为了评估该地址条件而触发域名解析。它不表示整个应用停止使用 DNS，也不保证这条规则永远不会匹配域名相关连接。如果请求的目标本来就是地址，或者匹配阶段已有可用地址信息，地址条件仍可能成立。理解这一点很重要：这个参数控制的是匹配时的解析行为，而不是把规则改造成只适用于某种应用的特殊条件。

当配置包含大量地址范围时，为每条不必要的匹配都主动解析可能增加等待，也可能让解析路径参与决定结果。相反，全部机械地加上该参数，又可能使原本依赖解析结果的规则在预期阶段无法判断。选择时应先问“这条规则是否必须把一个域名解析成地址才能发挥作用”，再观察实际记录，而不是把参数当作通用提速开关。

GEOIP 是数据库判断，不是网站归属判断

GEOIP 根据目标地址与所用地理地址数据库作判断。常见写法如下，但国家或地区代码描述的是地址数据库分类，并不等于网站经营主体、内容语言或用户所在位置。一个域名可能使用分布式服务，不同网络和时间下解析到不同地址，最终分类也可能不同。因此它适合作为较宽的后续规则，不适合替代已经明确知道用途的精确域名条件。

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

地理规则结果异常时，先确认实际连接地址，再核对命中的是哪条规则。不要仅凭页面语言推断地址应属于哪里，也不要为迁就单个例外而整体反转地理策略。若某项业务必须稳定走指定方向，用更明确的域名规则放在前面通常更容易维护。数据库分类、DNS 结果和业务需要是三个不同的事实，应分别记录。

USER-AGENT 的使用条件

USER-AGENT 按能够观察到的请求标识匹配，而不是按设备中安装的应用名称匹配。下面的写法演示前缀通配条件，但实际能否命中取决于请求是否包含相应字段，以及该字段在处理阶段是否可见。加密请求中的内容不能仅凭一条规则就自动读到；若规则没有命中，应先确认信息可见性，不应立刻扩大匹配范围。

USER-AGENT,ExampleClient*,DIRECT

同一应用也可能调用系统组件或不同网络模块，发出不同标识；不同应用又可能具有相同标识，所以这类规则不适合作为严格的应用身份边界。对于普通按域名分流，域名条件往往更直观。只有已经确认请求标识、了解覆盖范围并能稳定复测时，才应保留相应规则。不要为了让一个匹配条件成立而贸然改变证书信任或扩大内容处理权限。

五、匹配顺序、例外与 FINAL

第一条命中即决定，不自动挑最具体的一条

在通常的 [Rule] 处理逻辑中，规则自上而下评估，首条满足条件的规则决定策略。精确域名并不因为名字更具体就自动获得更高优先级；如果宽泛后缀写在前面并已经命中，后面的精确规则不会再次改写结果。这也是许多“规则存在但没有生效”的原因。检查时不仅要找到目标规则，还应从它上面开始检查可能提前命中的条件。

阅读顺序时可以把每行理解为一个判断：条件成立就采用该行策略并停止，否则继续下一行。注释、分组标题和空行可以改善阅读，但不会建立第二套优先级。把例外写在一个看起来很醒目的标题下面，也不能让它越过前面的有效规则。维护较长文件时，建议用稳定的分组顺序表达意图，而不是依赖记忆判断某条例外应该放在哪里。

[Rule]
DOMAIN,office.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

由明确例外到宽泛条件

上面的示例先处理两个明确主机名，再覆盖整个后缀，然后检查地址范围与地理条件，最后使用默认策略。这个顺序是便于说明的一种组织方法，并非所有网络都必须照抄。如果某项业务要求地址规则始终优先，就需要重新安排并理解对域名条件的影响。关键不在于背诵固定顺序，而在于能够说明每个重叠请求会先遇到哪条规则。

以 office.example.com 为例，即使它也符合后缀条件，第一条仍先确定直连。若把后缀规则移到第一行，结果便会改变。再看一个不属于该后缀的域名：它可能经过地址或地理条件后才到默认规则。逐个构造这种最小测试对象，比只观察日常浏览是否“似乎正常”更能发现顺序问题，也更便于确认一次编辑究竟改变了什么。

FINAL 必须作为剩余请求的出口

FINAL 没有域名或地址条件，用于承接此前没有匹配的请求。它应放在有效规则的末尾。若将它放在中间，后面规则通常就没有执行机会；若同时存在多条默认规则，也不意味着会依次尝试多个策略。下面两种默认方向代表不同的总体取舍：未明确处理的请求交给代理，或交给直连。选择哪一种应与自己的连接目标和已有配置保持一致。

FINAL,PROXY
FINAL,DIRECT

这两段是互相替代的示例，不应为了“保险”同时追加。默认策略影响范围很大，修改前应列出几类代表性请求，包含原本依赖默认方向的服务。仅测试一个已经命中精确规则的域名，无法证明新的默认方向符合预期。若不确定当前文件的设计，应先保留原默认策略，只为明确问题添加局部例外，避免把小范围修正变成全局行为变化。

合并规则时检查重复与遮蔽

合并两份片段不能只看是否存在相同文本，还要检查范围重叠。相同条件重复出现时，前面的通常决定结果；后面的不同策略可能只是没有机会执行。宽泛关键字、后缀、地址范围也可能遮蔽后续例外。清理时先保留原文件副本，再按目标域名追踪第一次命中位置，确认后才删除冗余内容。直接对整份文件按字母排序会破坏原有优先级，不适合有顺序含义的规则段。

发现被遮蔽规则后，还需判断它是无意重复，还是为了将来切换用途保留的说明。实际生效文本应尽量明确，维护笔记则记录在不参与执行的位置。修改后重新发起连接，避免把旧连接继续传输误认为新顺序无效。若有多个相关主机名，要分别检查；一条规则的优先级正确，并不能保证整组业务依赖都已覆盖。

六、DNS、Host 与连接地址的关系

解析回答地址，规则决定策略

DNS 主要回答主机名对应什么地址，规则主要回答请求使用什么策略。两者会相互影响，但不是同一件事。域名解析成功，只能说明获得了地址，不表示目标端口可连接；命中代理规则，也不表示解析一定按用户想象的路径发生。排错记录应分别包含主机名、解析结果、命中规则与最终连接状态，不能把“打不开”当作对所有阶段的共同结论。

[General] 中的解析设置会影响后续判断所依赖的信息。使用系统解析时，结果可能随当前 Wi-Fi 或蜂窝网络变化；使用其他明确设置时，还要考虑该解析服务本身是否可达。不要同时更改多个解析选项后只凭页面打开速度判断好坏。一个域名可能有缓存，页面还可能复用连接，这些因素都会让测试看起来比实际配置差异更明显或更模糊。

[General]
dns-server = system

Host 映射不是服务器条目

[Host] 可以为明确的主机名指定地址。下面将教学域名映射到文档示例地址，用于说明格式，不表示该地址存在可访问的服务。等号左侧是主机名，右侧是目标地址。它不是给 Add Server 填写代理服务器，也不会改变远端服务的认证信息。不要把订阅中的服务器地址或密码搬到这个分段，期待它完成服务器导入。

[Host]
service.example.com = 192.0.2.10
assets.example.com = 198.51.100.20

固定映射适合有明确地址要求的受控环境，但会绕开域名原有的动态调度。服务迁移、地址失效或网络位置变化后，旧映射可能继续把请求指向不适合的目标。若某个域名只有在启用特定配置时异常，应检查是否存在遗留映射，再比较系统解析与配置解析得到的地址。不要为了暂时恢复访问而长期保留来源不清楚的固定地址。

地址变化不等于证书身份变化

通过主机名访问加密服务时，连接地址与服务器身份校验有关联，但不能相互替代。把域名映射到另一个地址，不会让那个地址上的任意服务自动具备正确证书，也不会保证它识别所需主机名。出现证书或握手错误时，应核对域名、服务配置与系统时间，不应把降低校验要求当成常规解决方案。若正在核对已有 Trojan 服务器参数，可继续阅读密码、SNI 与 TLS 参数说明。

同样，Host 映射和域名分流也不能简单理解为前者一定覆盖后者。域名条件可能在地址条件之前命中，地址映射影响连接目标，而策略仍由匹配过程决定。若需要验证两者关系，应只为一个教学或受控主机名设置映射，记录实际连接地址，并分别观察域名规则与地址规则的命中。不要依据最后显示的地址反推所有前置步骤。

缓存、双地址与网络切换

同一主机名可能同时具有 IPv4 与 IPv6 结果，具体使用哪一个受网络可达性和连接过程影响。只为 IPv4 编写规则并不自动涵盖 IPv6；反过来，看到一次 IPv6 失败，也不能认定应整体改变地址族设置。应先看实际请求采用哪类地址，再检查相应规则和网络条件。把两个地址族分开记录，可以避免一条测试成功、另一条测试失败时得出相互矛盾的结论。

网络切换之后，解析缓存、应用连接池与旧连接可能仍短暂影响观察。验证新配置时，应结束旧测试连接，再重新访问固定目标；必要时按应用提供的功能清理相关缓存。只清理浏览器页面缓存不一定能重建所有网络连接。若问题只在某一个网络出现，可保持配置不变进行对照，这有助于区分本地网络差异与配置本身的错误。

最终应让解析设置保持可解释：知道所选来源是什么，知道固定映射为何存在，知道哪些地址规则依赖解析。配置中越多历史选项和未知映射，出现故障时需要排除的分支就越多。无法说明用途的设置不要在工作副本里反复叠加，先回到最小可用状态，再逐项恢复必要内容。

七、URL Rewrite 的语法与处理边界

改写请求地址，不等于选择连接策略

[URL Rewrite] 处理的是符合条件的可见请求地址，[Rule] 处理的是连接策略。两者不能相互替代。把一个地址改写到另一个主机名，并不等于已经指定代理方向；新目标仍需结合相关配置与实际处理阶段判断。反过来，域名规则只能决定路由方向，不能将某个路径自动改成另一个路径。先明确问题属于地址转换还是连接去向，再选择分段。

改写规则通常由匹配表达式、目标和动作组成。表达式中包含特殊字符时，要理解正则表达式含义，而不是只按普通字符串阅读。点号在正则中具有特殊作用，若希望匹配域名中的实际点号，需要正确转义。开头锚点可限制匹配起始位置，结尾锚点可限制完整边界；遗漏边界时，表达式可能比预期匹配更多内容。

[URL Rewrite]
^http://example\.com/(.*) https://example.com/$1 302

逐项读懂示例

示例从地址开头匹配明确的协议与主机名，将斜杠后内容捕获为一组，再通过 $1 放入目标地址。动作 302 表示临时重定向。这里使用保留的教学域名，不代表需要把它加入个人配置。实际使用前，应确认目标服务确实支持目标协议和路径；重定向只能告诉请求方去访问另一个地址，不能让本来不存在的服务变得可用。

表达式与目标之间的空白承担分隔作用，因此不要在表达式中随意加入未处理的空格。复制规则时也要留意文本编辑器是否替换了引号、反斜杠或标点。与简单域名规则相比，正则改写更容易出现“语法能读取、范围却不符合预期”的问题。验证不应只包含一个成功样例，还应包含相似但不应命中的地址，以检查边界是否足够严格。

可见性是改写的前提

加密连接的完整路径与查询参数通常不能仅凭域名路由直接读取。只有在应用具备相应请求信息、且请求处于可处理的条件下，相关改写才可能执行。看得到连接域名，不表示看得到完整地址；看得到一个地址，也不表示所有应用的请求都以相同形式经过处理。因此规则未执行时，应先核对请求是否可见与是否符合表达式，再考虑动作和目标。

不要为了验证一条普通改写，就扩大到所有域名的内容处理或改变证书信任。涉及加密内容的处理具有独立的安全边界，也可能受到应用自身校验影响。此处不把这些条件当作常规分流的必要步骤。只需要按域名选择代理、直连或拒绝时，使用 [Rule] 即可，不需要额外引入地址改写来完成相同目的。

防止循环、路径丢失与敏感信息迁移

重定向目标若再次符合原表达式，可能形成循环。即使看起来只改变了协议，也应检查目标服务是否又把请求重定向回原地址。路径与查询参数是否保留也要明确：捕获范围过小可能丢失必要参数，过大则可能把不应传给新目标的内容一并带走。尤其是认证相关请求，不应在不了解参数用途时将其改写到另一个主机名。

多条改写同时存在时，应逐条分析匹配范围，先测试单条，再恢复组合。使用同一个初始地址反复测试时，还要考虑请求方是否缓存了重定向结果。页面直接进入新地址不一定证明当前规则仍在执行，也可能是请求方沿用了此前结果。为避免混淆，应记录首次输入地址、最终地址以及实际命中的规则，并在需要时用新的会话重新验证。

当业务目标只是阻止某个已知主机名的连接时，明确的 REJECT 规则通常比复杂改写更容易维护；当目标只是更换策略时，也应回到规则段。只有确实需要地址转换、能够说明匹配和目标的关系、并具备稳定测试方法时，才保留改写。删除暂时实验过的规则同样重要，避免旧规则在之后某次访问中再次触发。

八、配置验证、故障定位与维护流程

建立可以重复的测试基线

开始修改前，应确认当前网络能够完成基本访问，记录所用网络、当前配置、Global Routing 姿态和选中服务器。测试目标应固定，并分别准备一个精确规则目标、一个后缀规则目标以及一个依赖默认规则的目标。每次只修改一个条件，保存后重新建立连接。这样的基线比连续追加规则更有价值，因为一旦结果变化，可以明确对应哪次编辑。

测试通过也应有清楚定义。页面打开只证明其中一部分请求成功；登录、接口和资源加载可能仍有独立问题。可以先验证目标请求是否命中预期策略，再验证连接是否建立，最后验证业务功能。把这三个结论分开记录，能够区分“规则方向正确但服务器不可达”和“连接正常但业务接口返回错误”，避免在错误层面反复调整。

按条件、匹配、连接、业务分层检查

  1. 条件层：确认应用已连接，选用正确配置，并处于 Config 姿态。
  2. 匹配层：核对实际主机名或地址，从规则顶部寻找第一次命中。
  3. 连接层：检查解析、目标可达性、服务器认证和传输参数。
  4. 业务层：检查目标服务响应、账号状态以及多个依赖请求是否完整。

如果没有按预期命中，先排除宽泛规则遮蔽、规则放在默认项之后、保存了错误文件或测试仍复用旧连接。若已命中预期策略但连接失败，则暂停改规则，转去检查该方向的实际可达性。Connectivity Test 有助于比较已有服务器的连接表现，但测试成功不保证任意业务目标都能使用，测试失败也不能单独说明是哪一个协议参数出错。

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

这份小片段可以用来理解验证思路：精确目标应先命中代理，同后缀的其他主机名应走直连，范围之外再看默认策略。实际操作需要使用自己有权测试、且确实存在的目标替换教学域名。不要直接用教学地址是否能打开来判断配置正确与否；保留域名和文档地址的作用是说明语法，不是提供网络连通性检测服务。

区分规则问题与速度问题

方向正确仍然速度慢时，应比较本地网络质量、目标服务、服务器负载与协议参数，而不是不断扩大代理范围。延迟测试与实际传输速度也不是同一指标，一次连接建立较快，不表示长时间传输一定稳定。保持配置不变，分别观察不同网络中的同一目标，通常比同时更换配置和服务器更容易定位原因。具体方法可接着阅读速度慢的分层排查。

如果问题只在切换网络后出现，检查连接是否重新建立、解析是否改变，以及 On Demand 是否影响了连接时机。按需连接负责触发连接，不会代替域名规则决定策略。不要把自动连接时机与规则匹配混成一个开关。需要调整这部分时，可参照On Demand 与后台耗电排查，完成后再用相同测试目标验证。

保留改动记录与可恢复副本

稳定配置应留有一份明确的恢复副本。记录无需包含完整订阅地址，只需写清修改目的、涉及分段、影响范围和验证结果。远程配置更新后，先比较默认策略、通用设置和个人例外是否变化，再切换正式使用。一次合并大量未知规则会增加解释成本，也可能引入重复条件与过时映射；按实际需求逐项添加，更容易在后续维护中判断哪些内容仍然必要。

对外展示排错信息前，应移除用户自己的订阅认证参数、服务器密码、个人地址与业务敏感路径。截图或文本只保留定位问题所需的模式、规则类型和经过处理的目标信息即可。本站是 Shadowrocket 官网与官方手册；应用为闭源商业应用，iPhone 与 iPad 的系统要求以 App Store 页面标注为准。购买核对见正版核验三要素，常见初次连接问题可返回使用说明逐步检查。

最终维护目标不是规则越多越好，而是每条规则都能说明用途、每个例外都有可验证范围、每次更新都有恢复路径。遇到新问题时，先复现，再定位首次偏离预期的阶段，最后做最小修改。能够从请求目标一路解释到策略和连接结果，才算完成一次配置验证。