01 / SUBSCRIBE
Subscribe 入口与数据边界
先分清订阅、服务器和 Config
订阅是用于取得服务器列表的地址，服务器条目是一次连接所需的具体参数，Config 则用于保存规则及相关配置。三者可以配合使用，但不能互相替代。把普通网页地址填入 Subscribe，并不会自动生成可连接的服务器；把服务器分享链接当作规则文件导入，也不能得到预期的分流行为。操作前先确认手中资料的用途，比反复尝试不同入口更有效。
订阅通常在更新时返回一批服务器资料，其中可能包含地址、端口、协议和认证字段。它解决的是“列表从哪里更新”的问题，不等于当前选中了其中某一条，也不等于已经开启连接。列表出现名称后，仍需核对条目、选定服务器，并按实际需求设置 Global Routing。导入成功、连接成功和目标服务可用，是三个需要分别验证的结果。
本章以用户已有自己的订阅为前提。准备资料时，保留订阅地址原文，以及已有服务说明中的格式、认证方式和更新要求。不要把管理网页、登录页面或付款记录页面的地址当作订阅地址。即使这些地址来自同一个域名，它们返回的数据也可能完全不同；能在浏览器显示页面，并不能证明该地址能被 Subscribe 解析。
从 Add Server 建立订阅条目
在 Home 找到添加入口，进入 Add Server 后检查 Type。添加订阅时选择 Subscribe，填入完整的订阅地址，并写一个能辨认用途的名称或备注，再保存。不同设备上的控件排列可能不同，应以实际界面为准；关键是确认当前建立的是订阅记录，而不是在某种协议的服务器地址栏中粘贴整段网址。保存前再从头到尾检查一次地址。
订阅地址中的路径和查询参数通常参与身份识别，不能只留下域名。尤其要检查复制时是否带入句号、引号、换行或开头的空格。若地址来自可换行的消息，视觉上的折行不一定是实际换行，不要凭外观手工拼接。更稳妥的做法是复制原始文本，粘贴后检查首尾与关键参数，而不是重新键入一条长地址。
保存后执行一次更新，再查看订阅下是否出现服务器条目。确认数量是否符合已有服务说明、名称是否可辨认、协议字段是否完整。这里不要求得到某个固定数量，因为列表会随账户权限和远端内容变化。如果结果为空，应先查看更新错误或返回内容类型，而不是立即删除现有列表；保留原记录有助于比较地址是否被改动。
建立第一次可重复验证的基线
首次更新完成后，选一个参数明确的服务器作验证对象，记录当时使用的本地网络、Global Routing 状态和测试目标。不要同时更换订阅地址、规则文件和网络环境，否则失败后无法判断是哪一层发生变化。若此前已有可用配置，先保持它不变，只导入订阅并检查列表，这样可以把导入问题与规则问题分开。
某些订阅还会显示额度或有效期等附加信息。这些信息由远端返回，客户端只是呈现数据，不能单凭显示状态推断实际连通性。反过来，没有附加信息也不表示订阅无效。实际判断应以更新是否完成、条目是否可解析，以及已选服务器是否能建立符合预期的连接为依据，必要时再核对已有服务的账户状态。
| 对象 | 负责的内容 | 不能据此推断 |
|---|---|---|
| Subscribe | 获取与更新服务器列表 | 当前连接一定可用 |
| 服务器条目 | 协议、地址、端口与认证 | 规则已经正确匹配 |
| Config | 规则及相关配置 | 订阅凭据仍然有效 |
建议为第一次成功导入留一份简短记录：订阅用途、添加方式、最后一次成功验证所用的环境，以及是否另有手动服务器。记录中不必抄写凭据，可以用本地安全存储的位置代替。以后遇到更新失败时，先按这份基线复查，而不是重置全部设置。关于连接主线的具体操作，可返回使用说明对照执行。
02 / ADD SERVER
Add Server 手填字段与协议核对
先确定 Type，再填通用字段
手动添加适合已经持有完整服务器参数、需要核对单个条目，或需要保留独立测试记录的情况。进入 Add Server 后先选 Type，再填写其他字段。不同协议的字段含义并不相同，不能因为都使用地址和端口就互换类型。改变 Type 后还应重新检查已经填写的内容，避免旧字段残留、认证方式不匹配或可选项恢复默认值。
服务器地址通常是域名或 IP 地址，地址栏一般不应包含网页协议前缀、路径和整段查询参数；端口应放在单独的端口字段。若已有资料提供的是完整分享链接，优先按导入方式处理，而不是拆出一部分随意填写。IPv6 地址中本来就含有冒号，手填时尤其要区分地址本体与端口，不能按照最后一个视觉分隔符猜测。
名称或备注主要用于本地识别，不是认证凭据。可以按用途与来源命名，但不要把密码、完整订阅地址或私钥放进名称。保存后先重新打开条目，核对 Type、地址、端口与认证字段是否仍然一致。输入框出现掩码不代表内容正确，复制粘贴带入的首尾空格也未必容易察觉，应以原始资料为准逐项比对。
协议特有参数必须成套一致
Shadowsocks 需要核对加密方法与密码，二者必须和服务器端一致。VMess、VLESS 等类型则要关注各自的身份字段及传输设置，不能把某种协议的密码概念套到另一种协议上。Trojan 还需要核对认证信息与 TLS 相关设置。这里的目标不是寻找一个通用参数组合，而是忠实还原已有服务提供的那组参数。
TLS 的服务器名称、连接地址与传输层 Host 可能相同，也可能有意不同。连接地址决定首先连接哪里；服务器名称参与 TLS 身份验证；Host 或路径则可能属于上层传输。不要为了让三处“看起来统一”而全部改成服务器 IP。尤其当连接地址使用 IP 时，正确的服务器名称仍可能是域名，必须按原资料保留。
WireGuard 的私钥、公钥、接口地址、对端地址等字段各有用途，不应把一整段配置随意塞进某一个输入框。Hysteria2 的认证与 TLS 参数也需要对应服务器设置，本地网络能否正常使用 UDP 则是另一层条件。关于其传输特征可阅读Hysteria2 与 QUIC 说明，但不能据此省略参数核对。
| 字段组 | 核对内容 | 常见误差 |
|---|---|---|
| 地址与端口 | 连接目标与监听端口 | 把整段网址填入地址栏 |
| 认证 | 密码、标识或密钥 | 漏字符、额外空格、字段错位 |
| TLS | 启用状态与服务器名称 | 用连接 IP 替换验证域名 |
| 传输 | 类型、路径与 Host | 擅自补斜杠或更改大小写 |
保存后按层验证，而不是同时改参数
第一次手填完成后，先检查能否解析服务器域名，再看是否能建立传输连接，最后确认目标请求是否经过预期路径。认证失败、TLS 验证失败与连接超时不是同一种问题。看到超时不应立即换密码，看到认证错误也不应先改规则。若界面提供具体错误，把错误类别和发生阶段记录下来，比只记录“不能用”更有诊断价值。
不建议把关闭证书验证当作通用修复办法。它可能隐藏服务器名称填错、设备时间异常或远端证书异常等真正原因。正确顺序是先核对原资料、设备时间和连接目标，再检查传输设置。只有清楚某项选项的含义、适用范围与风险时才调整，并在测试记录中注明，避免后续把临时诊断设置误认为正常配置。
如果同一服务器由订阅生成，直接编辑它可能在下一次更新时被远端内容覆盖。需要实验时，可在界面支持的情况下保留一个独立副本，写明用途并避免与订阅原条目重名。每轮只改一个字段，测试后决定保留还是恢复。确认手填记录有效以后，再把差异反馈到已有服务参数的核对流程中，不要靠长期维护多个不明副本解决问题。
03 / IMPORT
扫码与剪贴板导入的检查顺序
Scan QR Code 只改变输入方式
二维码只是文本的承载形式，里面可能是单个服务器链接、订阅地址，也可能是普通网页。使用 Scan QR Code 前，先确认二维码对应的是自己的订阅或服务器信息。识别成功只说明文本被读出，不代表内容适用于当前入口，更不表示其中的服务器已经通过连接验证。扫码后应查看识别出的对象类型，再决定是否保存。
调用相机扫码时，系统可能请求相机权限。若此前拒绝过，可在系统的应用权限设置中检查，不必反复重新导入列表。调整拍摄距离、避免反光并保持二维码完整，有助于区分识别问题与格式问题。二维码边缘被裁掉、显示过小或被其他图案覆盖时，识别器可能无法得到完整内容，这与服务器参数是否正确无关。
二维码与应用位于同一台设备上时，可使用实际界面提供的图片识别入口；若当前界面没有相应功能，就复制原始链接，改用剪贴板导入。不要为了完成扫码而把包含凭据的图片传到公开识别页面。对于需要留档的二维码图片，也应按凭据文件管理，不能因为它看起来是图片就当作普通说明截图随意转发。
剪贴板导入先看原文，再确认结果
复制时尽量只选中完整链接，不要连同介绍文字、编号、项目符号或句末标点一起复制。系统询问是否允许读取粘贴内容时，应在确认本次操作由自己发起后再授权。若应用没有读到预期内容，可返回文本来源重新复制一次，并检查是否被后续复制的验证码、搜索词或其他内容替换，而不是立即判断导入功能失效。
批量文本可能包含多条分享链接，但不同来源使用的分隔方式并不相同。不要预设所有带换行的内容都能一次导入。先拿其中一条完整链接验证，确认类型与字段无误后再处理整批。如果导入结果少于预期，检查空行、断行和说明文字，保留原文以便比较；重复点击导入可能只会增加重复条目，并不能修复被截断的链接。
订阅地址导入后应形成可更新的记录，单个服务器链接导入后通常只得到独立条目。若你原本希望以后自动取得列表变化，却只看到一个普通服务器，要重新检查复制的是哪一种对象。反过来，扫描订阅二维码后出现一组条目也不必惊讶，但仍应检查是否保留了对应的订阅记录，不能仅凭列表数量判断导入方式。
按“识别、解析、连接”分开排错
第一层是识别：相机或图片识别能否提取完整文本。第二层是解析：提取出的协议格式能否被当前应用识别，关键字段是否存在。第三层才是连接：服务器是否可达、认证是否通过、请求是否匹配预期规则。如果二维码完全没有响应，应先处理第一层；如果条目已经出现但连接失败，继续换一种扫码姿势通常没有意义。
导入后立即打开新条目的编辑页，重点查看 Type、地址、端口、认证和 TLS 设置。某些链接携带的扩展参数不一定在不同解析实现间完全对应，因此“已保存”不能代替人工核对。已有资料里明确要求的路径、服务器名称或传输方式若没有出现，应先补齐或重新取得正确格式的资料，再做实际连接测试。
对于显示“格式不支持”一类结果，先确认复制的是原始链接，而不是聊天软件包装的跳转页面。不要通过更换协议前缀来强迫导入，也不要删除看不懂的查询参数。参数往往决定 TLS 或传输行为，删除后即使能保存，也可能得到另一条含义不同的记录。格式检查可接着阅读下一章，连接阶段的问题则参照疑难解答。
本次导入完成后，确认新条目归属、删除意外生成的重复记录，并清理不再需要的凭据图片。剪贴板中的敏感文本可用普通无关文本替换，但这不等于抹除了其他设备或应用已经保存的副本。如果曾把完整链接发送到不受控的位置，应按已有服务的管理流程更换相关凭据，而不是仅删除本机的导入条目。
05 / UPDATE POLICY
订阅更新策略与失败回退
更新会改变列表，不只刷新显示
订阅更新是重新向原地址请求数据，并据返回结果刷新相关服务器记录。远端可能新增、移除或修改条目，因此更新不是简单地“再测一次连接”。更新前要区分列表变化与连接状态变化：地址能够成功取得数据，不表示列表中的每台服务器都可用；旧服务器仍能连接，也不能证明订阅地址的认证仍然有效，两条链路可能独立变化。
不要假定手工修改过的订阅条目一定会被保留。远端记录与本地记录如何对应，可能受到名称、标识及应用处理方式影响。需要长期保存的手工调整，应通过独立记录或受支持的本地管理方式保留，并写明它不是远端原始内容。否则下次更新以后，很难判断字段是被覆盖、条目被重建，还是自己选中了另一个同名服务器。
更新前至少知道当前使用的是哪个订阅、哪条服务器，以及是否有可恢复的备份。对于已经稳定工作的环境，不必在所有设备上同时更新。可以先在一台设备上执行，查看变化并完成验证，再处理其他设备。这样既能确认新列表的实际影响，也能在意外出现时保留一个用于对照的原始状态，而不是让所有设备一起失去基线。
按变化频率决定更新节奏
更新频率应服从已有服务的要求与列表变化频率，不是越频繁越好。连续反复请求同一地址，可能遇到远端请求限制，也会让排查记录失去时间顺序。如果界面提供自动更新选项，先阅读其实际含义，确认触发条件与网络要求。移动系统的后台调度还会受设备状态影响，不应把设置了某个间隔理解为绝对准时执行的保证。
手动更新适合首次添加、收到已有服务的变更说明、怀疑列表过期，或需要在维护窗口内控制变化的情况。更新完成后查看条目变化、当前选择和实际连接，不要只看刷新动作是否结束。若原来的条目被移除，应重新选定仍在列表中的记录，再做验证；不能因为名称相似，就默认新记录保留了原来的所有连接参数。
订阅取得数据所走的网络路径，也可能影响更新结果。服务器连接可用但订阅更新失败时，先检查当前本地网络能否访问订阅资源、域名解析是否正常，以及地址是否需要独立认证。切换网络可以作为对照实验，但每次只改变一个条件，并记录结果。不要为了取回列表就随意改动整份 Config，那会把更新链路与业务连接混在一起。
失败先分类，再决定是否恢复
连接超时通常意味着请求没有在允许时间内完成，但原因可能在域名解析、网络路径或远端响应，不能仅凭超时二字确定责任。若返回认证相关错误，应先检查完整地址是否被修改、凭据是否仍有效，以及已有服务是否要求重新生成链接。若返回网页或验证页面，即使网络请求本身成功，客户端也可能无法把它解析成服务器列表。
解析错误与空列表也应分开处理。解析错误可能来自格式变化、内容截断或不支持的字段；空列表则可能是远端确实没有返回可用条目。保留原地址和错误信息，查看已有服务说明，必要时在保护凭据的前提下核对返回内容类型。不要把空结果反复导入其他订阅组，也不要在没有备份时用它覆盖全部现有记录。
更新后只有部分服务器失效时，先比较这些条目的协议、地址和传输方式是否发生变化，再测试列表中其他已知条目。不要因为一条失败就删掉整个订阅，也不要用大批重试掩盖问题。如果新增条目与现有网络条件不兼容，保持可用项并核对原因，比频繁导入同一个订阅更容易得到明确结论。进一步分类可参阅疑难解答。
一次更新应以“列表检查完成并验证关键用途”为结束条件，而不是以刷新动画停止为结束条件。记录成功与失败的阶段，保留必要的回退资料，并确认下一次自动更新不会立即覆盖临时修正。如果凭据已经更换，还应检查自己的其他设备是否仍在使用旧地址，逐台更新，避免把不同设备的旧结果误当成同一次更新的表现。
06 / ORGANIZE
多订阅整理与规则引用
先保留来源边界，再安排显示顺序
同时管理多个已有订阅时，首要目标是知道每条服务器由哪份订阅生成，而不是把全部条目排成一张更长的列表。建议给订阅使用稳定、简短且能区分用途的名称，将来源和用途放在订阅层，将具体差异留在服务器备注中。不要把名称写成不断变化的测试结果，否则下一次更新或排序后，很难用同一名称找到同一对象。
命名可采用“用途—来源代号—补充说明”的结构，其中来源代号由自己约定，不必包含完整域名或账户信息。若两个订阅返回同名条目，先保留它们各自的来源，再判断是否真的重复。名称相同并不代表地址、认证和传输参数相同；名称不同也不代表底层连接目标不同。去重应以关键字段为依据，不能只对照显示文字。
手动服务器应与订阅生成记录明确区分。可以在备注中标明它是独立记录、测试副本还是需要长期保留的条目，并记录何时需要重新核对参数。不要把一个临时修正副本长期当作唯一可用记录，却忘了原订阅还会持续更新。来源清楚以后，才能决定哪些变化由远端维护，哪些变化应由自己负责，减少相互覆盖。
服务器列表与 Global Routing 各司其职
整理列表不会自动改变流量的匹配方式。Global Routing 的配置 Config、代理 Proxy、直连 Direct 是不同的运行姿态：Config 按当前配置决定请求去向，Proxy 用于将通常的业务流量交给所选代理路径，Direct 用于直接连接。具体请求仍可能受系统限制或相关配置影响，排查时不能把这些状态当作完全相同的开关。
如果当前处于 Direct，即使选中一条服务器并整理好顺序，也不能据此断言请求已经经过它；如果处于 Config，则还要查看规则是否把测试目标交给 PROXY。切换状态可以用于对照，但应在完成测试后恢复日常设置。不要为了让某个目标临时可用，就忘记当前已经离开原先的规则分流方式，造成后续判断混乱。
下面的片段是 Shadowrocket .conf 中的规则语法示例，只用于说明顺序与去向，不包含任何服务器凭据。规则通常按先后匹配，前面已经匹配的请求不会再由最后一行重新决定。示例域名没有实际测试意义；将片段加入自己的配置前，应先查看现有规则位置与策略引用，避免重复的最终规则遮蔽后续内容。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY整理过程也需要变更边界
若配置中的策略组引用了具体服务器名称或筛选条件，改名、移动或删除条目可能改变可选成员。整理前先检查 Config 是否存在这类关联，再决定是否统一命名。订阅更新后某个策略组变空，也可能是远端改名导致筛选条件不再匹配，而不是整个订阅失效。应沿着“订阅有无条目、条件是否匹配、策略当前选择”逐层确认。
| Global Routing | 排查时关注 | 整理不能替代的工作 |
|---|---|---|
| 配置 Config | 规则顺序与策略引用 | 验证请求实际匹配结果 |
| 代理 Proxy | 当前所选代理路径 | 验证协议与目标可用性 |
| 直连 Direct | 本地网络直连结果 | 证明已使用某条服务器 |
对于只想减少视觉干扰的条目，先查看界面是否提供筛选或折叠等展示方式，再决定是否删除。删除远端仍然返回的服务器，下次更新后可能再次出现；反复手删并不能形成稳定的维护策略。如果使用名称筛选，需要确认筛选范围，避免误把相似名称的可用条目一并排除，并在远端命名变化后复查结果。
多设备同步整理时，不要把“排列一致”理解为“配置完全一致”。不同设备可能处于不同网络、选用了不同 Config，也可能只有其中一台保留了手动条目。迁移前先列出真正需要一致的内容，例如订阅地址、重要规则和默认选择；本地测试结果与临时排序则不一定需要复制。这样能减少备份体积，也能避免把陈旧状态带到另一台设备。
建议在每次集中整理结束后做三项确认：重要用途仍有明确可选条目，策略引用没有失去成员，备份说明能够解释新的命名方式。不要一次合并、改名、去重和更换规则后才测试；按订阅逐组处理，每组验证完成再继续。只有可解释、可恢复的整理结果，才比原来的长列表更容易维护，而不只是表面上更整齐。
07 / CONNECTIVITY TEST
延迟测试、排序与实际可用性
先确认测试在测什么
Connectivity Test 的结果取决于具体测试方式、测试目标与当前网络环境。某些测试主要观察建立连接的时间，另一些还会涉及经代理访问目标的响应。阅读数字前先确认当前使用的方式，不要把不同方法得到的结果放在同一尺度上比较。一个较小的时间值只能描述那次测试的某个阶段，不能直接代表持续传输速度或全部应用体验。
延迟、吞吐与稳定性是不同维度。网页首次打开受解析和建连影响，大文件传输更受持续吞吐影响，通话或交互又可能对抖动和丢包敏感。测试排序适合缩小排查范围，不适合代替真实用途验证。选择候选条目以后，仍应使用自己的实际业务观察连接是否稳定，不能只因为列表排在最前就长期忽略其他异常。
测试超时也不是单一结论。可能是服务器不可达、测试目标未响应、当前网络限制某类传输，或应用使用的测试方式不适合该路径。若只有测试失败但实际请求正常，应核对测试目标与方法；若测试和实际请求都失败，再检查协议、认证与网络路径。把两种结果分别记录，能避免把测试端点的问题误判为服务器全部失效。
建立可比较的测试条件
对比服务器时，应尽量使用同一设备、同一网络、同一测试方法和同一目标，并避免在后台同时进行大量传输。先选择少量候选条目测一轮，再隔一段时间复测，观察结果是否大致一致。一次偶然的低值或超时，都不足以证明长期质量。尤其在移动网络切换、设备休眠恢复后，应先确认当前网络状态再解释结果。
全列表测试可能同时发起较多请求，测试本身也会占用资源。条目很多时，可先按已有用途或协议筛选，再分组测试，而不是连续反复触发全部检测。正在进行会议、下载或其他重要任务时，不宜把大批测试与实际使用混在一起。若测试后出现短暂波动，先停止重复检测，再观察原有连接，避免把负载叠加误认为远端持续异常。
需要判断本地网络影响时，可以在 Wi-Fi 与蜂窝网络之间做受控对照，但不要同时更换服务器和规则。某个协议只在一种网络下异常，提示应进一步检查网络条件，而不是直接删除该协议的全部条目。Hysteria2 等使用 UDP 的传输尤其要区分本地网络条件与服务器参数，具体思路可参照速度慢的分层排查。
排序是展示动作，不是连接保证
按延迟排序后，先确认当前选中的服务器是否发生变化。显示在首位、处于选中状态和被策略实际使用，是不同的状态；不能只看列表位置判断连接对象。若使用 Config 中的策略组，还应检查组内选择是否引用了另一条记录。排序完成后做一次实际请求验证，并查看相关记录，才能确认业务走向与预期相符。
测试结果会随环境变化，长期保留的数字也可能失去参考意义。设备换了网络、订阅更新了地址或服务器传输设置发生变化后，应重新测试关键候选条目。不要把旧排序当作永久优先级，也不要把远端给出的名称当作性能承诺。用于日常维护的记录应注明测试条件，而不是只截取一个没有上下文的数字。
如果所有条目同时超时，先暂停逐条更换服务器，检查本地网络是否正常、系统连接状态是否建立，以及测试目标是否可达。如果只有某一订阅中的条目失败，则对比其更新状态与共同参数；如果同一协议跨订阅失败，则关注本地网络和该协议设置。按共同特征归类，可以比逐条重建更快地缩小范围，同时保留原始证据。
最终选择应围绕具体用途，而不是追求一个孤立的最小值。保留少量已经在当前网络验证过的候选条目，知道它们属于哪个订阅，并在连接异常时按同样条件复查。不要因为一次测试结果就大量删除记录；先确认问题能否重复出现，再决定是否整理或更新。能够复现的比较，才足以支持长期的维护决策。
08 / BACKUP & RESTORE
删除、备份与恢复验证
删除前先确认对象和影响范围
删除一个服务器、删除整个订阅和删除 Config，影响的对象不同。单个服务器删除后，若它仍由订阅提供，下次更新可能重新出现；订阅记录删除后，其相关列表可能随操作范围一起移除；Config 删除则可能影响规则和其他配置。执行前先阅读确认提示，检查当前选择是否依赖该对象，不要仅凭名称相似就批量处理。
清理重复条目时，先确定重复的依据。两个记录即使地址相同，也可能使用不同端口、认证或传输；两个订阅即使返回相同名称，也可能承担不同用途。对于暂时不确定的条目，先保留并写清备注，比立即删除更稳妥。如果条目被策略组引用，还应先修改引用或确认替代项，否则列表缩短以后，配置中的候选成员可能变空。
本机删除并不等于远端撤销权限。订阅地址若已经泄露，删除应用里的记录不会让他人持有的副本失效；服务器密码或私钥也同理。需要撤销时，应使用已有服务的凭据管理流程，再更新自己所有设备上的记录。本地清理解决的是保存范围问题，远端更换凭据解决的是访问权限问题，二者不能互相代替。
备份要覆盖数据，也要说明范围
备份前先列出需要恢复的对象：订阅地址、独立手填服务器、Config 文件、策略选择，以及不容易重新记住的本地调整。应用提供的导出或备份入口可能覆盖不同范围，不能默认导出一个文件就包含所有内容。查看实际选项与说明，完成后在受控的位置保存，并记录这份备份包含哪些对象、哪些内容仍需手动重新设置。
订阅地址本身可用于重新取得列表，但不能替代手填服务器和规则配置的备份。反过来，一份旧列表即使包含服务器参数，也不能保证今后还能更新到远端变化。完整的恢复计划应同时考虑可重新取得的数据与只能从本地恢复的数据。对原本由订阅生成的条目，不必为了保存显示顺序而制造大量独立副本，避免后续失去维护来源。
备份文件、导出的分享链接和二维码都应视为敏感资料。选择自己可控制的存储位置，限制可访问范围，不把完整文件附到公开求助内容中。若导出入口提供加密或密码保护，应先理解其实际保护范围，并把恢复所需的密码保存在另一个可靠位置。不要把唯一的恢复密码只存在即将重置或更换的设备上。
| 资料 | 恢复用途 | 额外核对 |
|---|---|---|
| 订阅记录 | 重新取得远端列表 | 地址和凭据是否有效 |
| 独立服务器 | 恢复手填参数 | 协议与认证字段是否完整 |
| Config 文件 | 恢复规则与配置 | 策略引用是否仍有对应成员 |
| 维护说明 | 解释命名和临时调整 | 哪些调整应保留或撤销 |
恢复完成以实际验证为准
换机或重装后，先完成应用获取，再按备份范围恢复数据。iPhone / iPad 的应用获取与订阅恢复是两个过程：恢复已购应用不等于服务器资料自动齐全。其他平台也应从全平台下载页进入，再核对备份格式与目标平台实际支持的导入方式。不要假定某个平台的整套备份可以不经检查直接替代另一平台的设置。
恢复时建议先导入 Config 和已有资料，检查对象是否齐全，再按实际依赖顺序处理策略引用与当前选择。如果目标设备已经有部分记录，先备份现状，避免把新旧两套资料无计划地合并。发现同名条目时不要立即批量去重，先比较来源与参数。确认一组内容正确以后再继续，能够减少恢复过程中无法解释的重复和覆盖。
首次恢复后不要立刻删除旧设备上的全部资料。先检查订阅能否更新，手动服务器能否打开编辑页，关键规则是否存在，Global Routing 是否处于预期状态，再完成一轮真实用途验证。系统可能需要重新授权连接能力，这类授权状态不应当作普通备份字段处理；按当前设备提示完成，并在连接后检查实际状态。
恢复测试还应包含一次失败路径检查：如果订阅更新失败，是否仍知道原始资料在哪里；如果某条服务器被移除，是否有其他已验证的选择；如果配置引用失效，是否能找到对应规则与策略。备份的价值不只是文件能够导入，而是在发生变化时仍然知道如何恢复必要功能。仅保存一个文件却不知道包含什么，不能形成可靠的回退方案。
最后清理临时导出文件、过期二维码与不再需要的副本，保留一份当前可解释的维护记录。若曾更换凭据，检查旧备份是否仍含有不应继续传播的信息，并按自己的保存策略处理。日常操作回到快速上手使用说明，具体错误查阅疑难解答；下一次大范围更新、整理或迁移前，再按本章复查备份范围与恢复路径。