Shadowrocket 完整使用手册

01 / APP STORE

正版获取与购买记录

先确认应用身份，再完成购买。Shadowrocket 是 Apple 平台付费客户端，唯一获取入口是 App Store。本站的获取应用页集中列出商店入口、正版核对与已购恢复说明；本章说明这些检查为什么要在导入配置之前完成。购买应用与准备服务器是两件独立的事情，商店交易成功只表示取得应用使用资格，并不表示已经具备可连接的服务器。

核对开发者、图标与应用 ID

在 App Store 搜索时，不要只凭“小火箭”别称或相近名称判断。打开产品详情，核对产品名 Shadowrocket、开发者 Shadow Launch Technology Limited，以及产品链接中的应用 ID 932747118。图标应与本站页头显示的官方图标一致。名称、图标和开发者需要一起确认，尤其在搜索结果包含相似名称时，应进入详情页读完整信息，而不是停留在结果列表就付款。

应用 ID 是识别同一产品的重要依据，产品页地址末尾的 id932747118 对应本手册所述应用。商店中的介绍、兼容性、购买显示与更新记录应以当前产品页为依据。手册不会用固定版本号代替这一检查，因为应用显示与系统设置可能随实际设备状态变化。若页面上的开发者或应用 ID 对不上，应返回获取应用页重新核对入口。

理解一次性买断的范围

Shadowrocket 采用一次性买断方式，付款金额、币种及购买适用性以 App Store 页面标注为准。需要特别区分：客户端一次性买断 ≠ 线路套餐。应用负责读取服务器信息、建立连接并执行分流配置；服务器地址、认证凭据与订阅链接从你的服务商处获取。应用购买记录不能用来判断订阅是否有效，订阅失效也不意味着需要再次购买客户端。

付款前确认当前 App Store 所用账号。之后重装或更换设备，寻找应用时需要核对原购买账号的记录。系统中用于其他功能的账号与商店购买账号不一定相同，不能只看设备设置顶部显示的姓名就断定购买归属。若商店按钮显示与预期不同，先检查购买历史与账号，再决定下一步，不要为了测试恢复而反复发起付款。

设备兼容性与恢复边界

iPhone 与 iPad 是本手册主要操作设备；Mac、Apple TV、Apple Vision 的兼容性也可在同一商店页查看，系统要求及购买适用性均以 App Store 页面标注为准。不要把一台设备可以下载，推断成另一台设备必定满足要求。准备换机时，分别检查目标设备的兼容性、商店账号，以及原购买记录能否正常找到。

应用恢复和配置恢复还需要分开考虑。重新取得应用，并不自动证明原有服务器、订阅、规则文件都已恢复。卸载前应记录必要设置并妥善保管配置；重新打开后，应从 Home 和 Config 检查实际内容。家人共享是否适用、产品在当前店面的可用状态，以及商店要求的验证步骤，都以页面与系统提示为准，不把一次成功恢复当成所有账号和设备的通用条件。

完成本章后，应能够回答三个问题：应用身份是否核对一致，购买记录属于哪个商店账号，自己的服务器信息保存在哪里。若仍不能确认其中一项，先解决这一项再导入订阅。关于商店显示和重装场景，可继续查阅已购恢复说明；辨认搜索结果时，可参考正版三要素核对文章。

02 / FIRST LAUNCH

首次启动与系统权限

首次打开后先熟悉页面分工，不必立即修改所有设置。Home 用于查看服务器并发起连接，Config 用于管理规则配置，Data 用于观察流量，Settings 用于调整客户端选项。不同设备、显示语言及当前应用状态可能影响项目排列，本手册使用英文名称帮助定位功能，不把某个按钮的固定坐标作为唯一依据。先确认自己在哪个页面，再执行添加、切换或删除操作。

理解添加 VPN 配置的授权

首次发起连接时，系统可能要求允许添加 VPN 配置。这是客户端建立系统网络连接所需的授权，不是订阅导入成功的证明。应在自己主动打开连接开关后阅读系统弹窗，确认请求来自 Shadowrocket，再按系统流程完成验证。如果选择取消，回到应用后开关可能无法保持连接状态；此时先检查授权是否完成，而不是立刻修改服务器密码或重新导入同一订阅。

系统保存的 VPN 配置与 Home 中的服务器列表不是同一层内容。前者用于让系统调用连接能力，后者提供连接目标和协议参数。删除系统 VPN 配置，不等于删除服务器；删除服务器，也不一定移除系统已经保存的配置。排查时应先明确要处理哪一层，避免把“重新授权”误操作成“清空全部服务器”，使问题范围扩大。

相机、剪贴板与本地内容的使用条件

通过 Scan QR Code 扫码时，系统可能请求相机权限；只有需要实时扫描时才涉及这一权限。拒绝后可到系统设置检查 Shadowrocket 的相机授权，也可以在已有文本信息的前提下改用手动添加。不要把相机权限问题当成服务器故障，因为此时尚未进入连接过程。二维码本身可能包含完整认证信息，扫描前应确认来源，扫描后仍要检查导入的类型与地址。

从剪贴板读取配置时，应先确认复制的是完整链接或配置文本，而不是网页标题、说明段落或截断后的地址。系统是否出现粘贴提示取决于当前操作与系统行为，按提示确认即可。若没有出现预期条目，回到原始信息核对格式，不要多次点击导入后直接假设添加成功。导入完成的判断，应以 Home 或 Config 中实际新增的内容为依据。

首次使用先建立可追溯的起点

第一次配置建议保留一个明确的测试目标。先添加一条自己确认有效的服务器信息，记录当前 Global Routing 选择，再打开开关。此时暂不同时修改 DNS、On Demand 或复杂规则。这样即便连接失败，也能把问题限定在授权、服务器参数和基础网络之间，而不会被多个未经验证的设置交叉影响。一次只改变一项，是后续所有排查步骤的共同原则。

如果设备上已有其他 VPN 配置，连接前先检查系统当前启用的是哪一项，避免多个连接意图互相影响。系统设置中的连接状态与应用中的开关应结合观察；只看到状态栏标识，不能说明目标网站已经通过预期策略访问。也不要在系统与应用之间快速反复切换开关，这会让连接过程、断开过程和界面刷新交错，难以判断哪次操作产生了结果。

首次授权完成后，返回 Home 确认服务器仍在、选中项正确，然后再进入下一章。若开关立即回落，记下是否出现权限提示、是否已有系统配置、是否显示具体错误。保留这些现象比“完全不能用”的概括更有帮助。需要快速完成第一次操作，可转到使用教程；权限与系统状态的集中问题可查阅FAQ。完成本章的标准是理解授权用途，而不是仅仅看到一个开启状态。

03 / SERVER & SUBSCRIBE

添加服务器与导入订阅

导入之前，先辨认手上的内容是什么：单个服务器的完整参数、单条分享链接、订阅链接，还是规则配置文件。它们对应不同对象，不能因为都表现为一段文本就放进同一个输入框。服务器描述连接目标，订阅用于批量获取和更新服务器条目，规则配置决定请求怎样分流。本手册以你已有自己的订阅或服务器信息为前提，相关信息统一从你的服务商处获取。

手动添加时逐项对应参数

在 Home 使用添加入口进入 Add Server，先选择 Type，再填写对应协议要求的字段。类型选错时，即使地址和密码看起来正确，也不能建立预期连接。地址只填写服务器地址，端口按提供值输入；密码、用户标识、加密方法、传输设置与 TLS 参数按原始资料对应填写。备注主要用于辨认，不应拿备注中的文字替代真正的服务器地址。

Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard、Hysteria2 的字段并不相同，也不存在适用于所有协议的统一参数组合。看到不熟悉的字段，先回到信息来源核对，而不是照抄另一个条目的值。尤其要区分连接地址、TLS 使用的服务器名称和传输层 Host；它们有时不同，各自承担不同作用，不能为了“保持一致”就全部改成同一个内容。

订阅导入与更新后的检查

导入订阅时，在添加界面选择相应的 Subscribe 类型，将完整订阅链接放入对应地址项，并设置便于辨认的名称。保存后等待读取完成，回到 Home 检查是否形成订阅分组，以及组内是否出现服务器。只有分组名称而没有可用条目，不能视为导入完成；应先核对链接是否完整、响应是否成功、订阅内容是否仍有效，再考虑后面的连接步骤。

订阅链接可能携带访问凭据，前后空格、换行以及被聊天软件截断的部分都会影响读取。浏览器能打开一个页面，也不代表该页面就是客户端可读取的订阅内容。若返回登录页、普通说明页或错误提示，应重新核对原始链接的用途。不要把返回文本强行当作服务器参数逐项填写，也不要在公开讨论中贴出整条链接让别人代为判断。

更新订阅会重新读取远端内容，条目名称、数量和顺序都可能变化。更新后要检查当前选中服务器是否仍存在，不能只看到更新动作结束就立刻假设连接目标没有变化。对手动填写的参数也应做好记录，避免把临时修改误认为订阅的永久内容。需要长期保存的备注与配置调整，先确认更新行为是否会覆盖，再决定采用怎样的维护方式。

扫码、分享链接与配置文件的边界

Scan QR Code 只是读取入口，导入后仍要检查协议、地址和认证字段。二维码可能包含服务器信息，也可能是订阅入口，不能只凭扫码成功提示判断对象。分享链接同样需要完整复制；如果出现多个新增条目，应逐个辨认来源与用途。导入数量不是成功标准，最小可验证的结果是一条参数清楚、可以被选中的服务器。

Config 中的规则文件与 Home 中的服务器要分别检查。导入了规则，不表示自动拥有服务器；导入了订阅，也不表示当前 Config 已包含适合你的分流安排。第一次测试建议先确认服务器参数，再检查路由姿态，最后验证规则。协议字段需要进一步了解时，可参考协议与 Type 说明，但连接参数仍以你的原始资料为准，不用文章示例替代实际认证信息。

04 / GLOBAL ROUTING

Global Routing 三姿态与规则顺序

连接前先确认 Global Routing。配置、代理、直连三种姿态分别对应 Config、Proxy、Direct，决定请求按什么思路处理。它们不是服务器协议，也不是速度等级。切换姿态不会自动修复错误密码、失效订阅或不可达的服务器；它改变的是路由决策方式。排查时必须记录当前姿态，否则同一个请求前后走了不同路径，却容易被误认为服务器状态忽好忽坏。

选择 Config、Proxy 或 Direct

Config 按当前启用的配置与规则处理请求，适合已经明确分流目标的日常使用。规则可以让部分请求使用代理、部分直接连接，也可以拒绝指定请求。Proxy 将代理作为主要处理方向，适合在检查服务器是否能承担请求时缩小规则影响。Direct 则按直连方向处理，不应拿它的访问结果证明代理服务器已经工作。三种姿态都需要结合目标请求与系统实际状态理解。

从 Proxy 切回 Config 后出现不同结果，优先查看规则与策略目标，不要马上认定服务器突然失效。反过来，Config 下某个网站可用，也不一定证明代理可用，因为该网站可能命中了 DIRECT。合理的测试方法是先确定请求预期路径，再观察它实际命中的策略。测试结束后记得恢复日常姿态，避免为了排查而临时更改的选择长期保留下来。

按从上到下的顺序理解规则

规则通常按顺序检查，先命中的条目决定后续处理，因此精确规则应放在宽泛规则之前。DOMAIN 匹配完整域名，DOMAIN-SUFFIX 匹配域名后缀，DOMAIN-KEYWORD 按域名中的关键字判断，IP-CIDR 与 IP-CIDR6 面向地址网段，GEOIP 使用地址归属判断，FINAL 处理前面没有命中的请求。规则关键字描述匹配条件，末尾策略描述处理方向，两部分应分开阅读。

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

上面是教学用的 .conf 规则片段，不是完整配置，也不代表适合所有网络。第一行只匹配指定完整域名；第二行覆盖相应域名后缀；第三行展示私有地址网段与 no-resolve 的写法；最后由 FINAL 接住剩余请求。example.com 和 example.org 只是示例域名，粘贴前应理解每条规则的含义。修改已有文件时，还要先查看它是否已经存在相同或更宽的条目。

策略目标与规则生效检查

PROXY、DIRECT、REJECT 分别表达代理、直连和拒绝的处理方向；如果规则使用自定义策略名称，该名称必须在当前配置中有对应定义。不要把服务器备注随意写成策略名，就假设客户端能自动找到正确目标。检查规则时，既要看匹配是否正确，也要看命中的策略最终指向哪里；匹配成功与连接成功是两个独立的验证环节。

修改 Config 后，确认编辑的是当前启用文件，保存内容，并按实际提示重新加载或重连，使后续测试使用新状态。已经存在的连接可能继续使用此前的路径，应用缓存也可能掩盖修改结果，因此应发起新的请求再观察。更详细的关键字解释见规则语法入门；遇到不理解的名称可查术语表。每次调整保留原文件，确认结果后再继续扩展规则。

05 / CONNECTIVITY

建立连接与分层验证

连接验证应按“基础网络、服务器选择、系统授权、测试请求、规则命中”的顺序进行。开关保持开启，只能说明客户端与系统进入了相应连接状态，不能单独证明每个目标都可访问。Home 中存在服务器，也只能说明条目已保存。把这些状态分别确认，可以避免出现某个网站打不开时，直接清空配置或重新购买应用这样的错误处理。

从选中服务器开始

在 Home 找到准备测试的服务器，点选并确认选中标记。订阅分组中有很多条目时，应先明确本次使用哪一个，避免把组名误认为真正连接目标。若刚更新订阅，重新确认选中项是否仍然有效。然后检查 Global Routing，记下当前为 Config、Proxy 还是 Direct；如果 Config 使用了自定义策略，还要确认策略最终选用的目标与预期一致。

打开顶部连接开关，完成系统要求的授权，等待状态稳定后再测试。若开关立即关闭，优先检查权限、系统 VPN 状态和应用给出的错误提示。若开关保持开启但请求失败，继续核对服务器与网络，不要把两种现象混为同一故障。测试过程中避免快速重复开关，因为尚未结束的连接与新的连接尝试可能交错，让提示与实际请求不容易对应。

Connectivity Test 能说明什么

Connectivity Test 用于检查相应测试条件下的连通表现。应结合当前路由姿态、测试目标和所选服务器读结果，不能把一个测试成功扩展成所有网站、所有应用都正常。不同测试方式涉及的路径与协议可能不同，单个数值也不能替代真实业务请求。第一次测试最好固定服务器、固定网络和固定目标，只变动一个变量，形成可以重复的比较。

先执行 Connectivity Test，再尝试访问一个你明确知道应当可用的目标，观察页面是否完整加载，而不仅是标题出现。若测试成功但目标失败，可能涉及目标本身、DNS、规则、证书或应用缓存；若测试与多个目标都失败，则先回到基础网络和服务器参数。还应区分 TCP 类请求与其他传输需求，一个普通网页成功并不代表所有通信形式都已得到验证。

按现象缩小故障范围

断开连接后先确认设备自身能访问正常目标，排除 Wi-Fi 尚未完成登录、蜂窝网络不可用或网络临时中断。基础网络恢复后，再连接同一条服务器进行比较。若只有某个网络失败，应重点关注该网络环境与传输条件；若不同网络都失败，再核对服务器地址、端口、认证信息与 TLS 参数。切换网络属于一次变量变化，测试记录中应注明，不能与规则修改同时进行。

若 Proxy 下可以完成测试，Config 下失败，优先检查当前配置文件、命中规则及策略指向。若只有一个域名异常，检查它是否被更靠前的规则覆盖，以及域名解析是否符合预期。若所有条目同时异常，也不要立即断言所有服务器失效，还要查看基础网络、系统时间、共同订阅状态或刚刚改过的公共设置。多个条目可能共享某个依赖，因此数量多并不等于彼此完全独立。

验证完成后的收尾

连接通过后，恢复预期的日常 Global Routing，再用相同目标复测一次，确保成功不是只存在于临时姿态中。进入 Data 观察新请求与策略是否一致，并确认没有遗留临时 DNS 或调试选项。对于仍失败的场景，整理可复现步骤，再查看FAQ 中的连接排查。如果需要逐步操作示范，可阅读首次连接检查文章，但不要跳过自己的参数核对。

完成本章的标准不是得到一次偶然成功，而是能够说明当前使用哪个目标、请求按什么姿态处理、如何重复验证。只有这个基础稳定，后面的 Data 分析与 Settings 调整才有可比较的起点；否则不断追加设置，只会增加不确定因素。

06 / DATA

Data 流量观察与请求判断

Data 用于观察客户端记录的流量活动，适合回答“测试时是否产生了请求、哪些目标持续通信、处理方向是否符合预期”等问题。它不是服务商的计费账单，也不是设备所有网络活动的完整历史。阅读数据前，先确认统计范围、当前连接状态与测试时间段。某个总量变大，不能直接说明刚打开的页面用了这些数据，因为后台同步与已有连接也可能同时发生。

先确定观察窗口

准备测试时先记录当前统计值或列表状态，关闭暂时不需要的前台任务，然后只执行一个明确动作，例如打开一个目标页面或刷新一次内容。回到 Data 看新增变化，而不是对着累计总量猜测。若需要清空统计，先确认清空对象与提示，保留原记录中的重要信息；清空本地统计不等于清除远端用量，也不会改变订阅的有效期和服务商侧记录。

观察上传与下载时，应理解请求本身也会上传数据，包括连接建立、请求头和应用提交内容。即使只是阅读网页，也不意味着上传必须为零。下载量与文件标称大小之间可能存在协议开销、缓存、重试或压缩差异，因此不要用单次测试的数值细微差别判断是否异常。更有价值的是比较同一操作在相同条件下是否反复产生明显不同的行为。

把请求、规则和策略连起来看

当前界面若提供请求或连接详情，应重点查看目标、处理策略与时间，而不是只看流量大小。Config 姿态下，一个页面可能同时请求主域名、图片域名、接口域名与其他资源，各自命中不同规则。主页面打开而图片失败，可能是不同资源走了不同路径，不一定是整个服务器不可用。先确定失败资源对应的目标，再回到 Config 查找相关匹配条件。

看到 DIRECT 时，应先判断这是否本来就是期望结果；看到 PROXY 时，还要确认其实际目标。不能用某个站点的内容语言、页面外观或加载速度反推策略。域名也不总能完整出现，某些连接可能主要显示地址信息，且已建立连接可能沿用之前的决策。修改规则后，重新发起请求并观察新的记录，比只盯着旧连接是否立刻改变更可靠。

区分流量、速度与稳定性

累计传输量描述已经处理的数据，瞬时变化描述某个短时间段的活动，它们都不等同于长期稳定性。网页停留时没有新流量，可能只是页面已经加载完毕；短时间有明显流量，也可能是后台任务，而非测试目标恢复。验证稳定性应重复同一操作、观察错误是否复现，并结合连接状态，而不是只追求某个瞬间更大的数值。

不同网络下的结果也应分开记录。Wi-Fi 与蜂窝网络的条件变化，会影响连接建立和传输表现，不能把两次测试混在同一段累计统计中直接比较。若怀疑某个设置导致反复重连，先保留观察结果，再只回退这一项复测。不要一边清空统计、一边更新订阅、一边更改规则，否则即使结果改善，也无法知道真正起作用的是哪个动作。

诊断数据的隐私边界

流量与请求记录可能包含域名、路径、设备访问习惯以及认证相关内容。分享前应只保留排查所需部分，移除账号、订阅凭据、完整服务器认证字段和私人请求参数。某个字段看起来像随机字符串，也可能是可用凭据，不要因为不了解用途就原样公开。完成测试后可按需要结束额外记录，避免长期保存与当前问题无关的数据。

本章的目标是形成证据链：明确测试动作，定位新增请求，核对处理策略，再决定要检查服务器、规则还是目标本身。Data 提供的是观察依据，不负责替代这些判断。将异常现象与上一章的最小测试记录合并，通常比一张只有累计总量的截图更能帮助定位问题。

07 / SETTINGS

Settings 常用项与调整边界

Settings 应在基础连接已验证后逐项调整，而不是首次打开就把所有开关全部开启。不同设置作用于不同层级：有的影响何时连接，有的影响域名解析，有的影响测试与记录。调整前先写明要解决的现象，再确认项目的说明与当前值。界面若没有本章提到的项目，应以设备上实际显示为准，不通过相似名称猜测同等功能，也不要套用另一份配置的全部设置。

On Demand：连接条件而不是服务器修复

On Demand 用于按条件触发连接，其实际行为还受到系统 VPN 配置、网络变化和设备管理状态影响。应先确认手动连接能够稳定工作，再考虑启用。否则基础参数错误与自动触发行为叠加，会表现为反复连接、开关状态变化或网络切换后结果不一致，反而难以区分。按需连接决定什么时候尝试建立连接，并不负责修复不可用的服务器。

启用前明确自己的预期：在哪些网络条件下需要连接，在哪些情况下需要停止，以及手动断开后希望发生什么。修改后分别测试应用前台、切换网络与设备重新唤醒等真实场景，观察系统实际结果。不能只在设置页看到开关开启，就判断所有条件都已生效。排查自动重连问题时，先暂时回到手动连接状态，可以帮助隔离触发条件与服务器本身。

DNS：先区分解析失败与连接失败

DNS 负责把域名解析为地址，解析成功只是后续连接的前提之一。域名无法解析，与已经得到地址但建立连接失败，应分别处理。检查时先看故障是否只涉及域名请求，再核对当前 Config 与 Settings 是否同时包含 DNS 相关内容。文件配置与界面设置可能共同影响最终行为，应以当前项目说明及实际请求结果为准，不能只检查其中一处就假设另一处不存在。

DNS 选项不是数值越多越好，也不是随意替换后就能提升所有访问表现。解析服务本身需要可达，返回地址还需要符合后续路由预期。若改动后只有部分目标异常，记录目标域名与新旧设置，恢复原值做对照。不要把直连地址访问成功当作域名解析必定正常，也不要因为某个测试页面能显示内容，就忽略应用实际请求可能使用不同域名或缓存。

测试、记录与证书相关项目

连接测试目标与测试方式会影响 Connectivity Test 的解释。若修改测试项，应保留原值，并用自己明确知道用途的目标验证；测试目标不可用时，结果可能反映目标异常，而不是服务器异常。日志或诊断记录应围绕具体问题临时使用，记录时间越长、范围越大，并不一定越容易分析。测试完成后检查是否仍保留不必要的详细记录，并按隐私需要处理已有内容。

证书与 HTTPS 相关设置需要特别谨慎。普通服务器连接和基础规则分流，不应被当成必须启用解密检查的理由。遇到证书错误，先核对设备时间、目标域名与服务器 TLS 参数，不以关闭验证作为常规修复。若不清楚某项证书功能的影响，先保留原状态，并阅读当前项目的说明；不要仅为了让一个错误提示消失，就改变整个设备的信任判断。

配置作用范围与回退方法

每次修改后，应知道该值是只属于某个服务器、某个 Config 文件，还是应用层设置。修改单条服务器的传输参数，不代表订阅其他条目同步改变；切换 Config，也不一定意味着所有应用设置随之恢复。把作用范围写入简单记录，可以解释为什么切换服务器后问题仍存在，或为什么换一个配置文件后结果突然不同。排查共同故障时，先查看共同作用的设置层。

回退时按修改的相反顺序恢复，一次恢复一项并复测，而不是直接重置全部内容。若需要重置，先备份服务器与配置，确认敏感信息保存位置，并记录哪些值需要重新填写。Settings 的最终目标是让行为可预测，不是堆积更多选项。日常只保留自己能够解释用途的改动；对于仍不明确的界面词，可查阅术语表，再决定是否需要调整。

08 / MAINTENANCE

订阅更新、备份与日常维护

日常维护的重点是保留一个已验证的状态，并让每次变化都能追溯。应用更新、订阅更新、规则修改和设备换机属于不同操作，不应集中到一次没有记录的尝试中。遇到问题，先确认最近改变了什么，再选择最小修复范围。只要基础连接仍可重复验证，就没有必要为了某个局部异常删除全部服务器与配置；维护应降低不确定性，而不是不断重新开始。

应用更新与订阅更新分开处理

应用通过 App Store 更新，当前兼容性与相关说明以商店页面为准。更新应用不会自动证明订阅仍有效，也不保证某个远端服务器状态不变。订阅更新读取的是服务商提供的内容，两者的来源与目的不同。建议先记录现有连接结果，再完成其中一种更新并复测，确认正常后再进行下一项，这样才能把异常与具体变化对应起来。

更新订阅前确认需要保留的手动修改，更新后检查分组内容、当前选中项与规则引用的目标。若名称或条目变化，原先按名称辨认的记录可能不再准确，应重新核对地址和用途。遇到更新失败时，不要立即删除现有分组；先确认旧条目是否仍可连接，再检查订阅链接、基础网络和返回内容。保留可用状态，有助于区分读取故障与服务器故障。

备份需要区分内容与凭据

备份前列出要保存的对象：服务器信息、订阅入口、Config 文件、必要的 Settings 原值，以及商店购买账号的核对记录。使用应用当前提供的导出或系统文件保存功能时，先看清导出范围，不假定某个文件必定包含全部设置。完成后检查文件能否找到、名称是否清楚、保存位置是否适合长期保管。备份存在但无法读取，不能算已经完成恢复准备。

配置文件和分享内容可能包含密码、用户标识或订阅凭据，不能按普通说明文档公开存放。用于讨论问题的副本应先去除敏感部分，真正用于恢复的备份则需要保留必要字段并妥善保护。二者用途不同，不要将经过删改的诊断副本当成唯一恢复文件。若凭据曾被意外公开，应从你的服务商处确认相应处理方式，并检查旧信息是否仍然有效。

换机与重装采用分阶段恢复

在新设备上先从 App Store 找回应用，确认系统要求与购买适用性以 App Store 页面标注为准，然后打开应用检查实际状态。接着恢复一条服务器或一个订阅，完成系统授权，验证手动连接。基础连接成功后再恢复 Config 和日常 Settings，最后测试 On Demand。不要一次导入所有内容后仅凭开关状态判断恢复完成，因为某个旧设置可能只在网络切换后才显现影响。

旧设备上成功的配置，也可能依赖当时的网络、系统权限和仍有效的服务器信息。新设备出现差异时，先比较这些前提，而不是认定文件损坏。保留旧设备上的可用记录，逐项比较服务器参数、Global Routing 与当前 Config；确认恢复完成后再处理旧设备中的敏感内容。购买恢复的具体路径可查阅已购项目恢复，不要把商店恢复与配置迁移混成一个步骤。

建立固定的复查与排错流程

每次重要调整后重复同一组检查：当前服务器明确，Global Routing 正确，Connectivity Test 与实际目标能够验证，Data 中的策略符合预期，临时调试设置已经收回。若问题重现，先暂停继续修改，写下最后一次正常状态与首次异常之间的变化。这样的记录能缩小范围，也能防止几天后忘记某个临时选项为何开启，导致下一次排查从错误前提出发。

需要求助时，提供设备类型、网络环境、路由姿态、是否能复现、已经做过哪些对照，以及不含凭据的错误提示。避免只有“连不上”或“很慢”这样的概括，也避免把完整备份作为第一份材料。根据故障阶段回到本手册对应章节：导入异常查服务器与订阅，路径异常查 Global Routing，开关或请求异常查连接验证，自动触发异常查 Settings。

到这里，应当形成一条完整使用链：正版获取建立应用身份，首次授权建立系统条件，服务器信息提供连接目标，Config 决定路由，测试与 Data 提供证据，Settings 调整行为，备份与记录维持可恢复性。日常操作无需反复重做全部流程；出现变化时，从受影响的那一层开始检查即可。快速操作回到使用教程，常见疑问查阅FAQ，规则细节则继续阅读站内相关说明。