Shadowrocket
订阅与服务器管理手册

先区分地址、记录与服务器

订阅地址是用于获取服务器集合的远程地址，订阅记录是 Shadowrocket 保存的来源与更新设置，服务器条目则是解析后出现在 Home 中的连接目标。三者不是同一个对象：复制订阅地址不会自动建立记录，建立记录也不代表已经取得有效服务器。排错时先确认问题位于哪一层，避免把下载失败误判成所有服务器都失效。

订阅通常含有访问凭据，即使地址看起来只是普通 HTTPS 链接，也可能允许持有者读取你的服务器信息。操作前在可信的本地位置保存原地址，确认它来自自己已有的订阅资料。不要把完整地址贴进公开留言、搜索框或截图。示例里的 example.com 只用于说明结构，不能用于连接，也不需要实际访问。

通过 Add Server 选择 Subscribe

在 Home 进入 Add Server，查看 Type 并选择 Subscribe，再填写订阅地址及用于本地识别的备注。某些界面会把订阅管理入口与服务器添加入口分开显示，若位置不同，应寻找 Subscribe 对应的订阅类型，而不是随便选择一种代理协议。保存前核对地址开头、查询参数与末尾字符，尤其注意复制时混入的空格、换行和中文标点。

1. 确认输入的是订阅地址，不是服务说明页、账户页面或单个服务器分享链接。
2. 填写能识别用途的备注，避免使用完整账号、密码或访问令牌作为名称。
3. 保存订阅记录，并按当前界面提供的更新操作获取服务器集合。
4. 回到 Home 查看对应分组，选中一个条目，检查协议与地址是否完整。

首次获取成功后，先做一次小范围核对：分组名称是否容易识别，服务器的协议是否符合已有资料，列表是否出现明显重复。条目数量只能帮助发现变化，不能作为连接质量判断。即使订阅解析成功，仍需选择服务器并完成连接验证；反过来，某个服务器暂时不可用，也不意味着订阅地址本身不能更新。

区分订阅内容与 Config 文件

服务器订阅主要解决“有哪些连接目标”，Config 文件主要解决“连接如何分流以及采用哪些配置参数”。把规则文件地址填入 Subscribe，或把服务器分享链接当成完整配置导入，都可能得到空列表或解析错误。不要仅凭扩展名判断类型；应结合原资料说明与返回内容，确认它是服务器集合、单个服务器，还是包含配置段落的文件。

如果保存后没有服务器，先查看是否尚未执行获取，再检查返回内容是否为登录页面或错误提示。浏览器能打开一个页面，不等于客户端能解析其中的服务器。不要在不了解格式的情况下反复转换地址；保留原始记录，依据错误提示区分网络不可达、身份失效与格式不兼容，再决定是否重新填写。

需要建立首次连接时，回到快速上手教程继续完成 Global Routing 与系统权限步骤。本章只建立管理关系，不建议在导入阶段同时改动 DNS、规则和多个高级选项。先确认记录能更新，再检查服务器能连接，可以让后续问题有明确的起点。

先选 Type，再填写对应参数

手动添加适用于已经持有完整服务器参数、需要核对单个条目或排查导入差异的情况。在 Home 打开 Add Server 后先选择 Type，再填写该协议显示的字段。不同协议的认证方式不同，不能把一份资料里的所有字符串依次塞进看起来相似的输入框。若缺少必要字段，应回查原始资料，而不是用其他协议的默认值补齐。

Address 一般填写服务器域名或 IP 地址，Port 填写对应端口。地址字段通常不需要额外添加网页路径，也不应把整条分享链接粘进去。域名、端口、认证信息应作为一组核对；同一域名可能提供多个不同服务，端口相同也不说明协议相同。备注用于本地辨认，可以采用“用途／协议”的简短形式，但不要依靠备注推断真实参数。

地址、TLS 与传输字段分别判断

连接地址、TLS 使用的服务器名称以及传输层的 Host 可能不是同一个值。资料明确列出多个名称时，应分别填入对应字段，不要为了“保持一致”而全部改成 Address。TLS 的服务器名称参与证书与连接过程，传输路径则可能用于请求路由；其中任意一项不匹配，都可能出现端口可达但业务连接失败的情况。

填写 WebSocket 等传输参数时，应保留路径开头的斜杠、大小写和原有查询部分。路径中的空格或特殊字符也不能凭外观随意删除。若资料没有要求额外请求头，不应自行添加一组网上找到的值。排查时可逐项对照原始参数，先记录当前值，再修改一个字段进行验证，避免多处同时变化后无法判断原因。

认证信息需要逐字一致

Password、UUID 与密钥应使用原值，注意全角字符、输入法替换和复制时产生的隐藏换行。密码中的加号、等号、斜杠不一定是多余符号；密钥尾部也可能带有合法填充字符。不要把所有看似编码过的内容都解码后再填入，客户端字段通常需要的是该字段定义的值，而不是自行推测的“可读版本”。

对于 WireGuard，应特别区分本地接口与远端 Peer 的参数。私钥属于本地身份，不应用作对端公钥，也不应放进备注或导出截图。对于依赖 UDP 的连接方式，还要考虑当前网络是否允许相关流量；字段保存成功只是格式检查通过，不等于网络路径和对端状态均已满足连接条件。

保存后返回 Home，确认选中的是新建条目，而不是名称相近的旧记录。先执行针对该条目的测试，再打开连接开关验证实际请求。若旧条目仍可用而新条目失败，把两者的 Type、Address、Port、认证与传输字段逐组比对；不要直接覆盖旧记录，以免失去能够回退的参照。

手填条目与订阅生成的条目应分开维护。对订阅条目做的本地修改可能在更新时被替换，因此需要长期保留的调整，宜在确认客户端允许后另存为独立记录，并清楚标记用途。字段名称不熟悉时可查术语表，不要将中文解释误当作需要输入的英文参数值。

Scan QR Code 读取的是文本内容

二维码只是文本的承载方式，并不是一种独立代理协议。它可能包含单个服务器分享链接、订阅地址，也可能只是普通网页地址。使用 Scan QR Code 前，先确认二维码来自自己已有的服务器资料。识别成功后应查看解析结果，判断将要新增的是单个服务器还是订阅记录，不要把“能扫出来”当成“内容正确且可以连接”。

从 Home 进入可见的扫描入口，首次使用按系统提示授予相机权限。若此前拒绝了权限，应在系统设置中检查 Shadowrocket 的相机权限，再重新打开扫描。权限正常但无法识别时，先检查画面是否完整、焦点是否清晰、屏幕反光是否遮住图案。二维码四周应保留原有边界，不要只截取中心部分或把图案压缩得过小。

二维码显示在同一台设备上时，优先使用当前界面明确提供的图片识别能力；没有对应入口时，可回到资料中复制原始文本，使用剪贴板方式导入。不要为了扫码把含有凭据的图片上传到在线识别页面。经过聊天工具压缩的图片也可能丢失细节，可使用原图或原始链接，避免多次截图叠加造成字符信息不可恢复。

剪贴板导入前检查复制边界

复制时只选中目标链接，不要连同“地址：”、引号、编号、代码围栏或解释文字一起复制。部分资料把长链接自动折行，视觉换行不一定是实际换行；如果复制后包含了真正的空行，应回到原文确认边界，不要凭感觉拼接多个片段。多个服务器链接通常应分别成行，并在导入前确认每一行都有完整的协议前缀。

1. 从已有资料复制原始链接，避免复制经过转发后被截断的显示文字。
2. 返回 Shadowrocket，使用当前界面提供的剪贴板导入入口。
3. 如系统询问是否允许粘贴，仅在本次操作确需读取剪贴板时允许。
4. 核对解析出的类型和新增位置，再保存并检查 Home 列表。

剪贴板里存在链接并不意味着客户端必须自动导入。系统粘贴权限、界面入口和当前内容格式都会影响读取结果；没有出现提示时，不要连续复制不同内容来碰运气。先确认剪贴板仍是原链接，再通过明确的导入操作触发读取。完成后可以复制一段不含凭据的普通文字，减少敏感链接长期留在剪贴板里的机会。

识别失败与连接失败分开处理

如果扫描后没有可保存的条目，问题通常仍在内容识别或格式解析阶段。检查是否扫到了说明网页、是否缺少协议前缀、链接是否被截断，以及当前类型是否受支持。此时反复开启连接开关并不能解决导入问题。保留原始文本，优先比较其结构与本手册下一章的格式说明，不要修改密码或随机删掉参数。

如果已经成功新增条目，但连接仍然失败，说明导入阶段至少生成了记录，接下来应检查字段完整性、选中状态和网络条件。扫码与手填的结果可以互作参照：同一份参数手填可用而扫码不可用时，重点比较传输、TLS 与额外参数；两者均不可用时，再检查对端信息和当前网络，而不是继续更换导入方式。

重复扫码可能产生重复条目，是否合并取决于具体导入逻辑，不能假定相同名称一定会覆盖。首次导入后记录所属分组与备注，再进行后续操作。若不确定刚才新增了哪些内容，先停止继续导入，检查列表中的协议与地址，再按多订阅整理的方法处理，避免把原来可用的记录误删。

导入完成后还需要选择 Global Routing 并授权系统 VPN 配置。相关提示与二维码本身没有直接关系，首次遇到授权窗口可阅读添加 VPN 配置提示说明。不要因为系统权限尚未完成，就认定二维码内容失效或再次批量导入相同资料。

单服务器链接与订阅 URL 不同

单服务器分享链接把一组连接参数组织成文本，常见前缀包括 ss://、vmess://、vless://、trojan:// 与 hysteria2://。订阅地址则通常是用于获取集合的 HTTPS URL，其返回内容可能包含多个服务器。判断类型时先看原资料的用途说明，再看链接结构；不能因为两者都能复制，就认为它们应该填进同一个字段。

协议前缀只提供格式线索，完整解析还取决于后面的认证、地址、端口和参数。不同协议及导出方式的编码习惯可能不同，尤其是 VMess 分享内容常以编码后的结构保存，不能直接按“用户名、密码、域名”的网页地址方式拆解。对不熟悉的格式，优先使用客户端导入，再对照解析出的字段核验。

示例用于识别结构，不用于连接

下面展示的是虚构的结构示例：服务器地址使用 example.com，认证文字也不是实际凭据。用户名或认证段、主机与端口、查询参数、片段备注分别承担不同作用。实际资料可能还包含额外字段，不能因为示例里没有就删除它们，也不能从示例推导出适用于所有服务器的传输设置。

trojan://[email protected]:443?security=tls&sni=example.com#personal-reference
https://example.com/sub?token=xxxx

链接中的问号引出查询参数，参数之间常用 & 分隔，井号后的片段常用于备注。包含特殊字符的字段可能经过百分号编码，因此看起来相似的可读文字与原始编码不一定可以互换。若认证信息本身含有分隔符，随意解码或重新拼接可能改变字段边界，导致保存出的密码、路径或备注与原值不同。

Base64 是一种文本编码方式，不是保密措施，也不是可用性验证。看不到明文密码的链接仍可能包含完整认证信息。不要把编码后的分享内容视为可公开的技术日志；同样，不要在不了解格式的情况下反复编码，二次编码可能让客户端读到一段普通文本，而不是原先的服务器结构。

服务器参数不等于流量规则

分享链接通常用于传递连接目标，不必然包含当前 Config 的规则、DNS 或其他设置。服务器导入成功后，访问某个域名是否走代理，还取决于 Global Routing 与当前规则文件。下面的 .conf 片段展示按顺序判断的规则结构，其中 PROXY 是策略关键字，不是某个订阅分组的名称，也不携带服务器认证信息。

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

示例中的 FINAL,PROXY 为前面未匹配的连接指定后续策略；它不会生成新的服务器，也不会修复失效凭据。该片段只用于解释格式，不应在缺少备份和理解的情况下替换完整配置。需要逐段理解 .conf 时，阅读配置文件段落说明，并保留原有 [General] 等设置的上下文。

分享前确认导出范围

向另一台自己的设备迁移时，先确认分享对象是单个服务器、某个订阅地址，还是完整配置。单服务器导出可能不保留订阅更新关系，配置导出也可能不包含本地服务器库；具体范围应通过导出结果核对。不要仅凭文件名判断已经完成完整备份，更不要在测试恢复前删除原设备上的记录。

收到解析失败提示时，先保留原文并检查前缀、字符边界与转义情况，再比对导入后的字段。不要把多个不同协议拼到同一行，也不要用修改扩展名的方式把链接“变成配置”。如果确需共享排错信息，只提供不含认证内容的协议名、错误阶段与必要字段结构，完整链接和二维码应留在受控环境中。

更新改变的是远程条目的本地副本

订阅更新会重新请求远程内容，并据此调整本地生成的服务器集合。它与连接开关、延迟测试不是同一操作：开启连接不会自动证明订阅已更新，测试成功也不能说明取得的是最新参数。更新前应知道自己正在操作哪个订阅分组，并记录当前选中条目，避免更新后目标被移除或改名而误选到其他服务器。

首次建立订阅、原资料提示服务器参数发生变化，或者列表出现明显过期迹象时，可以主动更新。不要把高频刷新当作修复所有问题的方法；如果返回内容没有变化，重复请求不会改善某个服务器的线路状态。是否启用自动更新，应结合当前界面提供的选项和实际需要决定，并了解它在前台、后台与不同网络条件下可能受到系统限制。

按请求、响应、解析、连接四层排查

如果更新一直等待，先检查设备是否能正常访问其他已知网络资源，再检查订阅域名能否解析。订阅服务器和实际代理服务器可能使用不同地址，因此一个可用不代表另一个也可达。若界面提供更新请求相关的路由选项，应确认当前选择符合实际网络条件；不要假定每次更新都必然经过当前选中的代理服务器。

如果很快返回解析错误，重点查看拿到的是否真是订阅内容。账户登录页、访问验证页或错误说明通常不能直接当作服务器集合处理。浏览器显示“打开成功”只说明获得了响应，不代表响应格式适用。不要尝试把错误页面保存后重新导入，也不要为绕过错误而移除地址里看起来复杂的认证参数。

更新成功后检查变化，而非只看提示

更新完成后，核对分组是否仍有内容、原先选中的服务器是否还存在，以及备注或协议是否变化。服务器数量减少可能来自远程集合调整，不能单凭数量判断异常；同样，数量增加也不是质量提高的证明。先确认新增或保留的条目参数合理，再执行一次测试和实际访问，建立更新后的可用状态。

订阅生成的服务器应优先从远程资料保持一致。若在条目里手动改过密码、传输路径或 TLS 名称，后续更新可能覆盖这些修改。需要保留本地实验时，应先记录改动并另存独立条目，明确它不再自动跟随原订阅。不要为了保存本地修改而长期停止所有更新，却忘记远程参数仍可能变化。

怀疑原地址中的凭据已经泄露时，仅删除本地订阅不能使旧地址失效。应通过自己已有的账户管理渠道确认是否能更换相关访问凭据，之后再把新地址写回订阅记录。更换后检查旧链接的处理结果，并清理包含旧地址的截图、临时文本和其他设备剪贴板，避免旧资料继续被重复使用。

更新与连接问题交织时，坚持一次只改变一个条件：先保持当前网络验证订阅请求，再选一个更新后的条目验证连接，最后检查 Config 与 DNS。已经显示连接但网页打不开的情况，可继续阅读已连接但无法访问的排查清单，不要把所有故障都归因于订阅更新。

分组名称体现用途与维护关系

同时维护多个已有订阅时，优先保留清晰的来源边界，不要一开始就把全部服务器混成一个列表。分组名称可以体现个人用途、维护责任或使用场景，例如“日常／订阅”“工作／手填”“临时／待核对”。名称不需要暴露账号和访问地址；能帮助判断该在哪里更新、哪些条目允许本地修改，比追求统一外观更重要。

应区分订阅层备注与服务器层备注。前者帮助找到更新入口，后者帮助选择连接目标，两者即使名称相近也不表示是同一个对象。远程订阅可能在更新时重写服务器名称，因此本地整理策略不能完全依赖条目备注保持不变。对必须长期保留的说明，可在受控的本地维护记录中保存与分组的对应关系。

重复判断不能只比较名称

两个同名条目可能有不同地址、端口或认证信息；两个不同名条目也可能指向相同端点。检查重复时，至少比较协议、地址、端口和关键传输参数，再确认它们是否来自同一订阅。不要公开导出整份列表来求助去重，列表中可能包含完整认证信息。需要记录比较结果时，可只写本地分组和不含凭据的识别说明。

来自不同订阅的相似条目未必应该删除其中一个。它们可能具有不同更新周期、认证范围或使用条件，当前参数相同也不能保证以后一直相同。若只是想减少选择干扰，可以优先采用客户端已有的分组或筛选方式，而不是破坏来源关系。只有明确知道条目用途、备份状态和更新行为后，再决定是否清理。

服务器分组不等于规则策略

Home 里的分组用于组织服务器，Config 中的规则则决定连接如何处理。将某个服务器移动到名称不同的分组，通常不等于让某类域名自动走该服务器。若配置使用了按名称引用的策略或分组，重命名后还需要检查配置中的引用。具体关联取决于当前配置内容，不能仅凭分组的中文名称判断流量行为。

Global Routing 的三种常用姿态也应分别理解：配置对应 Config，按当前配置规则处理；代理对应 Proxy，用于让适用流量经过代理策略；直连对应 Direct，用于按直连方式处理。整理服务器列表时不应顺手切换这些姿态并遗忘恢复，否则测试结果可能与整理前不在同一条件下，容易误以为分组调整影响了服务器质量。

采用分批整理与回退记录

开始清理前，先记录当前分组、选中服务器和可用连接状态，再处理一组明确的重复内容。完成一批后检查更新入口是否还在、选中状态是否改变，并验证一次实际请求。不要在同一轮里同时大量删除、重命名、更新订阅与替换 Config；这些操作叠加后，即使出现问题也很难确定是哪一项造成。

如果某个条目暂时不确定用途，可以先保留并做本地备注，不必为了列表简短立刻删除。需要清理时优先处理已明确失效且可恢复的临时记录，再处理独立手填条目，最后考虑订阅分组。订阅内单条服务器被删除后，后续更新仍可能重新出现，这属于远程集合与本地副本的关系，不一定是删除操作没有执行。

整理完成后，用一份不含敏感值的维护说明记录“哪些分组自动更新、哪些条目独立维护、哪些配置引用名称”。这份说明不需要写入密码和完整链接，但能帮助换机或恢复后重建管理关系。界面词含义可结合Home、Config 与 Settings 对照说明查阅，避免在错误层级执行批量操作。

测试结果只描述特定条件

Connectivity Test 用于在一定测试方法和当前网络条件下检查服务器表现。显示一个较小的时间值，不代表所有网站都能访问，也不代表吞吐量更大；超时则说明这次测试没有在预期条件内完成，不能直接推断认证信息永久失效。解释结果时需要同时知道测试方法、网络环境以及测试发生时服务器是否繁忙。

不同测试方式覆盖的连接阶段可能不同。只验证端口可达的测试，无法完整证明代理认证、TLS、域名解析和目标请求都成功；通过代理发起请求的测试，也只反映当次目标与路径。若当前界面允许选择测试方式或测试地址，应先确认使用的是哪一种，再比较结果，不要把不同方式得到的数值放在一起排序后得出结论。

先做单条验证，再做有限范围测试

对新导入的订阅，先选一个参数完整的条目执行测试，确认客户端和网络状态正常，再对需要比较的分组做批量测试。一次测试整个大型列表可能产生较多并发请求，结果容易受本机网络、对端限制或测试目标影响。重复失败时先缩小到一个条目，而不是继续增加并发量试图得到更多结果。

1. 保持同一网络环境，确认没有正在进行的大流量任务影响观察。
2. 明确测试方法，并选取需要比较的少量服务器。
3. 对异常结果进行间隔复测，不凭单次超时删除条目。
4. 选中候选服务器，开启连接并验证实际需要访问的内容。

Wi-Fi 与 Cellular 的网络路径可能不同，在一种网络下可达不代表另一种网络下也可达。切换网络后应重新验证，不应沿用旧测试结果断言当前状态。如果所有条目同时异常，先检查本地网络、系统时间、测试目标与 DNS；多个独立端点同时故障时，本地共同条件往往比逐个修改服务器参数更值得优先检查。

排序是临时视图，不是自动选路承诺

按测试结果排序可以缩短查找候选服务器的过程，但排序不会自动改变所有规则的策略，也不保证客户端已经选中列表第一项。排序后应明确查看选中标记，并确认当前 Global Routing 和 Config。若规则引用了特定策略或服务器名称，实际连接仍可能不使用刚刚测试的条目，需要结合当前配置判断。

比较服务器时应在相近时间、同一网络和同一测试方式下进行，再用实际任务确认。大文件下载、短网页请求与长连接对路径的要求并不相同，单个延迟指标无法概括全部体验。服务器备注中写出的地区或用途也不能替代测试；备注属于识别信息，实际连接经过的路径仍需依据当前状态判断。

连接后失败，沿实际请求继续检查

如果测试可达而网页无法打开，先确认所选服务器确实参与当前请求，再检查 Global Routing、DNS 与规则匹配。可在排查阶段临时比较不同姿态的表现，但每次只改变一个条件，测试后恢复原配置。不要为了让单个网页打开就永久替换整份规则，也不要把全部失败都归结为延迟较高。

记录排查结果时，保存网络类型、测试方法、是否选中目标以及错误阶段即可，不必公开完整服务器地址和凭据。需要进一步区分规则与连接问题时，阅读服务器、Global Routing、DNS 与规则排查。稳定的管理依据是可重复的验证步骤，而不是一次排序或一个孤立数值。

删除前确认操作层级与关联

删除单个服务器、删除订阅记录、移除 Config 文件与删除系统 VPN 配置是不同操作。前两项影响本地服务器管理，Config 影响规则与配置内容，系统 VPN 配置影响系统连接授权及相关设置。操作前应读取当前界面的对象名称和确认提示，不要把“连接异常”直接等同于需要清空全部记录。

删除订阅内单条服务器后，它可能在下一次更新时重新出现；删除整个订阅记录则可能同时移除其生成的条目，具体范围应以确认提示为准。删除前记录当前选中服务器，并检查是否有配置按名称引用它。若引用对象消失，后续问题可能发生在策略选择层，而不是远端服务器真的停止工作。

备份需要覆盖不同数据层

完整恢复所需内容通常不止一份 .conf 文件。订阅地址、独立手填服务器、配置文件及其选择状态、本地覆盖设置和必要的操作说明，应分别核对是否已保存。不要假定某个导出入口自动包含全部数据；先查看当前界面对导出范围的说明，再验证输出内容。导出文件能打开，也不代表已经包含可恢复的认证信息。

备份文件、分享链接和二维码可能包含相同等级的敏感数据，应保存在访问受控的位置。若使用设备自带的文件同步能力，也应了解目标账户和共享范围；不要把备份误放到公开共享目录。为了排错而临时生成的导出文件同样需要管理，完成核对后清理不再需要的副本，避免旧凭据散落在多个位置。

恢复按来源、条目、配置、连接的顺序进行

在新设备恢复时，先通过全平台下载指南获取 Shadowrocket，再按备份内容重建订阅来源和独立服务器。随后恢复 Config，并检查配置中引用的名称是否存在。最后设置 Global Routing、选择服务器并完成系统授权。这个顺序有助于把“数据没恢复完整”和“连接条件不满足”区分开来。

iPhone / iPad 的应用获取与服务器资料恢复是两回事：重新取得客户端，不代表订阅地址和本地参数已经恢复。iPhone / iPad 在 App Store $2.99 一次性付费，Mac / Windows / 安卓 / Linux 版免费；应用获取和已购项目说明见下载页。客户端一次性买断 ≠ 线路套餐，恢复应用也不会生成新的服务器信息。

恢复后先选一个条目测试，再用实际请求验证；确认成功后才考虑删除旧设备上的记录。跨设备迁移时，部分本地设置、系统权限和后台行为可能不同，不应只看服务器名称一致就认为迁移完成。如果新设备失败而旧设备可用，优先比较关键字段、Config、Global Routing 和网络条件，保留旧设备作为回退参照。

误删与凭据失效采用不同处理方式

误删本地条目时，优先从已保存的订阅地址、服务器分享内容或备份文件恢复。若只是删除了订阅内条目，确认来源记录仍存在后，可尝试按正常流程更新。不要期待撤销入口一定存在，也不要在不清楚数据状态时反复导入多份旧备份；这容易造成重复记录和不同参数混杂，反而增加恢复难度。

若凭据已经更换或失效，旧备份只能还原旧参数，无法恢复远端授权。此时应回查自己已有的有效资料，更新订阅地址或认证信息，再重新验证连接。若目的是让泄露的链接失效，需要处理远端凭据而不只是本地删除。最终应保留一份已验证可恢复的备份，以及一份不含敏感值的维护说明，让下次更新和迁移有明确依据。