Shadowrocket
规则与配置参考

01 · 配置文件结构与编辑边界

打开 Config，先看当前被选中的配置，而不是只看列表里最近导入的文件。进入该文件的编辑入口，确认能看到配置段与现有规则，再开始修改。保存后返回列表，检查选中标记仍指向这份文件；若修改的是另一份副本，即使文本完全正确，当前连接也不会按副本处理。Config 管理的分流配置与 Home 中的服务器列表承担不同职责，不能把两者视为同一份数据。

配置段各自负责什么

Shadowrocket 的文本配置按方括号段名组织，段名占独立一行，后续内容属于这一段，直到遇到下一段。General 放基础行为参数，Rule 放按顺序检查的条件，Host 放指定主机名与地址的映射，URL Rewrite 放请求地址改写或重定向相关规则。不要因为某行看起来像域名，就把它放进 Host；先判断这行是在决定路径、指定解析结果，还是改变请求地址。

下面是阅读结构用的最小片段。它只展示基础参数与 Rule，不包含服务器定义，也不意味着可以替代你的完整配置。PROXY 是否有可用目标，仍要在 Home 中确认。示例中的域名仅供说明，实际验证时应换成你有权测试且清楚访问结果的目标；不要通过反复打开示例地址判断服务器是否正常。

[General]
dns-server = system

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

先保留原文件，再建立实验副本

编辑前导出或复制当前可用配置，并为副本设置能够辨认用途的名称。备份至少应能恢复原有 General、Rule 与自定义 Host 内容，另外单独确认服务器列表是否也已保存。导出内容可能含订阅地址或认证信息，不要把整个文件直接发到公开讨论区。需要求助时只保留相关规则、经过遮盖的目标信息以及实际错误现象。

一个字段是否被接受，要结合保存结果、应用内编辑器说明和请求记录判断。保留英文半角逗号、等号与段名；中文标点、不可见空格或从排版文档复制出的特殊引号，可能使一行内容无法按预期解析。若刚保存就出现错误，先撤回最后一次改动，再逐行恢复，不要同时改写多个配置段来碰运气。

订阅更新与配置更新分开理解

已有订阅通常用于更新服务器条目；远程配置则可能更新分流规则或基础参数，两者不应混为一谈。更新服务器后，Rule 未必改变；重新获取远程配置后，本地编辑也可能需要重新核对。先看更新入口所属位置、远程内容类型与保存目标，再决定是否操作。订阅地址从你的服务商处获取，本页不提供地址，也不判断任何服务商质量。

当应用内编辑视图与本文示例不完全一致时，以当前字段说明为准，先保持原有可用参数。系统要求以 App Store 页面标注为准；应用更新通过 App Store 完成，不需要通过更换整份配置来完成应用更新。配置负责网络行为，商店负责应用获取与更新，这两条维护路径应当分别检查。

02 · Global Routing 与匹配顺序

检查规则前，在 Home 打开 Global Routing，确认当前处于哪一种姿态。配置对应 Config，代理对应 Proxy，直连对应 Direct。需要按 Rule 分流时选 Config，再产生一次新的请求并查看记录。只在 Config 中编辑规则，却保持 Proxy 姿态，然后观察所有请求仍走代理，并不能证明 Rule 的语法有问题；路由姿态决定了这些规则是否参与当前判断。

首条命中不是“最长规则优先”

Rule 的基本阅读方法是从上往下检查，首条满足条件的规则决定本次策略。排在后面的规则，即使文字更具体，也不会自动推翻前面的命中。把精确域名规则放在宽泛后缀规则之前，是人为安排的优先级，不是程序替你排序。调整时要看整段上下文，不能只确认想用的规则“已经写在文件里”。

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

在这个片段中，api.example.com 先命中第一行，其他属于 example.com 的子域名才继续落到第二行。如果把前两行调换，api.example.com 会先满足后缀条件，精确域名那行便没有机会参与决策。检查这类问题时，记录目标主机名、首条命中条件与最终策略，再按顺序向上寻找覆盖范围更大的规则。

FINAL 处理剩余请求

FINAL 不需要再填写域名或地址参数，它负责处理此前尚未命中的请求，因此应放在 Rule 的末尾。它不是“失败后自动切换”的指令，也不会检测代理能否连接。FINAL,PROXY 的含义是把剩余请求交给 PROXY；若 PROXY 对应的服务器不可用，请求仍可能失败，不能依靠 FINAL 把故障路径自动修复。

不要在中间放一条 FINAL，再把例外规则写在它后面。中间的兜底会提前接收剩余请求，后续条目即使保存成功，也不能实现你预想的例外。同样，不建议保留多条互相矛盾的 FINAL 来表示备用方案。先明确剩余请求应走哪条路径，再用一条清晰的末尾规则表达这个决定。

记录中的地址不一定是最初访问的域名

一次页面访问可能产生主页面、图片、接口与资源文件等多个连接。只看到其中一条 IP 请求走了 PROXY，不能据此认定主域名规则失效。请在 Data 的请求或连接记录中找到与测试时刻、目标主机名相对应的条目，再检查匹配信息。若记录只提供目标 IP，还需要分辨请求是否携带域名信息，以及是否来自原有长连接。

保存规则后，原来已经建立的连接可能继续使用之前选择的路径。验证顺序是保存配置、确认选中、重新建立连接，再触发目标请求；必要时关闭相关应用后重新打开。不要只连续刷新同一页面，因为缓存可能让页面看起来已更新，却没有产生你要观察的新连接。测试结论必须对应一次可以识别的新请求。

03 · DOMAIN 系列规则写法

先从请求记录复制实际主机名，再选择匹配方式。域名规则的条件部分不填写完整 URL，不附带 https://、路径、查询参数或端口。例如目标是 https://api.example.com/status，DOMAIN 的条件应写 api.example.com，而不是整段地址。路径级区分属于另一类需求，不能通过把路径接到 DOMAIN 后面实现。

DOMAIN：只匹配指定主机名

DOMAIN 适合单独处理一个确定的主机名。DOMAIN,example.com,DIRECT 不会因为文字相同就自动包含 api.example.com，也不会包含名字里出现 example 的其他域名。需要为登录接口、更新入口或某个内部服务安排例外时，先确认它的实际主机名，再使用精确匹配。若服务使用多个主机名，需要逐项记录，而不是假定一次访问只对应一个地址。

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

这个片段明确写出两个主机名，再为其余后缀设置默认处理方式。login.example.com 的精确规则与后缀规则目前都指向 PROXY，看似重复，但在维护时可以表达它是一个被单独关注的入口；如果没有这样的维护需要，删除同策略冗余项会让配置更容易阅读。精简前仍应确认没有依赖顺序的其他例外。

DOMAIN-SUFFIX：按域名层级覆盖

DOMAIN-SUFFIX,example.com,PROXY 用于匹配 example.com 及其子域名。它按域名边界判断，不是任意文本包含关系：api.example.com 属于该范围，notexample.com 不属于。条件通常直接写 example.com，不要自行加入星号或把它当正则表达式。需要更窄范围时，可以填写 api.example.com 作为后缀，再明确是否希望涵盖其下一级主机名。

后缀规则便于覆盖一个服务域下的多个入口，但一个页面的资源不一定都在同一域下。若登录正常而图片失败，应检查图片请求的真实域名，而不是不断扩大主域规则。把所有观察到的域名简单合并为一个过宽关键字，可能影响本来无关的请求。先收集失败条目，再决定是增加精确规则还是增加另一个明确后缀。

DOMAIN-KEYWORD：范围通常比预想更大

DOMAIN-KEYWORD 针对域名文本进行关键字匹配，不要求关键字恰好占一个完整域名标签。DOMAIN-KEYWORD,example,PROXY 可能同时命中多个彼此无关但含有这段文本的域名。它适合你明确需要这种宽范围的情况，不适合代替所有 DOMAIN-SUFFIX。排错时优先把宽关键字缩小成实际观察到的主机名，能够减少误匹配带来的干扰。

规则条件不要含中文注释、尾部多余逗号或从浏览器复制来的句末标点。规则中的策略写在最后一个规定位置，说明文字另起一行记录，避免把注释误当字段。若配置编辑器支持单独填写类型、条件和策略，逐栏录入通常比直接粘贴长行更容易发现错误；保存后仍应回到文本视图检查结果。

把匹配范围和策略变化分开验证

测试一条域名规则时，先保持策略不变，只确认目标是否命中这条规则；确认条件准确后，再改变 PROXY 或 DIRECT。这样可以区分“没有匹配到”和“匹配到了但路径失败”。如果同时换条件、换服务器和换 DNS，成功或失败都无法说明究竟哪项修改起了作用，也会使后续回退失去明确依据。

04 · IP、GEOIP 与 USER-AGENT

域名条件无法覆盖所有请求。有些应用直接连接 IP 地址，有些连接记录没有可供规则使用的主机名，这时才需要结合 IP-CIDR、IP-CIDR6 或 GEOIP 判断。先确认实际目标地址和地址族，再选择条件。不要仅凭浏览器地址栏中的文字推断底层连接一定带域名，也不要把一条地址规则理解为对整个网站永久有效的身份识别。

IP-CIDR：地址与前缀长度

IP-CIDR 的条件由网络地址和斜杠后的前缀长度组成。192.168.0.0/16 表示一个地址范围，192.168.1.20/32 则只覆盖一个 IPv4 地址。前缀数字越大，范围通常越小。规则覆盖的是连接目标地址，不是当前 iPhone 的本机地址；要让某台内部设备直连，应填写那台设备所在的目标范围，而不是随意复制设备自己的地址。

[Rule]
IP-CIDR,192.168.1.20/32,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
IP-CIDR6,fd00::/8,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

示例先写单个内部地址，再写较大的私有范围，便于以后增加例外。实际环境可能使用其他内部网段，应以网络设置与管理员提供的信息为准。把私有地址交给 DIRECT 只是在路由层选择直连，不会自动赋予访问权限；设备仍要处于能够到达该网段的网络中，目标服务也需要监听对应端口并允许访问。

IP-CIDR6 与 IPv6 排查

IP-CIDR6 用于 IPv6 地址范围。示例中的 fd00::/8 仅说明一种本地地址范围的写法，不代表所有 IPv6 地址都应该直连。若同一主机名同时返回两类地址，只为 IPv4 写规则可能无法涵盖实际使用的 IPv6 连接。先从记录确认连接选用了哪一类地址，再决定是否补充规则，不要把关闭整个地址族当作常规修复步骤。

一些 IP 类规则允许使用 no-resolve 参数，以避免仅为检查该规则而主动解析域名。其目的在于限制匹配过程触发的解析，不是取消请求所需的所有 DNS 行为。若请求还只有域名、没有可用目标 IP，这类规则可能不会按你预期命中。使用前应确认当前编辑器支持该参数，并把带参数与不带参数的效果分别验证。

IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

GEOIP 依据地址数据库，不依据语言

GEOIP,CN,DIRECT 表示根据目标 IP 的地理归属分类选择 DIRECT，不是根据页面语言、域名后缀或用户位置分类。域名可能使用分布式地址，数据库也可能存在归属差异，因此不能据此推断服务运营地或保证连接速度。对少量明确服务的例外，使用已验证的 DOMAIN 规则放在前面，通常比扩大整类 GEOIP 条件更容易维护。

当域名规则与 GEOIP 同时存在时，顺序仍然重要。前面的域名条件已经命中，后面的地址归属不会自动重新选择策略。若日志显示请求落到了 GEOIP，先确认前面的域名条件是否覆盖实际主机名，再检查当前连接是否保留了域名信息。只更新地址数据库而不核对请求对象，可能并不能解决问题。

USER-AGENT 不能替代应用识别

USER-AGENT 根据能够获取的请求头字段匹配，例如 USER-AGENT,ExampleClient*,PROXY 展示了带通配模式的条件写法。它不是按应用名称分流，也不保证对所有连接可见。很多加密请求中的头字段不能直接取得，不应为了这类规则盲目启用解密。若记录没有可匹配字段，优先寻找明确域名条件，并保留 FINAL 作为余下请求的处理方式。

05 · PROXY、DIRECT、REJECT 与协议参数

规则前半部分回答“什么请求”，末尾策略回答“如何处理”。PROXY、DIRECT、REJECT 是三种常用策略关键字，大小写与拼写应保持一致。不要把策略名与服务器协议混写：Shadowsocks、VMess 或 Hysteria2 说明服务器连接采用什么协议，并不是 Rule 中直接代替 PROXY 的通用动作。先确认条件命中，再沿策略指向检查实际连接目标。

PROXY 与 DIRECT 的边界

PROXY 通常把请求交给当前代理选择；具体目标还要结合 Home 的选择以及配置中是否存在策略组判断。DIRECT 则使用直连路径，但不等于绕过网络环境、系统权限或解析过程。一个目标能直连，不能证明代理参数正确；代理能连接，也不能证明所有内部地址都适合交给它。应当根据服务所在位置与自己的使用目的作出选择。

若当前配置包含命名策略组，规则末尾也可能引用组名，这时要检查组是否真实存在、名称是否完全一致，以及组内是否有可用成员。不要把别的文件里的组名粘贴过来后就假定它会自动生成。本文片段统一采用基础策略，便于独立阅读；你的完整配置如果使用组，应在保留其结构的前提下安排例外规则。

REJECT 表示主动拒绝

REJECT 用于明确拒绝命中的请求，不是“测试失败后改走别的服务器”。只有确定目标应被阻止时才使用。若在登录依赖域名上误写 REJECT，应用可能表现为一直等待、按钮无响应或部分资源缺失，而不一定显示清晰的拒绝说明。排查时找到被拒绝的条目，确认条件是否过宽，再决定删除或缩小范围。

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

这组规则用三个不同主机范围演示动作，不是建议把真实登录域名加入拒绝列表。blocked.example.com 先被拒绝，internal.example.com 被安排直连，其余 example.com 子域名交给代理。只要顺序改变，结果也可能改变。给每个例外保留简短维护说明，记录为什么需要它，比积累大量无法解释的拒绝规则更有利于长期使用。

多协议只核对自己已有的参数

服务器导入后，先核对协议类型，再核对地址、端口与认证字段。Shadowsocks 的加密方法与密码，VMess、VLESS 的身份字段，以及 Trojan 的密码和 TLS 设置，各自含义不同，不能根据字段位置相似就互相替换。来自你自己服务商的完整参数优先于网上零散示例；缺失参数应向信息提供方确认，不要猜测。

TLS 相关失败应检查服务器名称、证书条件和系统时间，不应把跳过证书验证当作默认排错手段。Hysteria2 使用场景还需要关注 UDP 的实际可达性；某次测试显示响应，并不代表所有传输方式都正常。不同协议的成功条件应分别验证，不能用一个服务器的结果推断另一条服务器配置已经正确。

当 PROXY 请求失败而 DIRECT 成功时，记录所选服务器、协议类型和失败阶段，再回到 Home 检查对应条目。若所有目标都无法通过同一服务器访问，应优先排查服务器与网络，而不是为每个网站添加规则。若只有一个目标失败，再检查该目标是否涉及额外域名、特殊端口或服务端访问限制。

06 · General、DNS 与 Host 映射

DNS 负责把主机名解析为可连接的地址，Rule 决定请求的处理策略，两者相互关联但不是同一功能。页面打不开时，先区分是否取得地址，再看连接到了哪里，最后看采用什么策略。只改 DNS 无法修复密码错误，只改 PROXY 也无法保证一个不存在的域名获得解析结果。把故障分阶段记录，能避免在无关字段上反复试验。

dns-server 与系统解析环境

General 中的 dns-server = system 表示使用系统提供的解析设置，是理解字段职责的基础示例，不是对所有网络的统一推荐。系统解析环境会随 Wi-Fi、蜂窝网络及网络管理设置变化。你应先记录当前网络和已有 DNS 设置，再修改配置中的解析选项；这样在切换网络后出现差异时，才有可以对照的原始条件。

[General]
dns-server = system

[Host]
lab.example.com = 192.168.1.20

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

这份片段把 lab.example.com 指向内部设备，并安排该域名直连。它只适用于你确实控制该名称和设备的测试环境。Host 解决的是地址映射，DOMAIN 解决的是策略选择；少了后者，请求仍可能按其他 Rule 走代理。反过来，仅写 DIRECT 而没有正确解析，主机名也未必指向那台设备。

Host 不改变证书与服务身份

把一个主机名映射到指定 IP 后，访问时使用的名称通常仍是原主机名。HTTPS 服务需要提供与该名称匹配的证书，服务端也可能按主机名选择站点。不要因为 IP 地址能打开某个页面，就认定给它添加任意 Host 都能正常访问。地址可达、证书匹配、站点配置是三个不同条件，需要分别满足。

Host 不适合长期固定使用动态地址的公共服务。服务更换入口后，旧映射可能继续把请求送往已经失效的目标，造成“其他设备正常，只有当前设备失败”的现象。排查时检查是否存在遗留映射，临时移除后建立新连接再比较。如果映射用于内部设备，也应确认设备地址是否因网络重新分配而变化。

区分 DNS 缓存与连接复用

修改映射后，旧解析记录或旧连接可能继续影响观察结果。先保存文件，确认配置选中，再重新连接并产生新的请求；有需要时按应用提供的入口清理相关缓存。不要把“页面还显示旧内容”直接解释为 Host 没有生效，因为页面缓存、服务端缓存和连接复用都可能保留旧结果。优先以新记录中的目标地址作为依据。

当记录中看不到域名对应的地址时，先在当前网络验证名称本身能否解析，再检查是否有拼写错误、内部解析依赖或应用自己的解析机制。部分应用的请求方式可能使常规域名观察不完整，不能据此得出所有 DNS 都已绕过配置的结论。缩小到一个可重复的测试目标，比同时测试多个页面更容易确定边界。

General 参数逐项核对

General 还可能出现与系统流量处理、例外范围或地址族有关的参数。它们不应被当成“优化开关”整组粘贴。以现有文件为基线，先查字段含义，再确认它与 Rule 的关系；某个参数影响的是接管范围时，单靠追加 Rule 未必能覆盖其效果。每次只改一项，保留修改前的值和对应现象，确认后再处理下一项。

使用加密 DNS 等解析方式时，也要考虑解析请求本身怎样到达目标，以及是否形成连接依赖。若代理服务器地址还需要解析，而解析器又只能依靠这条代理访问，可能出现启动阶段的相互等待。遇到这种情况先恢复已知可用的基础设置，再按顺序建立解析与连接，不要通过堆叠更多解析地址掩盖根本依赖。

07 · URL Rewrite 的用途与限制

先明确你要改变的是访问路径还是请求地址。把 example.com 交给 PROXY 属于 Rule；把某个旧入口转到另一个 URL，才可能涉及 URL Rewrite。两者不是互相替代的配置段，也不存在把 URL Rewrite 放在 Rule 前面就能获得更高分流优先级的关系。它们处理不同问题，验证时应分别观察路由结果和地址变化。

从一个可控 HTTP 入口开始

URL Rewrite 通常由匹配表达式、目标地址和处理动作组成。下面使用一个 HTTP 到 HTTPS 的重定向片段解释结构；测试前应确认你控制对应目标，并以当前编辑器支持的动作与语法为准。表达式中的反斜杠用于把点号视为普通点，括号捕获路径部分，目标中的 $1 引用第一个捕获组。

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

这行从 URL 开头匹配 http://example.com/，将后续部分带入目标地址，使用 302 表示临时重定向。它不会让目标服务器自动支持 HTTPS，也不会修复目标证书。如果目标地址本身不能访问，重定向只会把请求带到另一个失败位置。应先直接验证目标 URL，再测试源 URL 是否转向它。

正则表达式必须限制边界

正则表达式中的点号默认可以匹配其他字符，省略转义可能扩大范围；开头锚点能避免在任意位置误匹配。条件只写一个很短的关键词，通常难以说明你到底允许哪些 URL 被处理。优先从完整协议、明确主机名和必要路径开始，确认效果后再考虑扩展，而不是先写一个宽条件再逐个排除误命中。

URL 可能带查询参数、编码字符与不同路径形式。示例里的捕获组会保留斜杠之后的内容，但这不代表所有复杂地址都适合简单拼接。登录回调、带签名的请求或依赖精确参数顺序的接口，改变任何部分都可能导致验证失败。涉及这类目标时，先确认协议约定，不要把能打开普通页面的表达式直接用到认证流程。

避免重定向循环与请求语义改变

新增规则后，检查目标地址是否会再次满足同一条规则，或被另一条规则改回原地址。出现页面反复跳转、地址不断切换或请求数持续增加时，应先停用新增规则并保留记录。多个入口之间的双向改写很容易形成循环；维护时把源条件、目标地址与预期终点写清楚，避免只按单行文字判断是否正确。

重定向还可能影响请求方法、请求体或认证头的处理方式，具体表现取决于动作和发起请求的应用。不要把浏览器中一次成功的 GET 测试，等同于接口的 POST 请求也会保持相同行为。对提交表单、支付或身份认证等请求，除非明确理解服务协议，否则应保留原有请求，不在通用规则里批量改写。

HTTPS 可见性与证书边界

常规加密连接不会把完整 URL 路径直接暴露给普通路由判断。需要读取 HTTPS 内容的功能涉及额外的解密与信任条件，不能因为写了 URL Rewrite 就假定这些条件已经满足。本页示例从明文 HTTP 入口开始，不要求为验证规则而添加信任证书。只需要域名分流时，保持使用 Rule 即可。

不要把证书信任步骤当成修复所有改写失败的通用方法。先判断测试请求是否真正可见、表达式是否匹配、动作是否支持，以及目标是否可达，再决定该功能是否适合当前需求。不同应用也可能主动校验证书或固定访问逻辑，出现失败时应停止扩大改写范围，而不是不断降低验证条件。

验证完成后，保留最少数量的必要规则，并记录每条规则的业务目的与测试入口。网站自身可能已经实施重定向，重复添加本地改写只会增加维护层次。若删除规则后访问结果完全相同，应检查是否由服务端或浏览器缓存完成跳转。确认功能归属后再决定是否保留，能减少后续配置迁移时的隐性依赖。

08 · 配置验证、On Demand 与维护流程

验证前先写出一句能够检验的目标，例如“api.example.com 的新请求应命中 DOMAIN 并走 DIRECT”。然后记录当前网络、Global Routing、选中配置和服务器，再进行一次访问。成功标准不是开关颜色改变，而是请求命中与预期一致，并且目标服务返回合理结果。路由判断正确但服务器失败，与规则没有命中，需要沿不同方向处理。

按失败阶段检查，不连续叠加修改

第一步看系统网络能否正常使用，第二步确认连接开关与 VPN 配置授权，第三步检查服务器，第四步观察规则。若添加 VPN 配置的授权曾被拒绝或相关配置被删除，应回到首次连接流程重新处理，不必先改 Rule。系统提示的含义见添加 VPN 配置与系统权限说明。

Connectivity Test 可用于辅助观察服务器响应，但不能替代真实业务请求。测试失败时核对地址、端口、协议与当前网络；测试有响应而网页失败时，再检查 DNS、TLS、规则与具体目标。不同测试方式所验证的层次可能不同，不宜把单次显示结果当成整条访问路径的保证。可结合连接超时排查顺序继续检查。

On Demand 控制触发，不改变规则语义

在 Settings 中检查 On Demand 的实际条件，区分“何时建立连接”和“连接后怎样分流”。On Demand 用于按所设条件触发连接，不能修复错误密码，也不会把 Rule 重新排序。调试规则时可以先使用手动连接建立稳定基线；确认分流正常后，再启用实际需要的按需条件，减少自动重连对实验结果的干扰。

当手动断开后又出现连接，先检查 On Demand 与系统触发条件，不要立即认为配置文件没有保存。若关注后台耗电，应比较相近网络、相近使用时长与相同服务器下的表现，不能只凭一次电量变化判断某个开关有问题。有关常驻与按需使用的取舍，可查阅On Demand 与后台耗电说明。

建立一份可以回退的验证记录

每次修改记录四项内容：原始规则、修改后的规则、测试目标、实际命中。若结果不符合预期，立即恢复本次改动，再决定下一步。不要在失败状态上连续添加更多例外，否则最后即使恢复连接，也很难解释是哪一行生效。与其保留大量重叠条件，不如用少量能够说明目的的规则逐步覆盖需求。

分享排查记录时遮盖订阅链接、密码、身份字段、密钥与不应公开的内部地址。通常只需要提供相关 Rule 片段、经过处理的目标名称、命中策略和错误阶段，不需要整份配置。分享截图也应检查是否暴露认证信息；本页不要求上传文件或提供完整订阅，保留最小必要信息即可说明问题。

更新后的例行检查

应用通过 App Store 更新后，先确认当前配置仍被选中，再检查你依赖的几条关键规则。订阅更新后确认服务器选择仍有效，远程配置更新后确认本地例外仍在预期位置。换机或重新安装时，应用恢复与配置恢复分别进行；购买记录不会自动代表所有自定义数据已经恢复，具体步骤见已购恢复说明。

需要继续查阅时，用本页目录返回对应配置段；需要从添加服务器重新走完整流程时，转到Shadowrocket 使用教程。涉及购买、导入失败或系统权限的独立问题，可在FAQ按类别查找。维护目标是让每条规则都有明确范围、每次修改都能回退、每个结论都对应可复现的新请求，而不是让配置文件不断变长。