Shadowrocket 完整使用手册

01 / 获取

App Store 正版与购买范围

先核对产品，再确认购买

Shadowrocket 是 Apple 平台的付费客户端，通过 App Store 获取。进入商店后先看产品详情，不要仅凭搜索结果中的名称决定购买。核对开发者为 Shadow Launch Technology Limited，检查图标与本站页头的官方图标一致，再确认产品链接中的应用 ID 为 932747118。三项共同定位产品，名称相似不能替代这一步。具体操作见下载指南的正版核验。

商店页面还承担价格、兼容性与购买条件的核对。先确认当前使用的设备出现在兼容性说明内，再看实际支付金额。系统要求与购买适用性均以 App Store 页面标注为准。iPhone 与 iPad 是本手册的主要操作对象；Mac / Apple TV 同店可得，但不要把移动设备上的按钮位置直接当作其他设备的操作说明。

客户端买断与连接资料分开准备

客户端一次性买断 ≠ 线路套餐。购买取得的是客户端使用资格，不会因此自动出现可用服务器。连接需要用户已有的服务器信息或订阅，相关资料从你的服务商处获取。操作前至少确认资料的类型、适用协议和有效状态。只有一个服务器地址通常不足以完成连接，端口、身份凭据和传输设置同样需要匹配。

美区标价以商店页面为准，各店面按当地货币显示，最终金额以购买确认页为准。不要把客户端价格理解为通信服务费用，也不要根据手册中的示例推定实际连接条件。本站提供官方手册，不提供节点服务。遇到服务器到期、凭据变更或服务端维护，应核对已有服务资料；重复购买客户端不会修复这些问题。

安装完成后的准备顺序

完成商店购买后，等待应用下载结束，再从设备桌面打开。若图标仍处于等待状态，先检查设备网络、可用存储空间和商店提示，暂时不要进入代理配置排错。此时客户端尚未开始承担网络连接，安装阶段与连接阶段属于不同问题。有关购买和下载状态的处理，可参照App Store 正版下载流程逐项确认。

打开前整理好现有资料，区分单个服务器链接、订阅地址和配置文件。单个服务器描述一条连接；订阅用于获取并维护一组服务器；配置文件主要承载规则与相关设置。三者可能以文本或链接形式交付，但用途不同。不要因为内容都可以复制，就把订阅地址粘贴到服务器地址栏，或把配置文件当作订阅更新。

已购记录与本地配置的边界

换机时先在 App Store 检查购买记录，使用完成购买时的 Apple 账户查找应用。能否重新下载、家庭共享是否适用，均以 App Store 页面标注为准。若商店仍显示购买价格，应先确认账户和已购项目，不要急于再次付款。应用获取资格与客户端内保存的数据是两件事，恢复已购并不等于恢复服务器和规则。

因此，在旧设备仍可用时就要规划配置迁移。记录正在使用的订阅名称、配置名称和必要设置，妥善保管原始资料。订阅地址与密码都应视为敏感内容，不要放进公开笔记或截图。购买阶段完成的标志是应用能够正常打开、正版信息已经核对；下一步才是授权系统网络配置，并将已有资料导入客户端。

02 / 初始化

首次启动与系统权限

理解添加 VPN 配置的系统提示

首次建立连接时，系统可能请求允许 Shadowrocket 添加 VPN 配置。这是客户端接管设备网络请求所需的系统授权，不是服务器账号，也不是订阅已经生效的证明。确认提示来自正在操作的客户端后，再按系统要求完成认证。授权通过只说明系统允许建立相应网络配置，远端服务器是否能访问仍需后续验证。

如果当时选择拒绝，先回到客户端重新发起连接，查看是否再次出现提示；必要时到系统设置的 VPN 相关项目检查配置状态。不同系统的入口名称和层级可能不同，以设备实际显示为准。不要为解决一次提示就清除所有网络设置。先判断是权限尚未授予，还是已经授权但连接失败，再决定下一步。

用 Home 确认操作对象

进入 Home 后，先辨认连接开关、Global Routing、Connectivity Test 与 SERVER 列表。连接开关负责启动或停止当前连接；Global Routing 决定请求使用何种路由方式；SERVER 列表承载已添加的服务器；Connectivity Test 用于辅助测试。这些区域各有职责，列表中存在服务器并不表示已经连接，测试有结果也不表示规则符合预期。

SERVER 列表尚为空时，先完成下一章的导入，不要反复打开连接开关。已有条目时，检查名称、类型和默认选择，避免把旧资料当作新导入的资料。界面布局会随设备尺寸和应用调整而变化，本手册使用界面词定位功能，不依赖固定坐标。各区域的入门说明可阅读首次打开与 Home 页说明。

按实际操作授予附加权限

使用 Scan QR Code 时，相机权限用于识别二维码；如果通过照片选择二维码，系统可能另行请求照片访问。仅在需要该操作时授权相应权限。手动输入服务器与扫描二维码是不同入口，相机没有授权不等于网络连接权限被拒绝。扫码失败时，应先区分权限未开放、图像不清晰和内容类型不受当前入口识别。

二维码和剪贴板内容可能包含完整凭据。操作前确认内容来自已有的服务资料，识别后先检查导入预览，再保存。不要对收到的任意图片直接执行导入，也不要将含有二维码的完整页面公开分享。若复制后未出现导入提示，可以回到添加入口按资料类型操作；不要为了触发提示而连续复制多份不同内容，导致来源混淆。

连接前排除系统层面的干扰

设备上如果存在其他正在工作的 VPN 配置，应先了解其用途与管理要求。测试 Shadowrocket 时，尽量保持一次只有一个明确的网络接管对象，避免系统状态来回变化。在受组织管理的设备上，配置和权限可能受管理策略限制；遇到不可修改的开关或系统限制提示，应按设备管理要求处理，而不是反复重建客户端配置。

此外，连接公共网络时可能需要先完成网络自身的登录或确认。先停止客户端连接，用设备原始网络检查是否能正常访问，再开始配置。系统时间应保持准确，错误时间可能影响安全连接中的证书判断。初始化完成后，记住哪些权限已经授予、哪些尚未使用；以后出现异常时，便能把权限问题与服务器问题分开排查。

03 / 导入

服务器、Subscribe 与协议参数

按资料类型选择入口

单个服务器资料可通过 Add Server 手动填写，或使用客户端支持的分享内容导入；一组持续更新的服务器通常通过 Subscribe 管理。首先确认收到的是哪一种资料，再选择对应入口。已有订阅从你的服务商处获取，完整地址可能含有身份凭据。粘贴时检查开头、结尾和换行，避免聊天软件附带的标点成为地址的一部分。

保存后回到 Home，查看新增内容位于哪个分组、名称是否合理、服务器类型是否与原始资料一致。出现条目表示内容已被客户端读取，不代表远端凭据有效。若导入结果为空，先确认返回内容是否确实是客户端可识别的服务器资料，而不是登录页或提示文本。不要通过重复建立多个同名订阅来掩盖一次更新失败。

协议参数逐项对应

协议名称决定字段的含义。Shadowsocks、VMess、VLESS、Trojan、Hysteria2 与 WireGuard 不能共用一套填写习惯。先选正确类型，再按原始资料填地址、端口及该协议要求的身份字段。名称只是本地识别标签，改名不会修复服务器连接；端口和凭据却直接参与通信，应原样核对，尤其留意复制时的空格和大小写。

启用 TLS 的连接还可能涉及 Server Name 等字段，它们不一定与填写的连接地址完全相同。使用特定传输方式时，Path、Host 等字段也需对应服务端。不要依据字段名称自行猜值，缺失内容应回到原始资料确认。关闭证书验证不是常规修复办法，会削弱对远端身份的判断；先检查名称、系统时间和资料是否过期。

订阅更新与本地编辑分开处理

订阅保存后执行更新，再观察服务器数量、名称和分组变化。更新失败可能发生在获取地址、网络访问或内容解析阶段，而不是所有服务器同时失效。先保留当前可用列表，检查订阅地址是否改变、是否需要续期确认，以及当前网络是否能获取内容。不要立即删除整个分组，否则会失去对比依据，也可能中断原本可用的连接。

订阅管理的服务器在后续更新时可能被重新生成或覆盖。若需要临时验证一个字段，先记录原值，并了解客户端对订阅条目编辑的处理方式。长期修正应以服务端提供的准确资料为依据，不要依赖每次更新后重复手改。更新成功后也要重新确认默认服务器，因为名称变化、条目替换或移除都可能影响原有选择。

手动添加、扫码与重复条目的判断

手动添加适合资料完整且需要逐项核对的情况；Scan QR Code 适合已有兼容二维码的情况。扫码只是录入方式，不会提高服务器可用性。识别后核对类型和主要字段，再保存测试。若多个条目看起来同名，比较协议、地址和端口，不要仅按名称批量删除；不同传输配置也可能故意使用相近名称。

完成导入后，选择一台资料明确的服务器作为初始测试对象。先不增加复杂规则，也不一次改动多种协议字段。能够说明“这一条来自哪份资料、最后核对过哪些字段、为何设为默认”，就具备了继续排错的基础。订阅只负责资料维护，实际请求如何选择路径由 Global Routing 和配置决定，下一章将分别说明。

04 / 分流

Global Routing 与配置文件

先分清 Config、Proxy、Direct

Global Routing 的配置、代理、直连分别对应 Config、Proxy、Direct。Config 根据当前配置中的规则决定请求去向；Proxy 用于让请求按代理模式处理；Direct 用于按直连模式处理。模式选择改变的是路由判断方式，不会自动修复错误凭据。遇到异常时先确认当前模式，避免把规则导致的直连误判为服务器没有工作。

排错时可以短暂切换模式做对照，但每次都要记录切换目的。Proxy 下可用而 Config 下异常，优先检查规则和策略；两种模式都异常，则继续核对服务器、解析和当前网络。Direct 下能访问某个目标，只能说明该目标在当前直连路径上可达。不同目标的网络条件不同，不能由一个页面的结果推导全部连接情况。

配置文件的段落与职责

Config 页面管理配置文件，Global Routing 中的 Config 则是路由模式，两者名称相近但操作对象不同。配置文件可包含 General、Rule、Host 等段落，各自承担通用设置、规则和主机映射等职责。编辑前确认当前实际使用的是哪一份文件，另存可用副本。文件存在于列表中，不等于它就是连接时启用的配置。

[General]
bypass-system = true
dns-server = system

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

这段示例用于解释结构，不是适用于所有网络的完整配置。example.com 是示例域名；PROXY 表示代理策略，DIRECT 表示直连策略。实际代理去向还要结合当前服务器选择或已定义的策略。保留原配置中已验证的设置，只替换需要测试的部分。不要把来源不同的多份文件整段拼接，以免段落重复或策略引用失去对应。

规则按顺序匹配

规则通常按顺序判断，具体条件宜放在宽泛条件前。DOMAIN 匹配指定域名，DOMAIN-SUFFIX 用于域名后缀，DOMAIN-KEYWORD 用于域名中的关键词；IP-CIDR 和 IP-CIDR6 面向地址范围；GEOIP 按地址归属数据库判断。FINAL 处理前面未命中的请求，应放在规则末尾。前面的宽泛规则已经命中时，后面更精确的规则不会再发挥预期作用。

域名规则与地址规则依赖的信息不同。某次请求能否用域名条件判断，与客户端实际获得的请求信息有关；地址归属结果也不等于服务业务归属。不要因为名称里包含某个词，就对所有相关请求写一条宽泛关键词规则。一个页面可能访问多个域名，应以实际记录为依据，逐步补充必要条件，避免扩大修改范围。

验证修改，而不是只看保存结果

保存后确认配置仍能被识别，再建立新请求检查命中结果。编辑成功只表示文本被保存，规则是否生效还取决于当前启用文件、路由模式和请求匹配信息。长连接可能继续使用已有路径，验证时应重新发起请求。若修改后异常，回退刚改的一组规则，比连续追加更多条件更容易定位原因。

配置与订阅应分别维护：订阅更新服务器资料，配置控制路由及相关行为。规则中的策略名称需要有对应定义，引用不存在的名称不能靠增加服务器数量解决。暂时不理解某段设置时先保留可用副本，不要凭注释猜测后直接删除。关于具体异常可转到疑难解答，但应先记录当前文件、模式和目标请求。

05 / 验证

默认服务器、连接与测试

建立一个变量明确的测试起点

回到 Home，在 SERVER 列表确认默认服务器，观察 DOT 标记所指向的条目。点开编辑页面与选择默认服务器不是同一个操作，应以列表中的实际选择状态为准。初次测试选一台资料来源清楚、协议参数已经核对的服务器。暂时不要同时启用复杂自动选择条件，否则连接变化时难以判断是网络变化还是选择逻辑变化。

接着确认 Global Routing，记录当前配置名称，再打开连接开关。系统若请求添加 VPN 配置，按前文完成授权。等待状态稳定后再发起测试，不要连续快速开关。频繁重连会混合多次尝试的记录，也可能让系统状态还未更新就进入下一轮操作。若系统提示明确错误，先保留提示文字，再停止操作进行分类。

把测试结果拆成不同层次

Connectivity Test 用于辅助判断连接情况，具体测试方式及目标以当前客户端设置为准。测试结果受本地网络、服务器响应、测试目标和协议条件共同影响。数值较小不等于所有业务请求都正常，出现超时也不能立即证明身份凭据错误。先确认测试针对哪一台服务器、采用何种方式，再与实际访问结果相互印证。

验证应包含三层：系统允许建立连接、客户端与所选服务器能够通信、目标请求按预期策略返回内容。依次检查这三层，能够避免把“开关已打开”当作成功结论。完成连接后访问一个平时可以判断结果的目标，并检查它应走的策略。随后再测试另一类请求，确认不是某个页面缓存造成的可用假象。

按网络、参数、规则的顺序定位

连接失败时先停止客户端，验证设备原始网络是否可用。若原始网络也异常，先处理网络登录、信号或路由问题；若原始网络正常，再核对默认服务器和协议参数。地址无法解析、端口不可达、身份验证失败、证书判断失败属于不同阶段，应结合提示与记录区分，不能都归结为“节点超时”。

随后用临时模式对照隔离规则因素。若代理模式能完成同一目标请求，而配置模式不能，查看当前文件与命中策略；若两者都失败，继续检查服务器资料和网络条件。每次只改一个字段或一个模式，并重新发起相同请求。具体顺序也可参照节点超时排查说明，不要在排查中同时更换所有条件。

连接成功但部分内容异常

网页主体加载而图片、登录或其他资源失败时，通常需要分开观察多个请求。一个页面可能连接不同域名，分别命中不同规则，也可能使用持续连接。记录失败资源对应的域名、策略和错误阶段，再决定调整。不要只把网页地址加入规则就认为所有资源会一起改变路径，也不要直接把全部请求改成同一种策略长期使用。

如果只有某个应用异常，先比较该应用与浏览器是否请求同一目标，再考虑缓存、解析和连接复用的影响。必要时完全退出相关应用后重试，保留调整前后的结果。涉及安全连接错误时，先检查系统时间和服务器名称。不要用跳过身份验证来追求一次测试通过，否则会失去本应保留的连接安全边界。

结束测试并恢复日常状态

一次验证结束后，把临时使用的路由模式改回日常设置，确认默认服务器没有被测试操作改变。记录可用配置、测试网络和主要结论，不必记录不断变化的瞬时数值。有效结论应说明“在什么条件下，哪个请求，以什么策略完成”，而不是只写“连接正常”。这样下一次异常才有可比较的基线。

初次完成连接可对照第一次连接与 Connectivity Test检查遗漏。若仍需继续排错，保留最少必要信息：服务器类型、模式、错误文字及复现步骤即可。密码、订阅地址、私钥和完整分享内容不要公开。后续使用 Data 观察请求时，也应沿用这种分层判断方式。

06 / 观察

Data 流量与请求判断

把统计当作现象，不当作结论

Data 用于查看客户端提供的流量与连接相关信息，具体项目以实际界面为准。流量增加说明有数据经过相应统计范围，不代表请求最终完成，也不代表所有流量都经过同一个远端。反过来，暂时没有明显变化也可能与缓存、统计刷新或请求尚未发起有关。先明确观察对象，再解释数字，避免用总量替代具体请求结果。

查看数据前确认连接正在运行、默认服务器正确，且测试期间没有大量后台任务。若一边同步照片一边排查单个网页，汇总流量很难对应到目标操作。尽量缩小观察窗口，只执行一次可复现的请求，再查看新增记录。这样可以把“页面打开”“请求产生”“策略命中”三件事按时间顺序联系起来。

从目标请求追到策略

如果客户端当前提供请求记录或连接详情，先找到与复现时间相符的目标，再查看可用的域名、地址、策略与错误信息。不同协议和请求类型能展示的信息可能不同，不要假定每条记录都有完整网址或内容。应优先回答请求去了哪里、匹配哪条判断、停在哪个阶段，而不是尝试从一条记录推测整个应用的全部行为。

Config 模式下尤其要核对预期与实际策略。若预期为 PROXY，实际却为 DIRECT，先检查更靠前的规则与当前启用文件；若策略符合预期但请求仍失败，继续检查对应服务器及目标可达性。规则命中只能证明选择过程，不能证明远端服务正确返回。将策略层和传输层分开，可减少无效修改。

区分解析、建立连接与数据传输

域名请求通常先经过解析，再向选定地址建立连接，之后才交换应用数据。解析失败时更换密码没有意义；连接地址已经确定但建立连接失败时，应关注网络、端口和服务端；建立连接后出现安全握手问题，则检查证书名称、时间与相关参数。不同阶段可能使用不同错误文字，应结合上下文阅读，保留原文而不是改写成统一描述。

看到域名对应多个地址时，不要立即认为配置混乱。服务可能按网络、时间或地理位置返回不同结果，地址规则因此也可能产生不同命中。先重复同一个请求确认现象，再比较直连与代理路径的解析条件。不要未经验证就把某一次得到的地址永久写进 Host，固定地址可能很快失去适用性，并引入新的故障。

统计范围与服务侧记录可能不同

客户端统计、设备系统统计和服务侧统计的边界可能不同。它们可能分别计算不同方向、连接开销或时间范围，因此不能要求每个数值完全一致。若需要判断异常消耗，先统一观察时段，暂停明显的后台任务，再看变化趋势。不要把一次短时间差值直接解释成计费错误，也不要把某个总量当作所有应用的完整使用记录。

重置统计之前先保存需要比较的结论，并确认重置操作影响哪些项目。清空本地显示通常不会改变服务侧使用记录，也不会修复连接问题。排错时更有价值的是某次请求对应的状态变化，而不是不断清零后反复观察。若客户端存在不同统计视图，先看其标签与范围说明，再决定用于哪一种判断。

记录分享前进行最小化处理

请求记录可能包含访问目标、服务器地址及其他识别信息。导出或截图前先检查可见内容，只保留解决问题需要的部分。订阅链接中的查询参数、服务器密码、UUID 和私钥不应随记录公开。即使只是分享一个二维码，也可能等同于分享完整连接资料；遮住名称并不意味着已经遮住敏感内容。

整理排错材料时，可以写明复现动作、发生阶段、所用协议与策略，再摘录不含凭据的错误原文。保留一份本地完整记录用于自己对照，对外只提供最小片段。若问题已定位到服务端参数，核对原始资料即可，不要继续收集无关请求。观察结束后回到日常模式，避免长时间保留为测试而启用的额外记录。

07 / 设置

Settings 常用项与修改边界

先确认设置作用在哪一层

Settings 中的选项并非都控制同一件事。有的影响客户端全局行为，有的影响连接过程，有的只是显示和测试偏好；服务器编辑页中的参数则可能只作用于一个条目。修改前先辨认作用范围，并检查配置文件是否还定义了相关行为。不要把某一条服务器的传输参数当作全局网络设置，也不要假设同名选项在不同位置具有相同优先关系。

本章按用途解释设置，不要求每台设备都显示完全相同的项目。界面名称与可用选项以当前客户端为准。遇到看不懂的选项，先记录现值和要解决的具体问题，再查阅对应说明。若当前连接已经可用，保留默认行为通常比批量开启高级选项更便于维护；没有明确目标的调整很难验证，也很难在出错后回退。

On Demand 在手动连接之后设置

On Demand 用于按条件触发连接相关行为。启用前先完成手动连接与目标请求验证，否则自动触发只会把尚未解决的问题变得更难观察。进入相关设置后，仔细确认启用状态与适用条件，再进行一次真实环境切换测试。不要把“已开启”理解为任何情况下都会维持连接，最终行为还受系统、网络条件和配置影响。

测试按需连接时，分别观察预期触发和预期不触发的情况。例如切换网络后，先等待系统状态稳定，再查看连接状态与请求结果。若出现反复连接，先暂时关闭 On Demand，以手动方式确认基础连接仍然可用，再检查触发条件。还应注意受管理设备上的限制，避免客户端条件与系统管理要求形成难以判断的交互。

DNS 调整要有可复现的问题

DNS 影响域名到地址的解析，也可能影响部分规则判断。只有在已经确认解析阶段异常或结果不符合预期时，再调整相关设置。记录原来的解析方式、测试域名和错误现象，然后一次只改一项。不要把切换 DNS 当作任何连接故障的第一步；错误端口、失效凭据和不匹配的传输参数不会因为解析方式改变而自动恢复。

配置示例中的 dns-server = system 表示使用系统相关解析设置，并不承诺适合所有网络。若使用其他解析方案，应理解其访问路径与适用条件，避免出现解析服务本身又依赖尚未建立的连接。修改后重新发起请求，考虑缓存影响，再比较结果。测试结束要清楚最终保留哪种方案，不要让临时修改长期堆积。

测试、超时与网络切换

Connectivity Test 的相关设置决定测试如何执行，修改测试方式会影响结果的可比性。比较两台服务器时应保持相同方法与目标，避免把不同测试条件下的结果直接排序。超时设置也应有合理边界：过短可能把正常但较慢的响应当作失败，过长则延迟故障反馈。先理解当前网络特点，再考虑调整，而不是单纯追求好看的结果。

网络切换后出现短暂异常时，先等待系统完成切换，再建立新请求。旧连接可能无法沿新路径继续，部分应用也会自行重试。若只有切换时发生问题，应把它与固定网络下持续失败分开记录。检查 On Demand、默认服务器和新网络本身的可用性，比同时重置全部设置更有效，也能保留原先稳定的配置。

安全相关选项保持明确用途

涉及证书、HTTPS 或请求处理的高级选项，应先理解用途和影响范围。普通服务器导入与首次连接不应被扩展为一整套额外的证书操作。若需要专项功能，单独保存配置并按其说明验证，不要把测试条件混入日常配置。任何降低远端身份验证要求的修改，都应先重新检查原始参数，而不是作为通用排错捷径。

设置变更记录可以很简单：原值、修改原因、测试结果和保留决定。只要能够回到上一份可用状态，就比零散记忆可靠。发现修改没有解决问题时及时恢复，不要因“已经改过”而继续保留。最后确认当前配置、Global Routing 和默认服务器，完成一次实际访问，让设置调整以可观察的结果结束。

08 / 维护

更新、备份与日常排错

维护一份可回退的工作状态

日常维护的核心不是频繁改动，而是知道当前为什么可用。保留一份已经验证的配置，记录默认服务器、Global Routing 和必要的全局设置。修改前另存副本，文件名可按用途区分，不必堆叠难以辨认的编号。每次只修改一组相关内容，验证后再决定是否替换日常配置，这样异常发生时能够沿着最近改动回退。

备份范围应包括自己编辑的规则和必要设置，但敏感资料需要单独保护。服务器密码、私钥和订阅地址不应随普通文档一起公开存放。使用客户端当前提供的导出、备份或恢复功能时，先确认包含哪些数据，再保存到自己可控的位置。备份完成不等于恢复已经可靠，必要时用副本检查文件能否读取，并保留原始资料。

区分应用更新与订阅更新

应用更新通过 App Store 完成，订阅更新在客户端内维护服务器资料，两者相互独立。更新应用不会替用户补齐过期凭据，更新订阅也不会改变商店购买状态。进行应用更新前，先保存重要配置并阅读商店中的说明；完成后检查当前文件、默认服务器与连接状态，不要仅凭应用能够打开就结束验证。

订阅更新后重点检查分组、条目和默认选择。若服务端移除了某台服务器，原来依赖该条目的选择可能需要重新确认。名称相同也不保证内部参数未变，异常时应对照已有资料。更新失败先保留可用内容，判断是获取失败还是解析失败，再决定重试。不要把应用更新与订阅更新同时执行后，才开始追查哪个变化影响了连接。

换机与重装按三层恢复

恢复时先解决应用获取，再恢复服务器资料，最后恢复配置与设置。第一层通过 App Store 已购记录确认；第二层使用自己妥善保管的订阅或服务器信息；第三层导入备份并核对作用范围。三层完成顺序清楚，便能避免应用已安装却没有服务器，或服务器已导入却仍使用空白规则的情况。

新设备上重新确认系统授权和兼容性，系统要求以 App Store 页面标注为准。不要假定旧设备上的权限会完整迁移，也不要把购买恢复当作本地数据恢复。恢复后先验证一台服务器和一个目标，再打开按需连接及其他附加条件。旧设备在迁移验证完成前保留可用状态，能够提供最直接的对照。

按故障阶段收敛，而非全面重置

出现异常时先写清现象：无法启动连接、测试超时、部分请求失败，还是规则去向不符。然后确认最近发生了什么变化，包括网络切换、订阅更新、规则编辑和系统设置调整。优先检查与变化直接相关的一层。全面重置会同时抹去线索和可用设置，只有在明确理解影响并已有备份时，才考虑较大范围的恢复操作。

如果需要继续查阅，购买与恢复问题转到下载指南，基础操作转到快速上手，常见异常转到疑难解答。查询时保留界面原词与错误原文，有助于准确定位对应功能。对于服务端信息不完整的情况，应核对已有服务资料；反复切换规则不能补足缺失的协议字段。

用最小记录完成日常检查

一份维护记录只需回答四个问题：当前使用哪份配置、默认服务器是哪条、最近改过什么、验证结果如何。记录异常发生的网络和复现步骤，比保存大量无筛选截图更有价值。问题解决后补上真正原因与回退方法，删除公开副本中的凭据。下一次出现类似现象时，可以先验证原因是否相同，而不是照搬上次的所有改动。

最终检查应回到实际使用：当前模式符合预期，目标请求能够完成，规则去向能够解释，临时测试选项已经恢复。连接可用后无需继续叠加设置。保持一份清楚、可验证、可回退的配置，比积累很多用途不明的文件更容易维护。本手册的八个阶段可以反复使用：先定位所在层，再检查输入资料，最后用同一请求验证结果。