Shadowrocket
订阅与服务器管理

Subscribe：建立订阅与记录的关系

订阅是一个用于获取服务器信息的远程地址，不是某台服务器本身。Shadowrocket 请求该地址、读取返回内容后，将其中能够识别的项目显示为服务器记录。因此，订阅地址能打开、列表能出现、服务器能连接，是三个不同的检查点。远程内容也可能改变；今天导入的名称、数量与排列，不能代替下一次更新后的检查。开始操作前，先确认手里拿到的是供 Shadowrocket 使用的订阅地址，而不是介绍页面、账户页面或单台服务器的分享链接。

从 Home 添加 Subscribe

在 Home 使用添加入口，进入 Add Server 后，在 Type 中选择 Subscribe，再填写订阅 URL 与便于识别的名称。入口文字或排列若随应用界面调整，以实际显示为准，操作对象始终是 Subscribe 类型的记录。将完整地址放入 URL 字段，不要把它写在服务器 Address 中。保存前核对开头、结尾和查询参数，尤其注意复制时夹带的空格、换行、中文标点以及聊天文本中的说明句。

名称只用于本地辨认，建议表达用途或来源，例如“个人常用订阅”，不要把完整地址放进名称。带认证参数的 URL 相当于访问凭据；别人拿到后可能读取你的服务器信息。输入完成后保存，并观察订阅读取的结果：是否出现所属记录，是否有明确错误提示，记录类型是否符合预期。首次获取可能受当前网络、订阅地址有效性和远端响应影响，保存动作本身不等于读取成功。

分别检查入口、响应与内容

列表为空时，先回到订阅记录检查 URL 是否完整，再区分请求失败与解析失败。请求失败通常需要检查本地网络、域名解析、远端可达性或认证状态；解析失败则可能是返回了网页、登录提示、错误文本，或者返回格式与当前导入方式不匹配。不要因为列表为空就随意修改协议字段，也不要用删除所有旧记录作为第一步。保留当前仍可使用的记录，才能在检查过程中维持可恢复的状态。

若地址里含有很长的查询参数，应与自己的原始资料逐段比对，而不是只看域名相同。远程地址可能通过参数区分账户、格式或访问权限，缺少一个字符也可能得到完全不同的响应。需要向自己的服务商反馈时，描述错误类型、发生步骤和网络环境即可；提交截图前遮住 URL、认证参数和服务器凭据。没有必要为了说明“导入失败”而公开完整订阅内容。

订阅不是 Config

Subscribe 主要解决服务器记录从哪里读取；Config 主要决定配置规则与相关设置如何组织。只有服务器列表，并不意味着已经具备适合当前用途的分流规则；有规则文件，也不意味着已经填写可用的服务器。导入成功后，应回到 Home 确认实际选中的服务器，再检查 Global Routing。日常按规则处理流量时使用配置姿态 Config，但还需确认当前启用的配置内容，不要仅凭姿态名称判断请求一定经过哪条路径。

最后用一个明确的网页请求验证实际连接，而不是仅观察列表出现。连接开关、服务器选择和请求路径的完整操作见入门指南。若订阅已成功读取却仍无法访问，应转到测试与排序一章按层检查，避免把服务器连接问题误判成 Subscribe 导入问题。

Add Server：逐项核对手填字段

Add Server 适合录入已有的单台服务器信息，也适合在订阅之外保留少量需要独立管理的记录。手填前应拿到一组完整参数，而不是仅有地址和端口。不同协议对认证、加密、传输与 TLS 的要求不同；不能因为字段名称相似就沿用上一条记录。先选择正确的 Type，再按提供给你的参数逐项填写，通常比先填地址、最后改协议更容易检查，也能避免忽略协议切换后新增的字段。

基础字段与认证信息

Address 表示服务器连接目标，通常填写域名或 IP 地址；Port 表示服务监听端口，应单独填写数字。除非字段明确要求 URL，否则不要在 Address 中附加网页路径或整段分享链接。Password、UUID 等认证字段应保持原值，大小写、连字符和末尾空格都需要注意。Remarks 用于本地名称，不参与认证，可写成“用途－协议－标记”的形式，便于以后区分相似记录。

协议字段不能互相代用

Shadowsocks 需要匹配认证信息与加密方法；VMess、VLESS 通常还需核对身份标识及对应传输设置；Trojan 应检查认证与 TLS 相关要求；Hysteria2 需核对其自身认证和连接参数；WireGuard 则涉及密钥、地址与对端等独立配置结构。这些名称只说明协议类别，不代表两条同协议记录拥有相同的附加字段。遇到资料缺失时，应补齐原始参数，不要通过反复切换选项猜测可用组合。

TLS 名称、HTTP Host 与服务器 Address 可能相同，也可能不同，三者不能仅因都是域名而合并理解。Address 用于找到连接目标；SNI 与证书身份验证相关；某些传输中的 Host 或路径用于匹配服务端入口。若服务端明确提供了这些字段，就按资料保留。连接失败时应先逐项对照，而不是降低证书检查要求来掩盖名称错误；参数错误与证书异常需要分别查明。

保存后先做最小验证

保存一条记录后，回到 Home 确认它确实存在，并检查选中标记是否落在这条记录上。若同时保留多条名称相似的服务器，单看屏幕上的名称容易误认，可进入详情复查地址末段、协议和备注。先测试新记录，再尝试实际请求；不要一次新增许多近似条目后再集中排错。每次只改变一个字段，并记下改变原因，才能判断是认证、传输还是本地网络导致结果变化。

手工记录通常由用户自行维护，不能假定订阅更新会替它修正参数。反过来，订阅生成的记录即使允许编辑，下一次更新也可能按远端内容重建，局部修改未必长期保留。如果确实需要独立调整，可在确认保存机制后另存一条可辨认的手工记录，并明确它与原订阅的关系。不要把重复名称视为备份；备份需要保留完整参数和恢复方式，而不是仅保留列表中的另一个标题。

当单条记录始终失败、同一网络下其他记录正常时，优先复查这条记录的协议与认证资料。若所有记录同时失败，则应检查网络环境、连接状态和实际请求路径。把问题限定在最小范围，通常比持续新增或删除服务器更有效。

扫码与剪贴板：导入前辨认载荷

Scan QR Code 与剪贴板导入只是输入通道，不决定输入内容的含义。一个二维码可能包含单台服务器分享链接，也可能包含订阅 URL，甚至只是普通说明文字。剪贴板也可能同时夹带标题、提示语和多段地址。因此，导入前先确认载荷类别：这是需要持续更新的订阅，还是一条独立服务器记录；随后再选对应入口。把普通网页地址作为服务器导入，或者把服务器链接当作 Subscribe URL，都会造成后续行为与预期不一致。

Scan QR Code 的检查顺序

在 Home 找到扫描入口并使用 Scan QR Code，首次调用相机时按系统提示决定是否允许访问。相机权限只是用于读取二维码，并不等于已经授权网络连接。扫描时让二维码完整进入取景范围，避免反光、过度倾斜与图像模糊。识别到内容后，先看出现的是服务器详情、订阅信息还是其他提示；若有确认步骤，检查协议、备注和地址是否与自己的资料一致，再保存。

当二维码位于同一台设备的图片中，若当前扫描入口提供从照片读取的选项，可选择对应图片；如果没有该选项，则回到原始资料复制文本，不必反复拍摄屏幕。读取失败首先应考虑清晰度、边缘缺失、图片压缩与内容长度，而不是直接认定服务器不可用。一个二维码在光学识别阶段尚未转换成参数，网络连通性还没有参与这个过程，二者应分开排查。

剪贴板只保留需要的完整文本

复制时尽量只选中一条完整链接，避免把项目编号、引号或结尾标点一并选入。返回 Shadowrocket 后，若出现剪贴板访问或导入提示，核对来源后再继续；也可使用当前界面提供的导入入口。系统询问是否允许粘贴时，按这次操作的需要决定。没有出现提示并不一定是应用故障，可能是剪贴板内容不完整、格式未识别，或当前系统权限与操作路径不同。

若导入后没有新记录，先检查是否已经存在相同项目，再检查文本是否只包含说明句。不要为了触发提示而连续复制不同内容，这会覆盖原始资料。遇到一段同时包含多条分享链接的文本，应先保留原始副本，再分批导入和核对结果。批量导入成功与每条参数正确也不是同一件事，至少需要抽查协议类别、名称和所属分组，重要记录则逐条验证。

授权、保存与连接是不同步骤

相机、照片和剪贴板权限与首次建立 VPN 配置的系统授权各有用途。导入过程只是在设备中新增参数；真正启用连接时，系统可能请求允许添加 VPN 配置。是否已经导入不能仅看系统顶部状态，也不能仅看 Home 开关。保存完成后先确认记录位置，再选择服务器、检查 Global Routing，最后发起实际请求。这样可以在出现错误时判断问题发生在哪一阶段。

成功导入之后，可清理剪贴板中仍保留的敏感内容，并按自己的资料管理习惯处理二维码图片。需要保留恢复资料时，应使用受保护的位置，而不是长期放在公开相册、共享笔记或聊天群中。删除剪贴板副本不会撤销已经暴露的凭据；如果怀疑泄露，应在对应服务管理端更换凭据，再更新客户端记录。

若同一段资料在不同输入方式下得到不同结果，比较实际被识别的文本，而不是只比较二维码外观。换行、编码和遗漏字符可能来自复制或识别过程。可将问题拆成“能否读出文本”“能否解析记录”“能否建立连接”三个检查点，逐一确认。

分享链接：区分协议、编码与配置

服务器分享链接是一种参数载体，通常由协议标识开头，再带有认证、连接地址、端口及附加参数。Subscribe URL 则是读取远程内容的位置，两者可能都以链接形式出现，但用途不同。识别格式时先看整体结构，不凭名称中的协议缩写做判断。一个看似普通的 HTTPS 地址可能是订阅入口，也可能只是网页；一个协议链接可能只代表单台服务器，不会因为被命名为“订阅”就自动获得更新能力。

前缀帮助分类，不能证明有效

常见协议分享前缀包括 ss://、vmess://、vless:// 与 trojan://。前缀用于提示解析方式，不足以证明后面的字段完整，也不足以证明当前客户端接受其中每一个扩展参数。部分格式会把内容编码后放在链接中，部分格式使用查询参数描述传输和 TLS。应优先使用已有资料原样导入，再在详情中检查解析结果，不建议凭记忆拼接一条正式记录。

编码后的长字符串不是安全加密。它可能只是把认证与配置转换成便于传输的文本，拥有链接的人仍可能恢复其中的信息。链接尾部的备注通常用于展示，备注改变不等于认证改变。查询参数里的字符也有语法意义，例如分隔符被删除或错误转义后，应用可能读到不同字段。不要用文本替换批量“整理”整个链接，更不要把看不懂的参数当成多余内容删掉。

规则文件与服务器链接的边界

Shadowrocket 配置文件按段落组织；下面片段只演示真实规则语法，不包含服务器认证信息，也不是完整的个人配置。规则自上而下匹配，FINAL 放在末尾用于处理前面未命中的请求。示例里的 PROXY 与 DIRECT 表示规则处理方式，不能作为填写 Password 或订阅 URL 的替代内容。导入服务器后仍需检查当前配置，不能把规则文本粘贴进 Add Server 的地址字段。

[General]
bypass-system = true

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

使用配置姿态 Config 时，实际请求由当前配置规则决定；使用代理姿态 Proxy 或直连姿态 Direct 时，处理方式不同。因此，测试某条服务器前应确认 Global Routing，避免因请求实际走了 Direct 而误以为选中的服务器已经通过验证。三种姿态的详细解释见Global Routing 选择说明。理解这层关系，有助于区分“记录解析正确”和“请求路径符合预期”。

格式不匹配时保留原文

若出现无法识别、字段缺失或导入后参数明显异常，应回到自己的原始资料核对适用格式。不要把含认证信息的链接上传到未知转换页面，也不要仅为消除报错而删除 TLS、路径或其他传输参数。可以在本地检查是否有中文引号、换行与截断，但任何参数修改都应有明确依据。不同字段组合可能代表不同服务端设置，能成功保存不代表这些组合一定能建立连接。

需要向自己的服务商描述格式问题时，可说明协议类别、导入入口、报错阶段与缺失字段，不应公开完整链接。保留原文副本有助于比较，但应将它视作凭据保管。若已经确认客户端暂时不能解释某项资料，先取得适用的参数说明，再决定手填或重新导入，避免从不完整文本中猜测连接方式。

订阅更新：先确认结果，再调整策略

订阅更新是重新请求远程地址并处理返回内容，不是给应用升级。应用更新通过 App Store 进行；服务器列表更新则由 Subscribe 记录及其远程内容决定。两种更新的对象、失败原因和恢复方式都不同。一次订阅更新可能带来名称变化、新增记录、参数调整或旧记录移除，因此更新前最好知道当前正在使用哪条服务器，以及它属于哪个订阅，更新后才能准确核对变化。

手动更新建立基准

第一次配置订阅时，先完成一次可观察的手动更新。在 Home 的对应订阅记录或相关操作菜单中执行更新，等待结果后检查所属服务器列表。界面入口以当前应用显示为准，不应把单条服务器的测试操作当作订阅更新。成功的基准包括：请求没有明确错误、列表能够解析、重要记录字段符合预期。仅看到更新动作结束，还不能说明每台服务器都可连接。

如果界面显示更新状态或时间，可用作本次检查的线索，但不要只依赖它判断远端内容是否发生变化。对照一两个已知记录，核查名称、协议或地址是否与当前资料一致。远程列表可以在内容未变的情况下正常返回；反过来，请求收到网页错误也不代表返回了有效服务器列表。遇到异常先保留提示，不要连续点更新，以免掩盖第一次失败的上下文。

自动更新围绕可恢复性安排

若当前 Subscribe 设置提供自动更新或间隔选项，应按自己的使用频率和网络条件安排，并先确认手动更新可靠。自动化不能修复失效地址、错误凭据或不兼容格式；它只会按条件再次执行请求。间隔也不应被理解为精确的后台执行承诺，设备状态、系统调度与应用运行条件都可能影响实际发生时间。重要使用前可主动检查一次结果，而不是假定远端变化已经同步。

移动网络与 Wi-Fi 的可达性可能不同，更新失败时应记录使用的网络、连接开关状态和错误类别。不要直接假定更新请求必然经过当前选中的服务器；实际路径受应用设置及网络状态影响，应以可观察结果核对。若切换网络后成功，说明需要进一步检查原网络的解析或访问条件，而不是立刻重建全部订阅。每次只改变一个条件，有助于保留可解释的因果关系。

更新后的名称变化与本地编辑

远程订阅通常是其生成记录的参数来源，本地对名称或字段的修改可能被后续内容覆盖。若需保留特殊用途的独立记录，应另行管理，并明确它不会自动继承远程修正。远程删除的服务器也可能从本地列表消失，这与手工删除的原因不同。更新后原先选中的记录不见了，应重新确认实际选择，不能因为 Home 开关仍开着就认为仍在使用原来的目标。

地址失效与服务器失效也应分开判断。订阅请求失败，但已保存服务器仍能连接，可能只是列表入口的问题；列表更新成功，而全部服务器连接失败，则应检查认证状态、服务端变化和本地网络。若远端确实更换了订阅地址，编辑正确的 Subscribe 记录并核对新结果，确认稳定后再清理旧项，不要只根据名称相同就认为两条记录完全等价。

更新后网页异常而延迟仍有数值，可参照DNS 解析失败排查继续检查。将“列表获取”“连接建立”“域名解析”“网页请求”分开记录，可以避免在错误层次上重复更新。自动策略最终应服务于稳定、可核查的管理，而不是追求更频繁的刷新动作。

多订阅整理：保留来源与用途边界

同时管理多个已有订阅时，最重要的是知道每条服务器由哪个订阅生成、是否会自动更新，以及当前为何选择它。数量增加后，名称相似、重复导入和本地编辑容易让来源关系变得模糊。整理的目标不是让列表看起来更短，而是让更新、测试和恢复都有明确对象。开始整理前先保留原始资料，确认正在使用的记录；不要在无法分辨来源时批量删除相似名称。

名称描述用途，不承载凭据

订阅名称建议使用稳定、容易辨认的用途标签，例如“个人常用”“临时验证”，独立手工记录则增加“手工”标记。服务器备注可以补充协议或自己的用途说明，但不要写完整认证信息，也不要把某次延迟数值长期放进名称。延迟受时间、网络和测试方法影响，很快会过时；名称应帮助识别身份，不应承担实时性能判断。相同用途的命名方式保持一致即可，不需要复杂编号体系。

若订阅远程名称经常改变，本地名称编辑可能在更新后被覆盖，应先确认保存行为，再决定是否依赖它。更稳妥的方式是保留一份简短管理记录，记住订阅用途、主要记录的识别方式与维护动作。该记录不需要复制密码，只需帮助你定位原始受保护资料。不要把含敏感 URL 的截图作为唯一的来源说明，因为截图既不利于恢复，也容易在分享排错信息时泄露。

区分重复导入与合法相似记录

名称相同不一定是同一台服务器，地址相同也不一定是同一项服务。端口、协议、身份认证、TLS 和传输路径都可能不同。反过来，同一条分享链接被扫码和剪贴板分别导入，也可能产生难以辨认的重复项。整理时先比较协议和连接参数，再结合所属订阅判断，不要只靠显示名称。若无法确认，先标记观察，待完成测试与备份后再删除，比立即合并更容易恢复。

多条记录即使连接到相同地址，也可能为不同网络条件准备。应按自己的实际用途验证，而不是按地区名称或标签猜测。名称中的地理描述不等于实际请求出口或固定线路信息，本手册也不据此评价服务器。保留与否应依据用户自己的使用要求、参数完整性和测试结果。把可验证事实与标签文字分开，有助于避免因远程改名而重复重建本地列表。

整理不改变规则选择

移动列表位置、修改备注或调整显示排序，通常是管理层面的操作，不能直接推断规则已经改变。实际请求仍需结合当前服务器选择、Global Routing 与 Config 判断。若配置使用了特定名称或策略引用，重命名前还应检查相关引用是否依赖原名称。服务器整理和配置维护应分两步进行：先确认列表身份，再核查规则关联，避免在同一次操作中同时修改名称、规则和连接参数。

可以为每个订阅保留一条已验证的代表性记录，便于更新后做小范围复查，但它只是检查样本，不代表整个列表都通过验证。多个订阅也不必同时启用自动更新；先明确各自用途，再决定维护节奏。临时测试结束后应及时整理，避免几个月后分不清哪些是正式使用、哪些是排错时留下的副本。

列表清理完成后，用一次实际请求确认当前选择与之前一致，再将管理记录同步更新。若整理过程中遇到界面词不确定，可查看Home、Config、Data、Settings 界面说明。让每个管理动作都对应清楚的对象，比依靠记忆维护一长串相似服务器更可靠。

延迟测试与排序：解释数值的边界

Connectivity Test 用于检查某种测试条件下的响应情况，结果并不是完整的可用性证明。不同测试方式可能关注连接建立或特定请求响应，测试地址、超时条件和网络状态都会影响数值。数值较小不等于下载吞吐更高，也不等于所有网页都能打开。比较服务器时应先确认使用相同的方法和环境，再看结果；不同时间、不同网络下的两组数字不适合直接排名。

先测少量，再验证真实请求

在 Home 对当前需要使用的少量记录执行测试，观察正常结果、超时或明确错误。测试完成后选中其中一条，检查 Global Routing 与当前 Config，再打开一个自己明确知道用途的网页。实际验证应包含域名解析、连接建立和页面内容加载，而不是只确认网页标题出现。若只测试列表而没有确认实际选中项，可能测的是一条记录、用的却是另一条记录。

批量测试有助于快速发现明显异常，但同时发起较多请求会增加本地网络和远端的瞬时负担，也可能让结果相互影响。列表较大时可按订阅或用途分批测试，等待结果稳定后再继续。不要把一次批量超时视为所有服务器永久失效；先选择一条已知记录单独复测，再换一个网络条件比较。复测应控制变量，而不是同时换服务器、改 DNS、换规则并重新导入。

排序只是展示，不代替选择

若当前界面提供按测试结果排序的操作，可用它帮助查看本次结果，但排序后仍要核对选中标记。显示顺序变化不应被当作已经自动切换至第一条记录，除非实际设置与界面状态明确如此。测试数值也会老化，离开 Wi-Fi 后进入移动网络，原排序可能不再反映当前情况。选择应结合当前测试、实际请求和用途，而不是长期固定依赖一次排列结果。

名称、延迟与稳定性分别描述不同信息。名称由资料提供者或用户设定，延迟是一次测试观察，稳定性则需要在多个实际使用时段中判断。不要把偶发最低数值写进固定备注并作为长期依据。出现某条记录时好时坏时，记录失败发生在连接开始、网页解析还是传输途中，比单独记录“慢”更有帮助，也方便后续区分服务端负载、网络波动与配置差异。

按失败阶段分层排查

如果订阅更新正常但测试普遍失败，先检查服务器选择、认证资料与网络可达性；若测试有结果但网页打不开，则继续检查 DNS、规则路径和应用实际请求。若网页可打开但大文件速度不理想，才进一步观察持续传输与不同网络条件。一个测试结果只能说明对应条件下发生了什么，不能自动排除其他层的问题。分层记录能避免把所有现象都归结为服务器失效。

排错时可以临时选择明确的 Global Routing 姿态帮助区分路径，但测试结束应恢复自己的正常配置，并确认恢复后的请求行为。不要把临时验证设置遗留为长期状态。相关姿态含义见功能页功能介绍，常见异常可在疑难解答继续查阅。

需要比较速度时，尽量使用相同目标、相近时间和相同本地网络，避免同时运行其他大量传输任务。若结果仍明显变化，记录变化范围和条件即可，不必追求一个固定数值。更多分层检查见速度慢的分层排查。测试的价值是缩小问题范围，而不是给服务器贴上永久有效或失效的标签。

删除与备份：区分本地清理和凭据撤销

删除之前应先明确对象：是单条独立服务器、订阅生成的一条记录、整个 Subscribe，还是当前 Config。它们的恢复依据不同，误删后不能一概通过再次更新找回。删除本地记录也不会自动撤销远程访问凭据；如果目的是处理泄露，需要在对应服务管理端更换或撤销凭据。把“从设备移除”和“让旧凭据失效”分成两项动作，才能判断清理是否真正完成。

先确定数据由谁维护

对于独立手工记录，恢复通常依赖原始参数或此前保留的有效导出资料；只记住名称不足以重建认证和传输设置。对于订阅生成的记录，单独删除后是否再次出现，取决于后续更新与列表处理行为。只要远端仍包含该记录，它就可能重新进入列表。因此，想长期改变远程列表内容，应处理相应订阅管理关系，而不是反复在本地删除同一条服务器。

删除整个 Subscribe 前，应确认不再需要其所属记录，并保留自己的原始 URL。删除后不要假定所有相关本地数据一定以某种固定方式保留或移除；应阅读当前确认提示，再返回 Home 检查实际结果。若当前正在使用其中一条服务器，先切换到明确可用的替代记录，完成实际请求验证后再删除。这样即使结果与预期不同，也不会同时失去连接与恢复入口。

备份要能恢复字段和关系

备份至少应覆盖订阅原始资料、独立服务器参数、需要保留的 Config，以及它们的用途关系。若当前界面提供分享、导出或备份功能，可按其实际支持范围使用；不要仅凭操作名称假定它包含全部数据。导出后检查文件或文本是否确实包含所需对象，尤其注意单条分享与整套备份的区别。Config 文件也不应被自动视为所有服务器认证信息的备份。

保存位置应具有适当的访问保护，避免公开共享文件夹、群聊和未受控的笔记。备份文件可能包含订阅 URL、Password、UUID 或密钥，应按凭据处理。用于说明问题的脱敏副本可以删除敏感字段，但它不能替代正式恢复资料。两者最好分开放置，并明确标注用途，避免换机时拿到一份已经删掉关键参数的文本，却误以为是完整备份。

换机与重装先恢复应用，再恢复资料

换机后，先通过 App Store 的购买记录确认并获取 Shadowrocket，再恢复自己的订阅与服务器资料。应用购买记录和应用内配置数据是不同对象，重新获取应用不等于自动找回每条记录。购买适用范围、设备兼容性及系统要求以 App Store 页面标注为准；有关应用获取的步骤见已购项目恢复说明。恢复资料后仍需重新检查服务器选择、当前配置与系统连接授权。

验证恢复时，先导入少量代表性资料，核对参数后完成实际连接，再恢复剩余部分。不要在尚未确认备份可读时删除旧设备上的记录。订阅能够重新读取，并不代表本地备注、独立记录和配置改动都已回来；应按自己事先列出的恢复清单逐项核对。只有原始资料存在、格式可读、字段齐全并经过验证，备份才真正具备恢复价值。

清理结束后，检查当前连接、默认选择和 Config 是否符合预期，再处理过时备份。新备份验证完成前保留一个可恢复的旧副本；确认旧凭据已失效或不再需要后，按自己的安全管理要求移除。记录“删除了什么、保留了什么、如何恢复”比仅记录一次清理日期更有用，也能帮助下一次换机或排错时快速定位正确资料。

本页按管理任务拆解各个环节；需要从头完成一条连接时，请返回入门指南。遇到无法归类的问题，先保存脱敏后的错误提示和发生步骤，再查阅疑难解答，不要用批量删除代替定位。