Shadowrocket
规则与配置参考

先找到当前文件，再区分每个段落负责的任务。

从 Config 确认实际使用的文件

配置文件不是服务器列表的另一种写法。服务器信息负责描述连接远端所需的地址、端口、协议和认证参数；配置文件则规定请求如何分类、怎样选择策略，以及部分解析和处理行为。打开 Config 后，应先确认当前启用的是哪份文件，而不是看到文件已经导入就认为它正在生效。文件存在、内容保存、文件选中、Global Routing 采用 Config，是四个需要分别核对的状态。若刚修改的规则没有影响连接，先检查这四处，通常比继续添加同类规则更有效。

开始编辑前，为当前可用文件保留副本，并记录正在使用的服务器与 Global Routing 状态。对首次查阅者，建议先读文件中的段落标题，再读各段字段，不要从第一行逐字猜测整份配置。方括号标题用于切换配置段，后面的内容按所属段落解释；相同文字出现在不同段落时，不一定具有相同含义。示例中的域名均用于说明语法，不代表可以直接使用的连接服务。

四个常见段落的职责

General 中的设置作用于基础处理环境，不应把普通分流行写在其中。Rule 中的每一行则描述一个匹配条件及其结果，例如域名命中后选择 DIRECT。Host 改变的是特定主机名的解析映射，并不等于给该主机指定代理策略。URL Rewrite 处理可见的请求地址，不能替代 Rule 对普通连接的路由判断。把这四件事混在一起，会出现“域名已经映射了地址，为什么仍然走代理”这样的误解：地址来源与策略来源本来就是两个判断。

[General]
dns-server = system

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

这份最小片段采用系统 DNS，为 example.com 及其子域指定 PROXY，为一个局域网网段指定 DIRECT，其他连接由 FINAL 承接。它不包含可用服务器，也没有表达完整网络需求，作用是让段落边界和规则结构清楚可见。不要为了凑齐目录而添加空的 Host 或 URL Rewrite 段；没有相应需求时，保持文件精简，更容易判断每次修改带来的影响。

编辑、保存与导入不是同一件事

从文件导入配置后，先检查段落是否完整、换行是否保留、逗号是否为英文字符。复制自富文本的内容可能带有中文标点、不可见空格或换行折叠，外观接近正确，解析结果却不同。保存后重新打开编辑内容，确认实际落盘的文本与预期一致；再回到 Config 确认所选文件。若更新了远程来源的配置，本地手工调整是否保留应单独验证，不要把一次成功保存当作以后更新都能自动合并的保证。

遇到来源较复杂的文件，先建立一份可解释的基线，再逐项移入确有用途的设置。每移入一组内容就测试一次，不必一次复制所有高级字段。文件名只能帮助识别，不能证明内容适合当前设备；同样，注释写着“直连”也不能覆盖实际策略词。最后以保存后的文本、当前模式和连接记录共同确认结果，这也是后续各章采用的判断方式。

Global Routing 决定路由姿态，策略决定命中后的处理方式。

Config、Proxy、Direct 的判断入口

Global Routing 中的 Config、Proxy、Direct 是路由层面的选择，不是某一条规则的同义名称。配置姿态 Config 用于按照当前配置处理连接，是核验 Rule 段时首先需要确认的入口。代理姿态 Proxy 适合临时检查代理路径，直连姿态 Direct 适合对照本地网络路径，但不能据此推断每一个系统连接都经过同样的处理。基础绕过设置、系统保留连接和具体网络环境仍可能影响观察范围，判断时应限定到正在测试的那个请求。

例如，某个域名在 Proxy 下可以连接，切回 Config 后失败，这只能把调查方向缩小到配置路径、解析差异或策略选择，不能直接认定所有域名规则都有问题。应查看 Config 下该连接命中了哪一行，以及策略最后指向了什么。反过来，Direct 下可访问而 Proxy 下失败，也应检查用户已有服务器的连接参数、远端可达性与协议要求，而不是立即把域名加入更多 DIRECT 列表。

PROXY、DIRECT、REJECT 的执行含义

规则行中的 PROXY 表示采用代理路径，但它本身并不包含服务器地址。实际使用哪一个连接对象，还要结合当前服务器选择及配置中的策略引用。DIRECT 表示直接连接目标，不通过该条规则指定的代理路径；这并不代表不会发生 DNS 查询，也不保证目标一定可达。REJECT 用于拒绝匹配连接，适合明确需要阻止的目标。规则阻止成功与页面能够正常使用是两种不同结果，某些页面依赖的资源被拒绝后，功能可能随之失效。

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

这三个域名分别演示三种策略，不能作为完整业务配置直接套用。把 DIRECT 改成 PROXY，只改变连接路径的选择，不会自动修正目标地址、证书或认证参数。把失败连接改成 REJECT，也不是修复失败，而是主动终止连接。维护配置时，应在注释中说明“为什么需要这个策略”，而非只重复英文词的中文意思，这样在网络环境改变后才知道哪些规则应重新评估。

策略名称、选择对象与失败回退

若文件使用自定义策略名称，必须确认名称在当前配置中有对应定义，大小写和空格也应与实际内容一致。不要只复制引用行而遗漏被引用的策略。对于包含选择或探测逻辑的策略，规则命中只完成了第一层分类，最终连接还可能受所选对象状态影响。因此，记录中看到预期策略名之后，仍要继续检查实际连接对象。规则正确、服务器不可用，是能够同时发生的情况，两者需要分开处理。

还应区分“未匹配到前序规则”和“命中后连接失败”。前者由后续规则或 FINAL 继续处理；后者通常不会因为连接失败就自动把同一个请求送回 Rule 段，寻找下一条能够连通的规则。是否存在重试或策略内部的切换，取决于对应配置和功能，不能把 Rule 的排列顺序当作备用服务器列表。这个区别能够解释很多“第二条明明可用，为什么没有继续尝试”的疑问。

完成模式或策略调整后，应重新建立测试连接，并记录调整前后的模式、命中行和连接对象。不要仅用连接开关的外观判断成功，也不要一次改变模式、服务器与 DNS 三个变量。保持其余条件不变，才能解释变化来自哪里。若目标是学习规则，优先在 Config 下使用少量明确规则建立可重复结果，再扩大到日常配置。

精确域名、域名后缀与字符串包含，覆盖范围依次不同。

DOMAIN：只匹配完整域名

DOMAIN 用于匹配一个完整域名，适合给单个服务入口设置明确例外。规则 DOMAIN,api.example.com,PROXY 的目标是 api.example.com，不应把它理解为 example.com 下的所有主机。域名字段不写协议前缀，不写路径，不写端口，也不把浏览器地址栏中的整段 URL 原样贴入。若需要区分同一主机的不同路径，普通 DOMAIN 规则并不提供这种粒度，必须先确认需求属于域名路由还是请求地址处理。

精确规则的优势是影响范围可控，也便于在日志中建立对应关系。为某个接口添加例外时，先确认实际请求主机，而不是仅看页面地址。一个页面可能请求登录域名、静态资源域名和接口域名；只修改主页面的规则，其他请求可能仍采用原策略。遇到页面部分正常、部分失败时，应分别检查失败连接的目标，不要把页面整体当成只有一个域名的单次请求。

DOMAIN-SUFFIX：按域名层级覆盖

[Rule]
# 精确例外应放在较宽的后缀规则之前
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

DOMAIN-SUFFIX,example.com,DIRECT 用于覆盖 example.com 及其子域。它按域名后缀边界处理，不是任意位置的字符串包含，因此不应把另一个名称中恰好带有 example.com 字样的无关域名视为必然命中。填写后缀时通常不加星号，也不写开头的协议。将这条宽规则放在精确例外之后，api.example.com 先被第一行命中，其余属于该后缀的目标才进入 DIRECT。

若把上述两行顺序反过来，宽规则会先接住 api.example.com，后面的精确规则即使写得更详细，也不会自动取得优先权。配置审阅时，既要看规则表达了什么，也要看它前面有哪些覆盖范围更大的行。后缀规则适合表达同一域名体系的共同策略，但并不意味着这个体系的所有依赖都在该后缀内；外部资源和跳转目标仍可能需要单独判断。

DOMAIN-KEYWORD：谨慎使用宽泛包含

DOMAIN-KEYWORD 按域名中的关键字符串匹配，适合确实需要跨多个域名体系捕获共同文字的情况。它不按品牌含义识别目标，也不会验证域名归属。例如关键字 example 可能匹配多种包含该字符串的主机，范围通常大于一个明确后缀。若目标只是 example.com 及其子域，优先考虑 DOMAIN-SUFFIX；使用宽关键字之前，应列出可能被误收的目标，再决定是否接受这种覆盖。

这三种规则没有天然的“精确类型高于宽泛类型”排序。它们仍然遵循 Rule 段中的排列顺序。因此，可以把最小范围的业务例外放在前面，再放共同后缀，最后才考虑确有必要的关键字。这样的组织方式是为了提高可解释性，而不是配置解析器强制要求的格式。若一条关键字规则已经覆盖多个后缀，继续添加相同策略的后缀行可能只是增加维护负担。

域名不可见时，不强行归因

应用通过 IP 地址直接连接、使用自身解析机制，或在记录中缺少域名信息时，不能假定 DOMAIN 系列规则仍能拿到完整主机名。此时应先检查记录中可见的目标，再决定是否需要 IP 规则。不要因为浏览器里看到了域名，就推断所有底层连接都具有同样的信息。域名规则是否参与匹配，取决于该连接进入处理流程时能获得什么，而不是用户在其他界面看到了什么。

整理域名列表时，建议为每组规则注明用途及例外，并移除已被前序同策略规则完整覆盖的重复项。测试至少包括目标域名、一个子域和一个相似但不应命中的域名。这样既能证明规则收到了需要的连接，也能检查边界没有扩得过宽；只测试一个成功目标，无法说明规则范围正确。

不同规则读取不同信息，先确认连接实际提供了什么。

IP-CIDR 与 IP-CIDR6 的网段表达

IP-CIDR 使用网络地址和前缀长度描述 IPv4 地址集合，IP-CIDR6 用于 IPv6。前缀长度越大，集合越小；单个 IPv4 地址可以使用 /32 表达，单个 IPv6 地址可以使用 /128 表达。添加网段前，应确认该范围是否属于你确实需要处理的目标，不要因为其中一个地址访问失败，就把很大的地址块全部改为同一种策略。目标使用共享基础设施时，过宽的网段可能影响与原需求无关的服务。

[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
GEOIP,CN,DIRECT
FINAL,PROXY

前两行演示常见私有 IPv4 范围，第三行演示 IPv6 唯一本地地址范围，不能据此认为所有本地网络都已覆盖。具体局域网可能采用其他私有网段，也可能存在不同地址规划；应按设备实际网络检查。IPv6 不是 IPv4 规则的自动补充对象，写了 IPv4 网段并不代表对应业务的 IPv6 连接采用相同策略。若相同域名的连接结果偶尔不同，记录中的地址族值得单独核对。

no-resolve 限制额外解析，不创造目标地址

IP 规则后面的 no-resolve 用于避免为了该规则的匹配而主动发起域名解析。它适合处理本来就已知目标地址的连接，或避免在一组 IP 规则中提前触发不必要的解析。它不表示完全关闭 DNS，也不表示所有域名都会跳过后续地址判断。若当前连接只有域名而没有可用目标地址，这条带 no-resolve 的 IP 规则可能无法据此完成匹配，最终仍需由其他规则决定策略。

因此，给一个本地域名设置 DIRECT 时，仅添加私有网段加 no-resolve 未必足够。如果主机名只在本地 DNS 中有效，应同时检查该主机怎样解析、解析结果是否可见，以及更前面的域名规则是否已经接住了请求。不要把 no-resolve 当作提升速度的通用开关。它改变的是匹配过程中是否进行额外解析，应根据需要控制查询行为，而不是在所有规则末尾机械添加。

GEOIP 是地址分类，不是业务归属判断

GEOIP,CN,DIRECT 表示按地址数据库对目标 IP 的分类应用 DIRECT。它不识别网站使用的语言，不按域名后缀判断，也不能证明运营主体或内容存放位置。数据库、目标实际地址与解析结果都会影响命中。一个域名可能对应多处基础设施，后续解析变化也可能改变地址分类，所以需要稳定策略的具体业务，通常更适合先通过明确域名规则表达意图，再把 GEOIP 作为较宽的后层分类。

排查 GEOIP 时，先记下本次连接实际使用的地址，再检查前序域名规则是否已经终止匹配。看到目标地址属于预期范围，不代表一定轮得到 GEOIP 行执行；反过来，未命中 GEOIP 也不能立即归因于数据库错误，还可能是连接没有进入这条判断路径。不要将地理分类当作精确安全边界，尤其不要用它代替身份认证、访问控制或对服务器证书的核验。

USER-AGENT 的可见性边界

[Rule]
# 仅在请求信息可供匹配时评估此条件
USER-AGENT,ExampleApp*,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

USER-AGENT 匹配请求中可获得的 User-Agent 信息，示例中的星号表示模式中的通配部分。它不是按设备上安装的应用名称进行进程识别，也不能保证识别一个应用的全部连接。加密请求或不携带相应字段的连接，可能没有可用于该规则的信息。排错时，应把“应用发出了连接”和“该连接提供了可匹配的 User-Agent”分开，不能仅凭应用名称推断规则应该命中。

对同时使用多类条件的文件，可按“明确域名例外、确需使用的请求信息条件、特定网段、较宽地址分类、FINAL”组织阅读，但最终顺序仍由业务意图决定。每加入一个条件，都应说明它依赖哪种信息，以及信息缺失后由谁承接。这样的记录比单纯统计规则数量更能帮助维护，也能避免把不同规则误认为同一层面的重复写法。

自上而下，命中即停；更具体不等于自动更优先。

按顺序推演，而不是凭规则名称判断

Rule 段的基本阅读方法，是把一个具体请求带入规则，从第一行开始依次检查。遇到能够匹配的条件，就使用这一行指定的策略，不再用后面的普通规则重新分类。因此，一条写在前面的宽泛条件可以覆盖后面很多精确条件。所谓“例外优先”，不是某种隐藏机制，而是维护者主动把例外放到共同规则之前形成的结果。看懂文件时，应先画出覆盖关系，再判断是否需要调整顺序。

[Rule]
# 先保留单个主机的例外
DOMAIN,api.example.com,PROXY

# 再处理整个域名体系
DOMAIN-SUFFIX,example.com,DIRECT

# 已知局域网目标
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

# 较宽的地址分类
GEOIP,CN,DIRECT

# 其余连接的最终策略
FINAL,PROXY

对 api.example.com，第一行已匹配，后缀行不再改变它的策略。对 static.example.com，第一行不匹配，后缀行将其送往 DIRECT。对一个已知的局域网 IP，前面两条域名条件可能不适用，随后由网段条件接住。对没有任何前序条件命中的连接，才使用 FINAL。这里的每一步都是条件判断，不是在多条线路间逐个尝试连通性；命中策略后的网络失败属于后续执行阶段。

FINAL 表达剩余集合

FINAL 不是“最重要的一条域名规则”，而是没有被前序条件分类的剩余连接的最终策略。FINAL,PROXY 适合表达默认采用代理路径的设计，FINAL,DIRECT 则表达默认直接连接的设计。两者没有脱离上下文的优劣，应结合前面的例外集合与用户的实际需求选择。修改 FINAL 的影响往往比添加一条精确域名规则更大，因为它改变的是整个未覆盖集合，而不是单个目标。

应把 FINAL 放在规则清单末尾，并避免在其后继续添加希望生效的普通规则。维护者若只在文件最后追加内容，却没有注意前面已有 FINAL，新行可能永远没有机会执行。合并文件时尤其要查找重复 FINAL：不能把两份各自完整的 Rule 段直接拼接后，期待第二份仍按原样工作。先确定统一的默认策略，再将两份文件的有效例外重新整理到这一条 FINAL 之前。

重复、冲突与不可达规则

同一条件重复出现而策略相同，通常只增加阅读成本；相同条件出现不同策略，则由较早的那一行决定。更隐蔽的冲突来自包含关系：例如前面的 DOMAIN-SUFFIX 覆盖后面的 DOMAIN，或者宽网段覆盖更小网段。审阅时不要只搜索完全相同的文本，还要比较目标集合是否重叠。若确实需要小范围例外，应将小范围条件上移，并在注释中解释它与后层规则的关系。

配置中若还引用外部规则集合，也应把引用行视为当前顺序中的一个判断入口，而不是完全独立的另一套优先级。外部内容变化可能扩大或缩小匹配范围，导致后续本地行不再收到原来的请求。更新后出现差异时，需要同时检查本地引用位置和外部内容变化；仅比较本地文件是否改动，可能遗漏真正改变匹配结果的部分。

建立可重复的测试矩阵

调整顺序前，选取至少四类测试对象：精确例外、共同后缀、已知本地地址以及应由 FINAL 承接的目标。为每个对象写下预期命中行与策略，再逐个新建连接验证。测试不要求记录大量数字，关键是同一个目标在相同模式下得到可解释结果。若新规则修复了一个目标，却改变了另一个本来正常的目标，应回到覆盖关系，而不是继续在文件末尾追加补丁。

最后，把规则顺序的理由保存在相邻注释里，尤其标记那些必须先于宽规则的例外。以后重排或合并文件时，这些说明能防止“按类型整理得更整齐”却破坏实际行为。规则清单的目标不是视觉排序，而是让预期请求在正确的位置停止判断，并让未覆盖目标有清楚的最终去向。

解析、路由与请求重写相互关联，但不能互相替代。

先区分域名解析与连接路径

DNS 负责把主机名解析为地址，Rule 负责决定连接采用什么策略。两者会影响彼此的观察结果，但不是同一个开关。一个域名可以先通过某种解析路径得到地址，再由规则决定直接连接或使用代理；某些连接方式还可能在不同位置完成解析。排错时，应分别记录“拿到了什么地址”和“连接使用什么策略”，不要看到 PROXY 就推断解析必然发生在远端，也不要看到 DIRECT 就推断所有解析都遵循同一种本地路径。

[General]
dns-server = system

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

dns-server = system 表示使用系统提供的 DNS 配置，是说明基础行为的一个简洁起点，并非所有网络环境的固定答案。若系统 DNS 无法解析某个内部主机，单纯给这个主机设置 DIRECT 不会凭空生成正确地址。应先确认该名称是否需要特定网络才能解析，再检查设备是否处于对应环境。反之，域名可以正常解析也不证明目标端口可达，解析成功只完成了连接前的一部分工作。

Host 映射的用途与维护成本

[Host]
# 文档示例地址，不代表可连接的业务主机
lab.example.com = 192.0.2.10

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

Host 段可为指定主机名提供明确地址映射。示例中的 192.0.2.10 是文档用途地址，只展示字段结构。上面的映射不包含 DIRECT 含义，真正的策略仍在 Rule 中说明。使用真实映射时，要确认地址属于预期目标，并考虑证书、服务端主机识别与业务更新。把域名固定到旧地址可能让解析看似稳定，却使业务迁移后的请求一直指向失效位置。

临时诊断可以借助映射隔离解析因素，但验证完成后应决定是否保留，并记录保留理由。若目标采用动态地址或负载分配，长期静态映射可能破坏原有调度。不要从一次解析结果复制地址后，就把它当作永久正确的业务地址。出现证书名称不匹配时，也不能通过随意关闭校验掩盖问题；应检查目标地址、主机名和服务端证书是否本来就一致。

URL Rewrite 处理的是可见的请求地址

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

这条示例使用正则表达式限定一个完整地址，并以 302 重定向到另一个地址。开头的 ^ 和结尾的 $ 限定匹配边界，域名中的点用反斜杠转义，避免被解释为任意字符。若请求带有查询参数或结尾斜杠，它可能不符合这个完整表达式；这不是重写失效，而是条件本来没有覆盖该形式。编写表达式时应先列出需要匹配的地址形式，再决定是否放宽边界。

重定向也不等于为原连接选择 PROXY 或 DIRECT。浏览器收到重定向后可能发起新的请求，新请求仍需依据自己的目标进入路由判断。若重写后形成循环，应检查新地址是否再次满足同一条或另一条表达式。测试时先使用一条范围很小、结果容易观察的规则，不要一开始就对整个域名体系使用宽泛表达式，否则很难定位是哪一次跳转改变了请求。

尊重加密请求的可见性边界

HTTPS 的完整路径通常不直接暴露给普通网络路由处理。配置中写了 URL Rewrite，不代表所有加密请求都自动提供完整 URL 供匹配；是否可处理，还取决于请求可见性与相关设置。普通域名分流不需要为了读取路径而扩大处理范围。本页的重写示例仅解释段落语法，不要求为学习规则启用额外证书相关功能，更不应把这类设置作为解决所有连接问题的第一步。

维护这些段落时，还要考虑缓存与既有连接。系统、应用或浏览器可能保留解析结果、跳转结果或连接状态；修改后应使用新请求复测，并区分缓存现象与配置未生效。若在不同应用中结果不同，先比较它们实际请求的域名、地址和协议，不要直接归结为某个段落优先级不同。最终仍以本次可见记录解释本次连接。

把需求写成小范围条件，再用可回退的方式逐步合并。

先用一句话定义默认行为

编写配置前，先回答两个问题：未被专门列出的连接应该怎样处理，哪些目标需要偏离默认行为。前一个问题对应 FINAL，后一个问题形成例外集合。若无法用一句话解释默认行为，通常也难以判断一条新增规则是否必要。不要从收集大量域名开始，再反过来猜整份文件的用途。规则越多，覆盖关系越复杂，而维护成本并不会因为内容来自不同文件就自动降低。

[Rule]
# 默认代理，仅对明确目标设置直接连接
DOMAIN,printer.example.com,DIRECT
DOMAIN-SUFFIX,home.example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,PROXY

这组示例描述默认代理、明确目标直连的结构。其中 printer.example.com 和 home.example.com 都是示例名称，需要用户按自己实际环境判断，不能直接提供本地服务。若你的需求是默认直连、仅部分域名代理，则应反过来建立少量 PROXY 条件，并将 FINAL 改为 DIRECT。不要把两种默认设计的文件直接叠加，否则一份文件中的例外可能在另一份文件里变成冗余或冲突。

例外、共同规则与阻止目标

[Rule]
# 单个主机先于共同后缀
DOMAIN,api.example.com,PROXY
DOMAIN,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

这一组合同时包含代理例外、拒绝例外和后缀共同策略。两个精确主机放在后缀之前，才能保留不同的处理方式。REJECT 应用于明确希望停止的目标，不宜因为某次连接慢就直接加入。若一个页面在加入拒绝规则后功能减少，先检查是否阻止了必要接口，而不是继续修改 DNS。规则能够正确命中，并不代表规则所表达的业务决定一定合适，验证必须同时覆盖路由与功能。

为本地设备配置直连时，也不要把所有出现过的地址都写成长期规则。先判断设备是否采用固定地址、主机名是否稳定，以及访问是否需要同一局域网。规则只能决定路径，不能让不在当前网络中的设备自动变得可达。如果需求依赖某个本地网段，应在切换 Wi-Fi 后重新核对地址规划，避免把另一网络中含义不同的同一地址范围误认为原来的设备环境。

把订阅数据与规则文件分开管理

Subscribe 导入的连接信息与 Config 中的规则配置承担不同任务。更新已有订阅后，服务器名称、数量或参数可能变化；若配置通过名称引用连接对象，就要检查这些引用是否仍然有效。不要认为订阅更新会自动修正所有本地策略引用，也不要把规则文件备份当作完整保存所有连接凭据。迁移时，应分别核对连接信息、当前配置和模式状态，确认三者能够重新组合工作。

用户已有的订阅地址、认证参数和私钥都属于敏感信息。向他人说明问题时，应隐藏这些内容，只保留必要的规则条件、策略名和错误阶段。示例文件也不应含有真实凭据。若需要理解 WireGuard 字段与路由规则的分工，可参阅WireGuard 配置参数说明：协议参数决定连接如何建立，Rule 决定哪些目标选择该路径，两层配置不能互相替代。

合并、更新与回退的操作顺序

合并配置时，先备份当前可用文件，再列出准备新增的实际需求。检查新内容是否引入新的 General 设置、Host 覆盖、URL Rewrite 或策略引用，而不只是比较 Rule 行数。随后移除重复 FINAL，将例外置于相关宽规则之前，并验证被引用名称存在。每次只合并一组相关规则，保存并启用后测试代表性目标；一旦出现异常，就能明确回退到哪一个修改点。

远程来源的配置更新应当作一次变更审阅，而不是只看更新动作是否完成。比较规则顺序、默认策略和地址覆盖的变化，尤其关注原来本地保留的例外是否仍存在。若需要长期手工维护，尽量减少不清楚用途的高级字段，并为关键规则留下理由。文件越容易解释，故障时越容易恢复；可维护性来自明确边界和验证记录，不来自规则数量。

最后保留一份精简基线，用于区分网络问题和复杂配置问题。基线仍需结合用户已有服务器使用，不是独立连接服务。日常配置异常时，切换到基线进行同目标对照；若基线正常，再逐组恢复复杂规则。这样得到的证据比反复导入整份文件更清楚，也能避免在排查过程中遗失原本有效的设置。

先确认处理链，再用同一目标对照，不以单次成功代替结论。

第一层：确认当前状态与新建连接

出现“规则没有生效”时，先写下设备当前网络、Global Routing、选中配置及连接对象，再重新发起一个目标明确的请求。旧连接可能继续使用建立时的状态，不能只修改文件后刷新一个仍复用连接的页面就下结论。连接开关开启只说明客户端进入相应工作状态，不证明目标已被预期规则处理。需要查的是本次请求的实际记录，而不是某个按钮看起来已经处于正确位置。

接着确认测试目标是否单一。浏览器地址栏里的页面可能发起多种资源请求，一张图片成功并不证明接口连接成功，一个接口失败也不代表整个域名体系都失败。选择其中一个可以明确识别的失败主机，记录域名或 IP、命中规则、策略和错误表现。若当前界面没有提供某类信息，应明确记为未知，不要根据页面现象补出不存在的匹配记录。

第二层：区分未命中、错误策略与执行失败

若命中 FINAL，先从首行推演同一目标，检查是否把完整 URL 写成 DOMAIN 值，是否只有 IP 而没有域名，或是否因为 no-resolve 没有进行预期地址判断。若命中了错误策略，优先查找更前面的宽规则。若命中了正确策略却连接失败，说明分类与执行至少需要分开分析，此时应继续检查被选连接对象，而不是不断把精确规则向上移动。

第三层：对照本地网络与已有服务器

Connectivity Test 可以帮助观察已有服务器的连通表现，但一次测试成功不代表所有目标、协议和实际业务都正常。测试失败同样不能单独说明 Rule 有问题，因为测试过程与某个业务请求的目标和处理路径可能不同。应把结果作为一条辅助证据，结合实际请求的阶段判断：是目标无法解析、远端无法建立连接，还是连接建立后业务返回异常，各阶段需要检查的字段不同。

当 Config 与 Proxy 表现不同，固定同一个已有连接对象再比较目标的解析与命中记录；当 Direct 也失败，检查本地网络是否能够正常访问该目标，尤其注意局域网主机和内部名称的环境限制。若只是速度下降而不是完全无法连接，应分开调查本地 Wi-Fi 或蜂窝网络、传输参数和实际路径，参阅连接速度的逐层排查，不要用不断扩大 PROXY 覆盖范围代替定位。

第四层：回退变量并复测代表性目标

每次只撤回一组最近改动，使用相同目标重新建立连接。如果删除一条宽规则后恢复正常，应进一步查明它覆盖了什么，而不是永久删掉所有同类规则。如果撤回 URL Rewrite 后跳转正常，应检查表达式和重定向循环，而非继续改服务器。若切回精简配置仍有同样问题，则复杂规则可能不是主要原因，应把调查重心移回网络、解析和已有连接参数。

[Rule]
# 临时验证单个目标的分类，不代表完整日常配置
DOMAIN,api.example.com,PROXY
FINAL,DIRECT

这类精简片段适合验证一个已知目标是否进入预期策略，但需要替换为用户实际测试的域名，并保留可恢复的原配置。验证后不要忘记切回日常文件，否则其他连接会遵循测试文件的 FINAL。临时配置也应明确命名和用途，防止数日后忘记当前正在使用哪份文件。测试成功后，再逐组恢复原规则并复测，直到能够指出造成差异的最小修改。

如果问题发生在购买、重新安装或已购恢复阶段，应先阅读已购恢复说明，这些步骤与 Rule 匹配无关。Shadowrocket 只通过 App Store 获取，以 iPhone 和 iPad 为主要使用设备；系统要求及兼容性以 App Store 页面标注为准。完成恢复后仍需核对用户自己的连接信息与配置，购买记录本身不能恢复所有业务环境。

最终结论应写成能够验证的事实，例如“该域名被前序后缀规则命中，移入精确例外后改为 PROXY”，而不是笼统写“配置修好了”。保留这种因果记录，下次遇到相似现象时就能快速判断是否同一问题。需要重新梳理完整操作主线时，返回快速上手教程；需要解释某一条规则时，则按本页目录回到对应章节，始终以实际输入、实际命中与实际执行结果为依据。