Shadowrocket
订阅与节点管理

一、Subscribe：导入已有订阅

先确认输入的是订阅地址

订阅地址指向一份可以重新获取的服务器列表，不等于列表中的某一台服务器。导入后，Shadowrocket 会解析返回内容并建立对应条目；后续刷新则重新读取该地址。因此，准备导入之前，应先确认手中信息究竟是订阅链接、单条分享链接，还是需要手工填写的服务器参数。不要仅凭地址长短判断用途，也不要把浏览器中打开的账户页面当作订阅地址。本文的操作均以已经持有自己的订阅为前提。

订阅链接常带有查询参数，其中可能包含访问凭据。复制时应包含完整协议、路径和参数，避免混入引号、换行、中文句号或聊天界面添加的说明。下面的地址仅用于识别格式，不可用于实际连接。真实地址不宜出现在公开截图、共享笔记或问题描述里；即使它看起来只是一行普通网址，也应按敏感信息处理。

https://example.com/sub?token=xxxx

从 Home 建立 Subscribe 条目

在 Home 中使用添加入口打开 Add Server，选择用于订阅的 Subscribe 类型，再把完整地址填入 URL，并在备注位置写下便于识别的名称。保存前核对地址是否仍然完整，尤其注意末尾参数。不同界面布局下，入口的排列可能不同；应以实际显示的类型和字段为准，不把普通服务器的 Address 栏当作订阅 URL 栏使用。保存后等待获取完成，再返回列表核对结果。

核对时先看订阅组是否出现，再看组内是否有服务器条目，最后抽查一条的协议、地址和端口是否符合已有说明。这三个观察点分别对应订阅对象建立、响应解析和内容正确性，不能互相替代。订阅名称出现，只能证明本地对象已保存；列表有内容，也不等于每个服务器都能连接。首次导入后应保留原有可用条目，等完成连接验证再考虑整理。

分开判断获取失败与连接失败

如果保存后没有服务器，先确认地址是否复制完整，再检查当前网络能否访问订阅地址。若浏览器看到的是登录页面、说明网页或错误提示，返回内容就可能不是可解析的服务器列表。浏览器能显示文字也不足以证明格式正确，遇到异常应核对自己的订阅说明，不要反复修改协议类型试图让网页内容变成节点。错误发生在获取阶段时，先处理地址和响应，暂不调整服务器加密参数。

如果条目已经出现但无法连接，则进入服务器字段和网络可达性的排查。订阅可能成功返回了过期条目，也可能有个别条目缺少必要参数。此时记录订阅组名称、失败条目的协议和错误发生阶段即可，不必公开完整链接。批量条目均失败与单条失败的检查路径不同：前者先看共同网络与列表内容，后者优先比较该条目的独有设置。

管理上建议为每个订阅保留一份本地记录，注明用途、原始地址的安全存放位置和手动调整情况，而不是把地址写进公开备注。这样在后续更新或换机时，可以判断某条记录来自订阅还是手工创建。若发现重复订阅，不要立即删除其中一组；先比较两组地址和内容，确认是否只是备注不同，再按第八章的顺序处理。

二、Add Server：手填字段与协议参数

先选 Type，再填写公共字段

手工添加适用于已经持有完整服务器信息、需要逐项核对字段的情况。进入 Add Server 后先选择 Type，因为不同协议会显示不同参数；类型选错时，即使地址和密码看似正确，也无法组成有效连接。不要仅凭端口号猜测协议，端口不是协议标识。同一地址也可能承载不同服务，必须以已有服务器配置为依据，把协议、端口、认证方式和传输设置作为一整组信息核对。

公共字段中，Address 通常填写服务器域名或地址，Port 填写服务器实际监听端口，备注只负责帮助识别。除非字段明确要求完整网址，Address 不应夹带网页路径或整段分享链接。粘贴完成后检查开头和结尾的空格，端口不要混入冒号。密码、标识符等凭据要保持原样，大小写、连字符和特殊字符都可能影响认证；不能为了便于阅读自行替换或补全。

按协议核对认证与传输

Shadowsocks 需要匹配的加密方法和密码，不能把另一个协议的认证信息直接填入。VMess 与 VLESS 的标识符字段可能看起来相近，但协议含义并不相同；应分别核对已有配置中的认证、传输与安全设置。Trojan 常与 TLS 设置一起使用，不能只填密码就忽略证书名称相关要求。Hysteria2 也应按已有信息核对认证和 TLS 参数，不根据协议名称自行推断服务端配置。

WireGuard 的配置包含密钥、对端与网络范围等不同含义的参数，不适合用普通“地址加密码”的方式理解。导入或填写时应区分本地私钥与对端公钥，私钥不能用于公开排查。对于 HTTP、SOCKS5，也要确认服务器是否要求用户名和密码，以及所填的是哪一种协议。本文列出的协议只用于字段辨认，不表示可以用相同的一套参数在这些类型之间切换。

保留安全校验，单项修改后再测试

TLS 的证书校验名称与服务器连接地址可能不同，SNI、Host 和 Path 也不能合并成一个“域名设置”理解。遇到认证失败，应分别核对连接目标、传输入口和证书身份。不要把关闭证书校验当作常规修复方案，也不要在不了解用途时添加额外传输参数。若已有服务器说明未提供某个可选字段，先保留合理默认值，再核实该字段是否确实需要填写。

保存后先单独选中这条手工记录进行测试。若需要调整，建议一次只改一类字段，并记录修改前后的结果；同时改密码、端口、传输和规则，会让失败原因难以定位。对订阅生成的条目进行编辑前还要判断改动是否会被刷新覆盖。需要长期保留的本地实验，可以在界面提供复制能力时建立独立记录，并用明确备注区分；不要依赖订阅条目的临时修改长期生效。

手填记录成功连接后，也要确认使用的是预期条目，而非先前仍在工作的连接。可以断开后重新选择、连接，再访问自己有权使用的目标服务进行验证。若仍有字段疑问，先回到原始服务器信息逐项比对；常见问题的分类路径见FAQ，不要以随机组合参数替代核对过程。

三、Scan QR Code：扫码与剪贴板导入

扫码只是输入方式，不是配置类型

二维码可以承载单条分享链接，也可以承载订阅地址或普通文字。使用 Scan QR Code 前，先确认二维码对应的是自己已有的配置，并判断预期导入结果是一条服务器还是一组订阅。扫描成功只代表识别到了文本，不代表协议字段完整，更不代表服务器已经通过连接验证。识别结果与预期不同的时候，应先检查内容类别，而不是立刻保存并打开连接开关。

在应用中打开 Scan QR Code，按系统提示决定是否允许相机访问。把完整二维码放入取景区域，避免边缘裁切、反光和过度缩放。对于保存在当前设备上的二维码，只有在实际界面提供相册识别入口时才使用该入口；不应假定所有布局都在同一位置提供相同操作。图片应来自自己保存的原始资料，尽量避免经过多次转发、压缩或拼接后的模糊副本。

识别后若进入参数预览，应先核对 Type、地址、端口和备注，再确认保存。二维码可能把多项信息编码在一起，因此不能只看备注熟悉就认为内容正确。备注是便于辨认的标签，不是服务器身份校验。扫描得到订阅 URL 时，应按订阅流程建立并获取列表；扫描得到单条协议链接时，则按服务器导入流程处理。两者在后续更新能力上有明显差别。

剪贴板导入前先清理文本边界

复制分享链接时，尽量只选择链接本身，不把说明文字、编号、列表符号或引号一起复制。打开 Shadowrocket 后，若出现读取剪贴板或导入内容的提示，先确认来源和预期，再执行导入；若没有出现提示，可以使用当前界面提供的相应导入入口。系统的剪贴板权限会影响读取流程，未出现导入提示不能直接解释为链接失效，也不宜反复复制其他敏感内容进行试验。

剪贴板中的多行内容需要特别检查。一段订阅响应可能包含编码后的整组条目，而聊天记录也可能只是把多条链接拼在一起，二者不一定由同一个入口处理。若批量导入未能识别，先取一条完整且明确的分享链接验证解析，再核对原始内容格式。不要在不清楚编码层次的情况下反复解码、加换行或替换特殊符号，这些操作可能破坏原本有效的内容。

保存后完成一次导入验收

导入验收至少包含三步：在 Home 确认新增对象，在详情中抽查关键字段，再进行连接验证。如果二维码识别成功但没有新增对象，先检查是否进入了尚未保存的编辑页，或是否导入为订阅组而不是独立服务器。若原有列表较长，可以通过刚设置的备注定位，不要连续重复扫描制造多个难以区分的副本。重复导入通常不会修复同一份内容的参数问题。

当识别失败发生在保存之前，重点检查图片完整性、协议前缀和文本格式；当保存成功但连接失败，重点转向认证、传输和服务器可达性。这个分界有助于缩小排查范围。对于经过他人重新排版的链接，可与自己安全保存的原始资料比对，尤其留意全角符号、自动断行和末尾片段。复制界面显示的短文本，不一定等于复制了完整目标内容。

完成导入后，妥善处理临时截图和剪贴板记录。如果二维码或链接已经在不受控范围内暴露，应按原有服务的凭据管理流程更换相应信息；仅在本机删除导入条目，不能让已暴露的凭据自动失效。更多格式辨认可继续阅读下一章，遇到系统授权问题则先按首次连接教程检查授权环节，避免把权限问题与导入问题混在一起。

四、分享链接：格式与配置边界

先看前缀，再看内容对象

分享链接把协议参数装入一段可复制文本，目的是减少手工输入错误。常见前缀包括 ss://、vmess://、vless://、trojan:// 和 hysteria2://。这些前缀帮助应用选择解析方式，但不能单独说明全部传输与认证细节。单条分享链接通常描述一条服务器记录；订阅 URL 则用于重新获取一组记录。把单条分享链接保存下来，不会自动获得订阅列表的持续更新能力。

不同格式可能使用编码后的认证信息、查询参数以及井号后的备注。编码是表示方式，不应当成保密措施；持有完整链接的人通常也能取得其中参数。某些链接包含百分号转义，备注中的中文也可能被编码。排查时先保留原始文本，不要为了让字符串“看起来正常”就手动去掉等号、百分号或连接符，也不要把末尾备注误当成密码的一部分。

参数兼容不等于内容完全相同

同一种协议的链接可能采用不同字段表达方法，导入程序也未必支持每一种可选参数组合。判断导入是否完整，要看导入后的字段，而不是仅看是否弹出成功提示。尤其是传输类型、TLS、SNI、Host、Path 等配置，遗漏后可能仍然生成服务器条目，却无法建立预期连接。若原始链接带有额外参数，应逐项确认应用是否识别，不把陌生字段随意映射到名称相近的选项。

通过分享链接导入一条记录，通常不会同时替换整份 Config。服务器决定连接到哪里，规则决定哪些请求使用哪种策略，二者需要配合。Global Routing 的配置姿态 Config 会结合当前规则处理请求；代理姿态 Proxy 与直连姿态 Direct 的行为不同。排查时先确认当前姿态，再判断是否需要检查规则，避免把规则导致的直连误认为服务器分享链接没有生效。

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

上面的片段说明规则与服务器记录的分工，不是一份完整配置建议。DOMAIN-SUFFIX 按域名后缀匹配，GEOIP 根据地址所属区域判断，FINAL 承担最终兜底；规则顺序会影响命中结果。PROXY 和 DIRECT 是策略关键字，不是服务器密码，也不应填入 Add Server 的认证栏。实际使用前应理解规则覆盖范围，再在现有 Config 中检查相应位置。

分享时明确导出的范围

准备分享或保存资料时，先确认导出的是单条服务器、订阅地址，还是规则配置。三者恢复后产生的结果不同：服务器链接重建连接参数，订阅地址重新拉取列表，规则文件恢复请求处理逻辑。只备份其中一种，不能据此认定整个使用环境都能恢复。接收方若只需要排查规则，应提供经过脱敏的相关规则片段，而不是把完整连接凭据一并交出。

对格式有疑问时，可阅读分享链接与订阅链接的区别，再回到原始资料确认输入对象。不要将分享链接改写为普通网页地址，也不要把 HTTPS 订阅 URL 强行加上某种协议前缀。格式转换只有在明确知道字段含义且目标格式支持这些字段时才有意义；手工替换前缀不会完成协议转换，反而容易制造难以察觉的参数丢失。

五、更新策略：刷新与失败处理

先理解订阅刷新会改变什么

订阅刷新是重新获取服务器列表，不是给当前连接增加速度，也不是更新应用本身。远端列表发生变化后，刷新可能新增条目、移除条目、调整名称或替换参数。与订阅关联的本地修改也可能被远端内容覆盖。因此，在重要条目上改过备注、端口或传输设置之后，不应把这些改动视为永久保存；更新前先记录必要差异，再决定是修正原始配置还是保留独立的手工记录。

日常使用可以先执行一次手动刷新，观察是否出现明确错误，再检查列表变化。订阅相关操作可能通过列表手势或编辑入口提供，应以当前界面显示为准。刷新完成后不要只看提示消失，还应核对订阅组和原先选中的条目。如果当前服务器被移除或名称改变，应重新选择有效记录，再检查连接状态。刷新列表与切换正在使用的连接不是同一项操作，不能假定两者总会同步完成。

自动更新应服务于实际使用频率

自动更新相关选项应在应用实际提供的订阅设置中查看。打开应用时触发的更新，不能理解成应用在所有后台状态下都会按精确间隔执行。系统调度、网络状态和应用运行状态都可能影响触发时机。如果需要在一次重要使用前确认列表有效，手动检查比推测后台是否已刷新更直接。不要凭订阅名称中的日期判断最近一次获取是否成功，名称本身可能只是固定文本。

频繁刷新也不等于提高可靠性。相同地址在短时间内连续请求，可能遇到网络波动、远端访问限制或缓存响应。合理做法是先获取一次，若失败则读取错误并判断阶段，而不是不断点击直到出现不同结果。自动更新后出现问题时，记录是“获取失败”“列表变化”还是“连接失败”，三者对应的处理方式不同。对重要的本地条目，保留安全备份比缩短刷新间隔更有价值。

按地址、网络与内容三层排查

第一层检查地址：确认原始链接未被截断，查询参数仍然完整，且没有把订阅地址替换成了网页入口。链接包含敏感参数时，不要通过公开在线工具检测；可以在本地比对原始文本。若凭据已经更换，旧地址可能仍保存在本地，单纯重新打开应用不会让它自动变成新地址。只有确认新旧地址关系后，才修改原有订阅对象，避免把两个用途不同的订阅混为一谈。

第二层检查网络：当前连接能否访问订阅服务器，与导入后的服务器能否连接，是两个独立问题。若错误表现为超时或域名解析失败，可在另一条自己可用的网络下复测，并保持地址不变以便对比。不要一边更换网络一边修改链接和规则，否则无法判断是哪项变化起作用。若怀疑当前路由影响获取，应先记录现有设置，再谨慎验证，不把临时切换当作长期配置。

第三层检查内容：请求返回成功不等于返回了有效列表。远端可能给出错误说明、登录页面、空内容或不适用的格式。此时应保留已有可用列表，不要为了“清空重来”先删除全部条目。核对原有服务说明中的格式要求，并记录经过脱敏的错误类型。若只有一组订阅异常，优先检查该组地址和响应；若所有组同时异常，再看共同网络条件与应用状态。

更新成功但使用结果改变时，先查看服务器是否被替换，再核对选中项与 Global Routing，最后才检查规则和目标请求。保存问题发生前后的简短记录，可以减少重复试验。更多手动刷新与打开时自动更新的说明见订阅更新方法；需要回溯参数时，使用第二章的字段核对顺序。

六、多订阅整理：分组与命名

把来源关系与使用用途分开记录

管理多个已有订阅时，最重要的不是把列表缩短，而是能回答每条记录从哪里生成、更新时会发生什么、当前连接选中了哪一条。订阅组承担来源关系，服务器备注承担条目辨认，本地记录承担修改说明。不要把这三件事全部挤进一个冗长名称，也不要为了统一外观而把所有组都改成相同名字。名称相同会增加误选风险，地址相同则可能表示重复对象，两者需要分别核对。

建议先为订阅使用稳定、简短的用途名称，再在自己的安全记录中保存原始地址和变更说明。服务器名称可沿用原有标签，并对独立手工条目增加容易辨认的本地标记。备注不要包含完整密码、私钥或订阅令牌；备注会出现在列表、截图及导出内容里，不适合承担凭据存储功能。名称也不应写成固定性能承诺，某次测得的快慢不会永久成立。

重复条目先辨认，再合并

两条记录使用同一域名和端口，不一定完全重复，它们可能具有不同认证、传输、安全或分流用途。反过来，两条名称不同的记录也可能指向同一套参数。整理时应先比较协议和地址，再比较认证与传输字段，最后确认所属订阅。凭据比对应在本地完成，不要复制到公开文本。只有确认记录的含义一致，并且清楚后续更新关系时，才考虑保留其中一个对象。

如果重复来自同一订阅的多次导入，优先比较订阅 URL，而不是逐条删除服务器。重复建立的订阅组可能在下次刷新后再次产生相似列表。处理前先确定哪组是当前使用对象，再备份所需资料，最后删除多余组。若只是同一组内名称相近，则应核对远端列表本身，不要为了让界面整齐而删掉可能仍有用途的不同参数记录。

选中项、排序与策略分别检查

列表顺序变化，不等于当前连接已经切换。手动排序、测试后排序和重新导入，都可能改变条目的显示位置，但使用者仍需确认实际选中项。对长列表进行整理时，可以先记录当前订阅组与服务器名称，整理后重新核对。若远端更新更改了名称，还要结合协议和地址判断，不能只按记忆中的列表位置点击。位置适合浏览，不适合作为稳定标识。

Global Routing 的配置姿态 Config、代理姿态 Proxy、直连姿态 Direct 也不应与订阅分组混淆。分组解决列表管理，路由姿态解决请求如何处理。一个订阅组内有很多条记录，不表示应用一定按你的用途自动选择；仅把组命名为某类用途，也不会改变规则行为。需要指定请求处理逻辑时，应检查当前 Config 的规则与策略，而不是依靠备注名称产生效果。

对临时测试条目，建议设定清理条件：完成问题复现且已有安全记录后再删除，不能仅因一次延迟较高就认定它永久失效。长期不用的订阅也应先确认恢复材料是否完整。整理动作尽量分批进行，每批完成后核对一次当前连接与剩余组，避免一次删除、重命名和重导入过多对象，导致问题出现后无法判断对应操作。

iPhone 与 iPad 上可以沿用相同的命名规则，但两台设备的本地选择、排序或测试结果应分别检查，不要仅凭名称一致就认定运行状态一致。应用购买与设备说明见iPad 获取说明，配置迁移则按第八章单独验证。这样可以让名称保持可辨认，同时承认不同设备的网络条件和本地状态可能不同。

七、Connectivity Test：延迟与排序

先理解测试读数代表哪一段

Connectivity Test 用于观察某项连接测试的结果，读数必须结合测试方法解释。不同测试方式可能反映目标可达性、连接建立或经由服务器访问测试目标的耗时，不能把所有数字都理解为完整业务请求的响应时间。执行前先查看实际采用的测试方式和目标，比较时保持方法一致。一次读数较低，并不证明下载速度更高，也不证明对所有网站都有相同表现。

测试结果还会受到当前网络、域名解析、服务器负载、测试目标响应和超时设置影响。相同条目在不同网络下出现不同结果是可能的，不能只比较两次测得的数值而忽略条件变化。批量测试时也可能产生并发请求，结果与单独测试不完全相同。实用的做法是先在稳定网络下完成一轮筛查，再对准备使用的少量条目分别复测，并用真实需求验证。

按统一条件测试，再决定排序

测试前先完成订阅更新，避免测试过程中列表又被刷新。确认正在使用的网络与测试方法后，选择需要比较的范围；大列表可以分组测试，不必每次都测试全部记录。测试结束先辨认有效结果与超时结果，再决定是否排序。若应用提供按测试结果排序的操作，可以将它用于临时筛选，但应保留清楚的名称，避免排序后只能靠位置寻找条目。

延迟排序适合缩小候选范围，不适合直接替代连接选择。某条记录对测试目标响应较快，仍可能在你实际需要的服务上表现不同。选定候选条目后，明确选中它，检查 Global Routing，再完成连接并访问自己的目标服务。若测试通过但业务失败，下一步应检查规则、域名解析和目标返回，而不是仅反复更换列表中数字最小的记录。

把失败分为单条、整组与目标差异

单条失败时，先核对它的地址、端口、认证和传输设置，并与同组正常条目比较共同点和差异。整组失败时，先看当前网络能否访问相关地址，再看订阅内容是否发生变化。所有组均失败时，还要检查测试方式和测试目标本身是否适合当前环境。这个顺序能够减少误删：共同条件未确认前，不应把每一条记录都单独判断为参数损坏。

如果测试目标可以响应，而实际目标不能访问，应确认请求是否经过预期路径。Config 中的 DOMAIN、DOMAIN-SUFFIX、GEOIP 和 FINAL 等规则会影响匹配结果；当前处于 Direct 时，服务器测试成功也不会使普通请求自动改为代理。可以借助应用实际提供的连接或日志信息确认策略，但应对域名、地址和凭据进行脱敏，再保留与问题有关的最小片段。

对需要比较的候选条目，可以在相近时间、同一网络、相同测试方式下重复少量测试，关注结果是否稳定，而不是从许多次测试中只挑最好看的一个数字。连接建立成功后，再观察实际任务是否完成。不要用持续批量测试代替日常使用验证，也不要把测试造成的流量与后台活动忽略。出现耗电疑问时，可参考后台耗电与 On Demand 的取舍。

最终应保留的是可解释的选择依据：在哪种网络、用什么测试、访问什么目标、当时得到什么结果。它比一个脱离条件的排序截图更有排错价值。对临时超时的记录先保留观察，只有确认不再需要且已掌握恢复方式后，再进入删除流程。测试负责提供证据，删除属于配置管理，不应由一次失败自动决定。

八、删除与备份：恢复材料与迁移验证

删除前先确认对象范围

删除操作前先辨认对象是独立服务器、订阅生成的条目、整个订阅组，还是 Config。删除独立条目通常意味着移除本地参数；删除订阅组则可能同时影响该组及其关联列表。具体确认提示应逐字阅读，不凭手势习惯快速确认。若只删除订阅生成的一条服务器，后续刷新仍可能再次从远端生成；这与删除整个订阅对象有本质区别，应先明确真正需要清理的范围。

当前连接依赖的条目被删除后，不应假定连接状态和后续选择会自动符合预期。进行整理前可以先记录当前条目，再断开连接，完成删除后重新选择并验证。若只是为了隐藏一条暂时不使用的记录，应先查看当前界面是否有合适的管理方式，不把不可恢复的删除当作唯一整理手段。对不清楚后果的组，先保留，等备份完成再操作。

分层准备恢复材料

可靠备份应分别考虑订阅地址、手工服务器参数和规则配置。订阅地址有助于重新获取列表，但不能保证远端内容永远与当前相同；单条分享链接有助于重建服务器，却未必覆盖全部应用设置；Config 保存规则逻辑，也不等于完整保存了连接凭据。备份前列出自己实际使用的对象，再确认每类都有可恢复材料，而不是看到一个导出文件就认为所有内容已经齐全。

如果当前界面提供分享、导出或备份入口，先阅读其范围说明，再按需保存。对于不能确认是否包含的字段，可打开导出结果在本地核对，或在保留原对象的前提下做恢复试验。手工记录尤其要检查认证、TLS、传输和特殊字段是否完整。不要把仅供辨认的备注或测试截图当作参数备份，也不要只记录地址和端口而遗漏认证信息。

保存备份时，可以附带不含凭据的说明，写清对象用途、导出范围、当前规则选择和必要的手工差异。资料应具备可辨认性，但不要在文件名中暴露密码或令牌。若使用自己信任的存储方式，应同时考虑设备遗失、访问权限和过期副本清理。加密保存有助于保护内容，但恢复所需的访问方式也应妥善保管，避免备份存在却无法读取。

换机或重装后逐层恢复

应用本身通过 App Store 获取；已购项目与账户说明见已购恢复指南，系统要求与是否通用购买以 App Store 页面标注为准。应用能够重新获取，不等于订阅、手工节点和 Config 已自动恢复。打开新设备后先检查现有内容，再决定导入哪些材料，避免在已经恢复部分数据的情况下又整组重复导入。

恢复建议按订阅、独立服务器、Config 和连接验证的顺序进行。每完成一类，确认条目与字段，再继续下一类。订阅重新获取后列表可能已经变化，要核对选中项；独立记录恢复后检查关键参数；规则恢复后确认当前使用的配置与 Global Routing。随后按系统提示处理 VPN 配置授权，进行一次实际连接验证，不把“列表出现”当成迁移结束。

在新设备验证成功之前，保留原设备上的资料和备份。若新旧设备结果不同，先比较网络条件、所选条目和路由姿态，再核对参数，而不是立刻覆盖全部数据。需要回退时，应依据之前记录的对象范围恢复，防止旧 Config 覆盖新修改，或旧订阅重复生成列表。迁移过程中尽量一次只改变一层，使每一步都能解释和复现。

最后检查备份是否仍然适用于当前状态：凭据更换后旧副本可能失效，规则修改后旧文件可能不再表达预期用途。完成更新后安全清理不再需要的敏感副本。删除本地记录或文件，只影响自己的副本，不会自动撤销已经暴露的凭据；如有暴露，应按原有服务的凭据管理流程处理。后续日常操作可回到快速上手教程，具体错误则按FAQ 分类继续定位。