Shadowrocket 完整使用手册

先认识 Home 与配置之间的关系

首次打开后，先区分三个对象：Home 中可选的服务器、Config 中使用的规则配置，以及建立系统连接的总开关。服务器决定请求交给哪个远端处理；规则配置决定哪些请求采用何种策略；总开关决定本次网络扩展是否运行。三者相互关联，但不能互相替代。列表中有服务器，不代表规则已经合适；规则文件存在，也不代表服务器凭据正确；开关开启后，仍需要通过实际访问确认结果。

初次启动时，应用可能在相关功能首次使用时才请求权限，而非一次展示所有提示。阅读当前弹窗所说明的用途，再决定是否继续。相机权限通常与扫描二维码相关；通知权限涉及应用通知；系统 VPN 配置授权则用于建立连接。只导入文本链接时，不必为了完成同一任务主动打开相机权限。对于未使用的功能，可以等真正需要时再按系统流程授予权限。

理解系统 VPN 配置授权

在第一次尝试开启连接时，系统通常会要求允许添加 VPN 配置，并可能要求设备身份验证。这是系统登记网络扩展配置的步骤。先确认请求来自正在操作的 Shadowrocket，再按系统提示处理。授权成功只说明系统允许该配置运行，不意味着网络中的每个请求都一定转发，也不意味着已连接的服务器能够访问所有目标；具体处理仍取决于 Global Routing、规则与远端服务。

若此前取消了系统提示，可以在确认服务器信息后再次尝试开启连接，按实际出现的授权流程继续。若始终无法建立配置，先检查设备是否由组织管理、是否存在限制相关功能的策略，以及是否有其他网络配置正在生效。组织管理设备应遵循管理要求，不能把管理限制当作普通连接故障。不要连续删除多项系统配置试错；先记录现有配置所属应用与用途，避免影响原有工作网络。

把系统状态与应用状态分开判断

系统中显示 VPN 状态，说明相应网络扩展处于连接状态，但不能证明目标网页已成功加载。反过来，某些设备的状态栏位置有限，未持续显示某个标识也不能单独证明连接已经断开。判断时同时查看应用中的开关状态、当前选中服务器和实际访问结果。若从系统设置发起断开后又自动连接，应检查 On Demand 等触发条件，而不是将开关恢复认定为系统未接受操作。

更改服务器、路由姿态或规则配置之后，已有连接可能仍保持先前的路径。第一次验证建议先停止当前访问，再按需要重新建立连接，随后重新打开目标页面。不要一边保留旧会话，一边修改多项设置，然后仅凭页面是否还在播放来判断新配置。对于需要登录的应用，还应考虑应用自身缓存和会话恢复带来的影响，必要时退出目标应用后重新访问。

权限检查只回答“系统是否允许该功能运行”。连通性检查还要回答“当前服务器、认证参数、规则和目标服务是否正常”。两个检查点应分别记录。

建立第一次操作的可回退基线

在导入前，记下当前使用的是 Wi-Fi 还是蜂窝网络，并确认普通网络本身能够正常使用。需要先通过网页认证的 Wi-Fi，应先完成认证再进行连接测试。初次配置期间暂不启用自动触发规则，便于明确知道每次连接由哪次手动操作产生。如果设备已有其他会改变网络路径的功能，也应记录其状态，避免把多个机制同时生效后的现象归因于单一设置。

建议准备一份仅自己保存的操作记录，写清当前服务器名称、配置名称、Global Routing 姿态和本次修改事项，不记录完整密码或订阅凭据。第一次成功后，这份记录就是回退基线。若尚未导入任何服务，停留在本阶段是正常状态；请继续下一章添加用户已有信息。希望跟随较短步骤操作，可返回入门指南，完成授权后再回到本页查阅各项边界。

区分路由姿态与规则策略

Global Routing 决定请求按什么方式处理。Config 使用当前配置中的规则进行匹配；Proxy 让进入客户端处理范围的请求采用代理路径；Direct 则采用直连路径。它们是工作姿态，不是三个不同的服务器。切换姿态不会修复错误密码，也不会延长已有服务的有效期。尤其是 Proxy，不应简单理解为设备上的所有通信都必然经过远端，系统网络行为、处理范围与协议能力仍存在各自边界。

规则中的 PROXY、DIRECT 与 REJECT 是策略关键字，不能与 Global Routing 的界面文字混为一谈。规则里的 PROXY 还需要结合当前选择以及配置中的策略定义理解。若配置使用了自定义策略组，规则末尾可能引用组名，而不是固定写成 PROXY。首次学习时先看清现有配置的引用关系，不要只更换规则尾部文字就认为完成了策略调整。

从上到下匹配，FINAL 放在末尾

在 Config 下，规则按从上到下的顺序检查，命中后采用相应策略。越具体的例外通常越需要放在相关宽泛规则之前；否则前面已经命中，后面的例外便不会得到执行机会。FINAL 用于处理前面没有匹配的请求，应放在末尾。排查顺序问题时，应从规则顶部检查，而不是只搜索自己新添加的一行，因为真正生效的可能是更靠前的另一条规则。

下面是 .conf 中的规则片段示例，仅说明结构和匹配顺序，不是完整配置，也不代表适用于所有网络。example.com 为教学域名；使用前应根据自己的目标和现有策略定义调整。保留原配置备份后再编辑，并确认当前选中的确是修改后的配置文件。

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

DOMAIN 对应精确域名；DOMAIN-SUFFIX 对应指定域名及其子域；DOMAIN-KEYWORD 按域名中的关键字匹配，范围可能比预期更大。IP-CIDR 与 IP-CIDR6 用于地址网段，GEOIP 根据地址所属地区数据库判断。域名请求与实际连接地址之间还存在解析步骤，因此域名规则命中和地址规则命中所依赖的信息不同，不能仅凭最终显示的某个地址反推整条匹配过程。

用单个目标验证修改，不同时改整份配置

修改规则时，先明确预期：哪个目标应采用什么策略，原先为何不符合要求。添加一条针对该目标的规则后，重新发起请求并观察可用记录中的策略结果。若行为不变，先确认配置是否已保存、是否被选用、是否有更早的规则命中，以及旧会话是否仍在持续。不要一次修改 DNS、服务器和大量规则，否则即使恢复正常，也难以知道是哪一项产生作用。

将目标切到 DIRECT 并不意味着目标一定可以访问，它仍依赖本地网络的解析和连通性；切到 PROXY 也不意味着远端一定能访问该目标。REJECT 是主动拒绝请求，可能影响页面资源、登录流程或应用通知，使用前应理解目标用途。规则应围绕明确需求编写，不以条目数量衡量质量。更详细的顺序案例见自定义规则优先级与 FINAL 说明。

推荐顺序：先保留已验证服务器，再用 Proxy 检查代理路径，最后回到 Config 验证分流。临时姿态完成对照后，应恢复原本的日常配置。

如果 Proxy 能访问而 Config 失败，优先检查规则、策略引用与配置相关的 DNS 行为；如果两者都失败，则应回到服务器认证、传输与网络可达性检查。这样的分组判断比反复切换姿态更有价值。记录最终使用的配置名称和 Global Routing 姿态，下一章的连接验证才有可重复的前提。

本机统计不等于服务侧剩余额度

Data 用于观察客户端可见范围内的流量与相关记录，具体项目以当前应用显示为准。先看清统计是当前连接、某段时间还是累计数据，再判断数值变化。客户端记录的流量不应直接等同于服务侧扣除额度：两端可能采用不同时间窗口、计算单位、协议开销或计费方式。需要确认已有服务剩余额度时，应查看自己的服务账户信息，而不是用客户端累计数字自行推算。

上传与下载的方向以设备视角理解。页面请求、文件发送、云端同步都可能产生上传；页面内容、视频与文件接收则会产生下载。即使没有主动打开网页，后台同步与应用通知仍可能产生网络活动。因此看到少量流量持续变化，不足以单独判断存在异常；应结合当前前台任务、后台活动与记录范围分析，尤其不要在未检查单位时把速率与累计量混为一谈。

先分清速率、累计量与时间窗口

速率描述单位时间内的数据变化，累计量描述某个统计窗口内的总量。短时峰值不能证明长时间吞吐能力，累计量增大也不能说明当前仍在持续传输。查看时先确认单位以及是否存在字节与比特的差异，再进行比较。不同界面可能对单位采用不同显示方式，记录问题时最好写出屏幕上的完整单位，而不只写一个没有上下文的数字。

重连、清理记录或重置统计可能改变可见范围，操作前应先阅读当前选项的作用。不要为了让数字归零而删除服务器或订阅，两者不是同一个管理对象。若准备比较两次访问的流量，应选用相同目标与相近操作，记录开始和结束时的统计差值，并考虑浏览器缓存是否已经命中。第二次打开页面更省流量，可能来自缓存，不代表网络路径发生变化。

从请求记录核对规则是否按预期生效

当应用提供相关连接记录时，可结合目标域名或地址、命中规则、所用策略与结果判断请求路径。首先明确自己刚刚发起了哪个请求，再寻找对应记录；列表中同时可能包含后台任务与其他应用的通信。域名与地址并不是必然一一对应，某些连接直接使用地址，某些请求还依赖先前缓存的解析结果。没有看到预期域名，不应立即认定目标完全没有发起网络请求。

记录中的策略信息尤其适合验证 Config。先检查命中的是具体域名规则、地址规则还是 FINAL，再看其引用的策略是否符合预期。如果出现 DIRECT，不要只修改服务器，因为请求可能根本没有使用该服务器；如果出现 REJECT，应先检查是否被主动拒绝。若记录与预期不符，回到第四章按从上到下的顺序检查规则，并确认当前选中配置与正在编辑的文件一致。

数据数字回答“观察到了多少”，请求记录帮助回答“这次请求如何处理”。两者结合使用，但都不能替代目标服务返回结果的实际验证。

流量异常时先做差分观察

发现流量明显增加时，先停止正在进行的大型任务，例如视频播放、系统更新或云端同步，再观察变化是否减缓。随后逐个恢复任务，找出与增长相关的活动。不要只凭服务器名称判断来源，也不要将统计增长直接解释为凭据泄露。若停止前台任务后仍持续增加，应结合后台应用活动和可用记录继续缩小范围，并确认统计窗口是否仍包含刚才的历史数据。

如果服务侧额度减少而本机 Data 变化较小，应考虑是否有其他自己的设备正在使用同一服务、两端统计周期是否一致，以及服务侧是否采用不同计算口径。先核对这些事实，再联系已有服务的支持渠道询问计量规则。客户端通常无法解释服务侧所有扣量细节，因此不宜通过反复重置本地统计来解决账户额度问题；重置只改变本机显示，不改变服务侧记录。

分享诊断信息前做最小化处理

请求记录可能包含访问域名、路径、设备网络信息与个人标识。对外说明故障前，先筛选与本次问题有关的内容，遮盖完整订阅地址、密码和可识别个人的参数。截图也应检查背景中是否显示敏感条目。处理完毕后，按应用现有功能管理不再需要的记录；保留时间应以自己的排查需要为准，不必长期积累全部历史。日常维护只需保留可复现条件、关键错误与有效处理结论。

这一阶段的目标不是持续盯着数字，而是掌握判断依据：知道统计覆盖什么范围，能够找到一次失败请求，并能区分本机观察与服务侧账户信息。掌握这些后，再调整 Settings 中与实际问题有关的选项，能够减少没有依据的尝试。

把应用更新与订阅更新分开管理

应用更新通过 App Store 完成，主要改变客户端自身；订阅更新则重新获取用户已有服务的服务器列表，两者不是同一操作。订阅更新成功不代表应用已经更新，应用更新也不会自动保证服务信息仍有效。日常应分别关注商店中的应用状态与自己的订阅状态，不需要追逐未经核实的版本描述。更新前若正在处理故障，先记录当前可复现条件，避免更新后失去对照。

订阅刷新频率应遵循已有服务的说明与自己的实际需要，不必因一次请求缓慢连续重复刷新。刷新后先检查当前所选条目是否仍存在、名称是否变化，以及规则中的策略引用是否受到影响。若列表更新失败而原条目仍可用，应优先保留工作状态再排查获取过程。将正常使用和维护尝试分开，能避免在需要连接时因一次清理操作失去所有可用信息。

备份应覆盖信息，而不只是应用本身

应用购买记录、服务器资料、订阅链接与规则配置应分别理解。能够重新从 App Store 获取应用，不代表能够自动恢复全部本地内容；设备备份能恢复多少，也应按实际恢复结果确认。迁移前先检查应用提供的导出或备份功能，并确认导出范围是否包含需要的配置。对于手动填写的条目，保留原始资料尤其重要，否则只有一个显示名称并不足以重新建立连接。

备份可能包含密码、订阅凭据或其他访问参数，应存放在自己控制的受保护位置。不要把完整配置放进公开笔记、公开文件夹或故障讨论中。建议为备份写上用途和配置名称，并保留一份已验证可用的版本；进行大范围规则调整前，先导出原有内容。备份是否有效最终取决于能否读出并恢复必要信息，而不是文件是否存在，所以应在合适时机检查其内容范围。

换机后按依赖顺序恢复

先在新设备的 App Store 中确认原购买记录与产品身份，再按商店条件获取应用；系统要求、通用购买和家庭共享适用性均以 App Store 页面标注为准。接着恢复自己的服务器或订阅信息，再恢复规则配置，最后重新检查系统 VPN 配置授权。新设备仍可能需要独立完成权限提示，不能因旧设备已经授权就略过这一环节。购买恢复的具体检查见已购恢复说明。

恢复后不要立即启用全部自动触发与高级选项。先手动选中一个已知条目，验证连接与常用目标；确认 Config 下分流正常后，再恢复 On Demand。设备名称、Wi-Fi 环境、系统设置和应用权限都可能与旧设备不同，因此完全相同的配置不一定呈现完全相同的触发条件。若迁移过程中遇到问题，回到最近一个已经验证的阶段，而不是直接重做全部流程。

建立固定的故障恢复顺序

日常异常可按四步处理：确认基础网络，确认当前选择，检查最近改动，恢复已知基线。第一步排除 Wi-Fi 认证和网络不可用；第二步核对服务器、配置与 Global Routing；第三步查看是否刚更新订阅、修改规则或启用自动触发；第四步只回退相关变化。这样既保留证据，也能减少无关操作。只有明确知道某项内容已损坏且具备恢复资料时，才考虑删除重建。

若问题仅出现在一个网络，保持配置不变，换到另一个自己的可用网络进行对照；若仅一个服务器异常，保留其他条目并核对该条目参数；若仅一个目标失败，则检查请求记录与相关规则。遇到服务资格或额度问题，应通过已有服务的支持渠道处理；遇到购买记录问题，应从 App Store 账户记录检查。把问题交给对应环节，避免用应用设置处理账户侧事项。

回退基线至少包含：可用服务器的来源、配置名称、Global Routing 姿态、必要设置及最后一次有效验证的操作。凭据单独保护，不写进公开排查记录。

用简短记录代替反复试错

每次维护只需留下几项结论：修改了什么、为什么修改、采用了哪次对照、是否有效、如何恢复。不要把没有验证的猜测记成固定规则，也不要因为一次短暂成功就删除原有备份。周期性清理重复条目和无用记录时，先确认当前依赖关系，尤其注意订阅生成条目与手动条目的区别。清理的目标是减少混淆，而不是让列表看起来越短越好。

至此，完整使用链应当清楚：App Store 确认产品与购买，系统授权允许连接，已有信息提供服务器，Global Routing 决定处理方式，实际访问证明结果，Data 与记录提供证据，Settings 解决具体需求，维护流程保障可恢复。需要重新走一次简短操作时，使用入门指南；需要核对某项原理时，从本页目录回到对应章节，无需重复重建已经正常工作的部分。