Shadowrocket 完整使用手册

02 / FIRST LAUNCH

首次启动：理解 VPN 配置与连接权限

先认识界面，再处理系统授权

结论是先准备有效服务器信息，再在发起连接时处理系统授权。Home 用于查看服务器和连接入口，Config 管理规则配置，Data 用于查看流量相关信息，Settings 集中常用设置。不同设备的布局可能有差异，应按项目名称查找，不必照着固定按钮坐标操作。首次打开时列表为空，只表示尚未添加可用连接资料。

第一次启用连接时，系统可能要求允许添加 VPN 配置，并要求使用设备密码或设备提供的认证方式确认。这是系统允许应用建立网络扩展连接的授权步骤，不是订阅登录页面，也不是服务商密码输入框。应确认弹窗由当前操作触发、应用名称正确，再决定是否允许；如果取消，可以先返回应用检查服务器信息。

允许添加 VPN 配置只解决设备端连接权限，不会验证远端服务器是否可用。授权成功后仍可能因为地址、端口、认证信息或网络条件不符而连接失败。不要把系统授权完成当作连接已经打通；后面还要分别验证服务器连接、域名解析和目标访问，三个结果不能互相替代。

权限不足时如何定位

如果此前拒绝授权，下一次连接时应先观察是否重新出现系统提示。没有提示而且连接立即失败时，可在系统设置中查找 VPN 配置，核对 Shadowrocket 对应项目是否存在，以及设备是否有组织管理限制。系统设置入口名称随系统界面变化，以设备实际显示为准；不要为了找到固定路径而连续更改无关权限。

设备已有其他 VPN 配置时，先确认当前真正处于连接状态的是哪一项。测试 Shadowrocket 前，应结束其他正在使用的 VPN 连接，避免把系统连接切换误判为服务器故障。保留配置与保持连接不是一回事，通常不需要为了测试删除所有配置；先断开、复核，再进行一次明确的连接尝试，便于判断是哪一步失败。

相机权限只与扫码操作相关。若通过 Scan QR Code 导入已有服务器信息，需要按系统提示允许相机访问；若不使用扫码，可以采用应用提供的其他导入方式。拒绝相机权限不等于拒绝 VPN 权限，也不应解释为服务器不能连接。对每一种权限都应先问清当前功能是否需要，再决定是否授予。

首次连接前保留可回退状态

正式配置前，先确认设备原本能正常访问需要测试的普通页面。记录当前使用的是 Wi-Fi 还是蜂窝网络，以及是否处于需要网页认证的网络中。需要网页认证时先完成认证，再连接 Shadowrocket；否则应用即使已取得权限，也可能因为基础网络尚未放行而失败，反复修改协议参数只会掩盖真正原因。

初次使用建议先手动连接，暂不启用复杂的 On Demand 条件。先建立“选择服务器、选择路由模式、开启连接、访问目标、关闭连接”的完整流程，确认每个阶段的现象。自动连接依赖基础配置正确，提前启用容易造成手动关闭后又重新连接，让用户难以判断是权限问题、条件触发还是服务器连接不稳定。

配置检查或故障记录需要截图时，先遮盖密码、订阅链接、认证标识和可恢复敏感信息的二维码。系统弹窗与应用设置可以用于记录操作阶段，但分享前仍需逐项核对内容。权限排查只需要知道授权是否出现、是否允许和失败发生在哪一步，不需要公开服务凭据。完成这些准备后，再进入服务器导入章节。

04 / GLOBAL ROUTING

分流：明确 Config、Proxy、Direct 的职责

三种姿态先决定请求的处理方向

结论是日常规则分流使用 Config，排查所选服务器使用 Proxy，对照本地直接访问使用 Direct。Global Routing 是应用内的总体路由选择，不是服务商协议类型，也不是系统授权开关。先确认这里的当前值，再解释某个请求为什么经过服务器或直接连接；只检查服务器名称，无法判断实际采用了哪条路径。

Config 下，规则通常按顺序检查，先命中的规则决定相应处理策略。更具体的例外应放在可能覆盖它的宽泛规则之前，FINAL 作为未命中前面规则时的收尾。下面的片段用于解释匹配关系，不是可直接覆盖所有现有设置的完整配置；修改前应先复制当前有效文件，保留原来的服务器和策略定义。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

规则类型、策略与顺序分开理解

DOMAIN 对完整域名进行匹配，DOMAIN-SUFFIX 按域名后缀匹配，DOMAIN-KEYWORD 按域名中的关键字匹配。后缀规则适合一个域及其子域的共同策略，关键字规则范围更宽，容易覆盖名称中包含相同字符的其他域名。新增规则前应先明确需要覆盖的目标范围，不要用过宽的规则替代目标域名清点。

IP-CIDR 与 IP-CIDR6 分别用于相应地址段，GEOIP 则按地址数据库中的归属结果判断。域名请求可能涉及解析，IP 规则也可能与解析行为相关；示例中的 no-resolve 用来限制该规则触发额外解析，不是提高连接速度的通用开关。规则能否命中取决于实际请求信息，不能仅凭网页展示名称推断。

PROXY、DIRECT、REJECT 表示不同处理策略，不能与 Global Routing 中的界面姿态混为一谈。Config 中某条规则命中 DIRECT，并不意味着整个应用切换成 Direct；命中 PROXY 时，还要检查当前配置中的策略引用与服务器选择。若文件使用自定义策略组名称，规则末尾必须引用实际存在且拼写一致的名称。

用最小改动确认规则是否生效

编辑配置时，先确认修改的是当前选中的文件，而不是同名副本。保存后按应用提示处理重新连接或配置重新载入，再发起新的测试请求。已存在的长连接、网页缓存和应用缓存可能继续保留原先行为，因此不要只盯着已经打开的页面；使用一次明确的新请求，并结合请求记录确认命中策略。

Proxy 下目标可用、Config 下不可用，优先比较规则命中、策略组引用和 DNS 结果，不要立即重建服务器。Direct 下正常、Proxy 下异常，则回到服务器与协议层检查。三种姿态是帮助缩小范围的对照工具，不是互相替代的修复按钮；完成测试后应切回原本需要的姿态，避免让临时测试状态成为长期设置。

规则文件还可能包含 DNS、策略组或远程规则引用，不能只看一行 FINAL 就判断整体行为。先用少量清晰规则建立可验证基线，再逐步加入例外。每次增加规则后记录目标、预期策略与实际命中，保留能够解释的变化；需要继续排查时，带着这三项查看疑难解答，比单独描述“分流不对”更容易定位。

06 / DATA

Data：区分流量统计、请求记录与服务用量

数字先看统计范围，再看大小

结论是 Data 中的流量信息用于观察客户端处理情况，不等于已有服务的最终计费用量。读取数字前先看项目名称、统计周期和当前连接状态，确认它描述的是上传、下载、当前连接还是累计记录。不同范围的数字不能直接相减比较，更不能只因两处数字不一致就判断客户端或服务端统计发生错误。

上传和下载是从当前设备视角描述数据方向。打开页面也可能产生上传请求，下载内容时同样会有协议交互，因此不能把上传完全理解为主动发送文件。流量数字表示数据传输，不表示每一段内容都已成功展示；连接重试、后台刷新以及失败请求也可能产生数据，应结合实际访问行为解释。

本地统计和服务端记录可能存在差异，原因包括统计时间范围、协议开销、重试处理和服务端自己的计算方式。还有些请求可能按规则直接连接，而用户在服务端看到的仅是经过服务器的部分。若要核对使用量，先统一观察时间和连接范围，再查看已有服务的说明，不要把 Data 当作账单结算凭据。

用请求信息定位规则与解析问题

查看请求记录时，优先找到刚刚主动发起的那一次操作，核对时间、目标和策略。设备在后台会产生其他连接，列表中最上方的一项不一定就是正在排查的网页。可以先停止无关操作，再执行一次清晰测试，缩小记录范围。需要重复验证时保持目标不变，避免把不同请求的结果当作同一请求反复变化。

如果记录中有规则命中信息，应同时读取规则类型与最终策略。命中某个域名规则，只说明匹配过程走到那里，还要确认该规则引用的策略是否符合预期。DIRECT 记录不代表服务器失效，REJECT 记录也不一定是连接错误；它们可能正是配置要求的处理。先比较预期，再决定是否属于异常。

域名与地址记录也需要分别理解。同一个网页可能访问多个域名，同一个域名可能解析到不同地址，网络切换后结果也可能改变。只看某个地址的归属，不能断定整个网页应采用什么规则。排查 DNS 时，把解析结果、命中策略与目标访问放在一起看，避免仅凭一个地址修改大范围 GEOIP 或 IP-CIDR 规则。

异常增长、清理与隐私边界

设备没有主动操作但流量仍增长时，先检查后台同步、媒体播放、系统更新和其他正在运行的网络任务，再判断是否与当前测试有关。可以在一段明确的短时观察中减少后台活动，对比连接开启前后和不同路由模式的结果。不要因为看到增长就直接认定订阅异常，客户端处理到的后台请求本来也会反映在统计中。

如果应用提供清空统计或清理记录的操作，执行前先保存排错需要的范围说明与关键现象。清理本地显示通常不等于清除服务端用量，也不等于修改服务器连接状态。不要用清空数字作为恢复服务额度的方法。重置后做同条件短时测试更适合观察变化，但必须记住新的观察起点，不能再与旧累计值直接比较。

请求记录可能包含访问域名、服务器地址、时间与其他敏感字段，导出或截图前应逐项检查。分享故障时可以保留规则类型、策略名和错误阶段，隐藏个人凭据与与故障无关的访问内容。即使订阅链接只出现一部分，也可能携带认证信息；不要假定裁掉开头就已经安全，分享前需核对完整可见范围。

Data 的合适用法是提供证据，而不是单独给出结论。将一次访问对应的网络环境、路由姿态、命中策略和结果记在一起，通常比积累大量截图更有效。若记录与观察不一致，先确认是否取到了同一次请求，再检查缓存和长连接。完成证据整理后，才进入 Settings 调整相关项目，避免仅凭统计变化大范围改动。

08 / MAINTENANCE

维护：保留有效配置，分别管理更新与恢复

应用、订阅和规则是三条维护链

结论是将 App Store 应用更新、Subscribe 列表更新和 Config 规则维护分开处理。应用更新改变客户端本身，订阅更新改变服务器资料，规则更新改变请求分流依据。三者可能在不同时间发生，遇到变化时应先确认最近动过哪一层；不能因为订阅刷新成功就判断应用已经更新，也不能用应用更新代替失效资料的核对。

通过 App Store 更新前，先保存当前有效配置并确认已有订阅资料可找回。更新后使用原来的服务器、路由模式和测试目标复核，不要立刻同时导入新规则。若结果出现变化，先记录具体功能与失败阶段，再判断是否与配置兼容、网络环境或服务器状态有关。应用更新记录可以在商店查看，不需要自行维护版本清单。

订阅更新应留意条目增删、名称变化和当前选择是否仍然有效。更新完成后至少验证一条正在使用的服务器，不要只看“成功”提示。若列表突然为空，先保留现有资料并核对链接状态，避免连续删除重建。已有服务的访问期限和权限由用户自己的服务安排决定，客户端更新不能延长或改变它们。

备份不仅是保存一个文件

备份时应区分规则文件、手动服务器参数和订阅链接。一个 Config 文件未必包含全部服务器信息，一张列表截图也无法恢复认证字段。使用应用提供的导出或备份方式前，先确认实际包含哪些内容，再把必要资料保存在自己可控的位置。备份文件可能携带凭据，不宜放在公开链接、共享目录或未经检查的聊天记录中。

对备份的检验是能否恢复，而不是文件是否存在。可以在不破坏当前有效配置的前提下检查导出内容和恢复入口，确认文件可读取、规则段完整、策略引用仍有对应对象。无需为验证备份先清空全部设置；先保留原配置，再用副本检查，能够避免把一次维护变成重新排查所有连接的问题。

换机后先从 App Store 恢复 Shadowrocket，再处理服务器资料与 Config。购买资格恢复与本地数据恢复应分别确认，同一账户取得应用不代表每一项配置一定自动出现。涉及家人共享、跨设备使用和兼容性的条件，以 App Store 页面标注为准。恢复后先手动连接，确认有效再重新启用 On Demand 等自动行为。

清理失效项与形成可复用记录

整理服务器列表时，先区分暂时测试失败和已确认不再使用。网络波动造成的一次超时，不足以判断条目应删除；先更新订阅、确认参数，再进行同条件复测。手动添加的条目应保留来源说明，订阅生成的条目则注意下一次更新可能重建。按来源整理，比单纯按名称或一次测试结果批量清理更稳妥。

配置文件也应保留一个明确的有效基线。准备修改时复制副本，写清修改目的，例如增加一个域名例外或调整最终策略；确认结果后再决定是否替换原文件。不要让多个同名副本同时承担“当前配置”，否则下一次连接时容易选错。示例中的保留地址与域名仅用于解释，不能作为实际服务器连接资料。

故障记录可以保持简短，但要包含网络类型、选中服务器所属资料、Global Routing、问题发生时间范围、错误阶段和最近一次改动。记录中不需要完整密码或订阅凭据。再次发生相似问题时，先对照上次有效状态，检查最近变动，再沿权限、服务器、解析、规则和目标访问的顺序复核，避免每次从零重建。

长期使用的检查顺序是：基础网络正常、资料仍有效、配置选择正确、路由命中符合预期、实际目标可以完成访问。先保证这条链清晰，再增加自动连接和复杂规则。需要重新走最短路径时阅读快速上手；需要核对购买与恢复时阅读下载指南；出现具体症状时到疑难解答按问题继续查阅。