Shadowrocket
订阅与服务器管理

Subscribe：保存订阅与首次导入

先判断手里的内容属于哪一种

订阅是一个用于获取服务器列表的更新地址，不等于某一台服务器的地址，也不等于 Config 中的规则文件。开始操作前，先核对你保存的是订阅地址、单条分享链接，还是独立的服务器参数。以 https:// 开头的内容可能是订阅，也可能只是说明网页；不能仅凭前缀判断用途。应以这份信息原本附带的用途说明为准。订阅地址可能含有用于识别账户的参数，复制时需要保留完整路径和查询字符串，但不应把它发到公开讨论区。

在 Home 的添加入口查找 Subscribe；有些布局会先打开 Add Server，再通过 Type 选择 Subscribe。选择后，把已有订阅完整粘贴到 URL 对应输入框，为其设置便于辨认的备注，然后保存。这里的备注只帮助你识别来源，不会改变远端服务器名称、认证信息或更新权限。如果当前界面提供额外选项，首次导入先保持原值，除非你已经知道该选项对应的用途。不要为了让订阅“看起来正确”而随意改写地址末尾的参数。

将保存地址与取得列表分开检查

保存成功只表示订阅条目已写入本地，不一定代表已经获取到可用列表。保存后观察 Home 中是否出现归属于该订阅的服务器；若界面没有自动获取，使用对应条目的更新操作。检查结果时依次确认三件事：订阅条目是否仍在、更新是否给出错误提示、列表中是否出现服务器。备注能显示而列表为空，往往说明地址保存成功，但网络请求、账户授权或返回内容仍需检查。此时重复添加同一个订阅通常只会制造重复条目，并不能修复原来的请求。

复制错误是首次导入最常见的原因之一。链接前后的空格、聊天软件插入的换行、全角标点，以及只选中了屏幕上可见的一部分，都可能改变请求。重新复制时应从原始文本取得完整地址，而不是照着截断后的显示文字手动补写。若地址内含 &、? 或百分号编码，不要把它们当成多余符号删除。排错记录只需写下请求结果和出现问题的阶段；需要分享截图时，先遮挡整条订阅地址及账户标识。

列表导入后再建立连接基线

有服务器出现后，选择一个条目，再检查 Global Routing 与当前 Config。服务器列表决定“连接到哪里”，规则配置决定“哪些流量使用该连接”，两者需要分别确认。首次验证宜保持一个已知条目和一份明确选中的配置，不要同时更改多个开关。如果 Subscribe 更新成功而网页仍无法访问，应继续检查服务器连接与规则，而不是立刻判定订阅地址有误。相反，更新失败但原有服务器仍能连接，也可能只是更新端点暂时不可达。

订阅导入不会自动证明所有条目都适合当前网络，也不保证每个条目参数都相同。先完成一次列表获取，再做连接测试，最后决定是否启用定期更新。这样可以把“订阅请求失败”“服务器握手失败”“规则没有命中”分成三个独立问题。尚未完成首次连接时可回到使用教程逐步验证；已经能连接但需要调整 Global Routing，则查阅设置说明，避免把规则问题误处理成重新导入问题。

Add Server：手动填写服务器字段

先选 Type，再填写地址与认证

Add Server 用于建立单个服务器条目。打开后先选择 Type，再填写对应协议需要的字段；不同协议下同名字段的含义不一定完全相同，不能先照着别的条目填完，再随意切换 Type。Address 通常填写主机名或 IP 地址，不包含网页路径；Port 填写对应端口，不应把地址和端口一起塞进 Address。备注可以使用便于识别的文字，但连接参数应按已有信息逐项保留，包括字符大小写、分隔符和可能存在的特殊字符。

认证字段需要与协议配套理解。Shadowsocks 的 Method 和 Password 要成对匹配；VMess 与 VLESS 常见 UUID 字段；Trojan 使用的 Password 不能因为外观看起来像另一种标识就改填到 UUID。WireGuard 则涉及密钥、地址与对端参数，不能只凭一个服务器域名完成填写。缺少必要信息时，应先补齐原有服务器资料，不能用某个协议的常见默认值代替。某个字段在界面中显示为空，也不代表它在当前服务器端一定可以省略。

区分连接地址、TLS 与传输参数

TLS 的服务器名称、传输层的 Host 与实际连接 Address 可能相同，也可能不同。这些字段分别服务于不同阶段：Address 用于找到连接目标，SNI 参与 TLS 握手，Host 与 Path 则可能用于应用层传输。不要因为三处都能填写域名就把它们合并。Path 中的斜杠、尾部字符和大小写也可能影响服务端路由。若资料只给出一条完整分享链接，优先按下一章的方法导入，再核对解析后的字段，比凭链接外观猜测参数更可靠。

遇到证书或握手错误时，先检查系统时间、SNI、TLS 开关和服务器端口，再检查原始资料是否已经变更。不要把跳过证书验证当成常规修复步骤；该操作会改变身份核验条件，即使暂时连接成功，也不能说明填写问题已经解决。传输方式同样必须与服务器端一致，开启 TLS 并不能自动修复错误的 Host、Path 或 Type。一次只改一个已确认错误的字段，并保留修改前的记录，才能判断哪一项影响了结果。

保存后进行单条验证

保存条目后回到 Home，先确认选中的确实是刚创建的服务器，而不是列表里同名的旧条目。随后进行连接验证，并把结果分为解析失败、无法建立连接、认证失败或连接后访问异常。不同提示对应不同检查顺序：域名无法解析时先看 Address；连接超时时先看端口和网络可达性；认证失败时重点核对密码或 UUID；已连接但部分访问异常时，再看 Config、DNS 与目标服务。只看到一个失败结果时，不宜把整份参数全部重写。

手动条目通常不会随着某个订阅的更新自动同步。若远端密码或地址变更，需要根据原有资料手动维护，或改用已有的订阅地址重新导入。建议在备注里清楚区分“手动”与“订阅”，但不要把密码、UUID 或私钥写进备注，避免它们出现在列表截图中。VMess 与 VLESS 的概念差异可参阅协议字段说明；理解差异的目的在于准确填写，而不是凭协议名称推断服务器的实际可用性。

扫码与剪贴板：确认导入对象

Scan QR Code 只是读取内容的入口

二维码是承载文本的方式，不是新的代理协议。Scan QR Code 读取到的可能是单条服务器分享链接，也可能是订阅地址，甚至只是一个网页地址。开始扫描前先确认二维码来自你已有的服务器资料，并明确预期结果：是增加一个服务器，还是增加一个可以更新的订阅。扫描后若出现确认页面，查看 Type、Address 或 URL 等关键信息，再决定是否保存。不能因为二维码能被相机识别，就认定其中内容一定能由 Shadowrocket 直接导入。

首次使用扫描入口时，系统可能询问相机权限。拒绝权限会影响取景扫描，但不代表二维码内容损坏；可以在系统设置中按需要调整权限。若二维码就在当前设备屏幕上，先查看当前入口是否支持从照片读取；没有该选项时，使用同一份资料提供的文本链接会更直接。不要为了绕过读取问题，把包含订阅凭据的图片上传到不明识别页面。二维码截图也需要按敏感资料保管，因为图形被识别后仍会恢复完整地址或认证信息。

剪贴板导入前清理外围文字

从剪贴板导入时，应复制链接本身，而不是连同“点击这里”“服务器信息”等说明文字一起复制。聊天记录中的链接可能带有尾随句号、括号或换行；有些应用显示的是缩略文本，长按复制得到的却可能是说明网页。导入没有反应时，先确认复制内容的起始前缀与预期格式一致，再检查是否混入了多余文字。系统询问是否允许粘贴时，应按自己的操作意图授权；拒绝后重新尝试时，也要留意系统权限状态。

多行内容不一定会被一次性识别为多条服务器。若导入结果只有一条，先检查原始文本是否确实包含多个独立分享链接，而不是一个跨行显示的长链接。可以先导入其中一条，确认解析方式正确后再处理其余内容。不要把多行文本自行拼接成一行，也不要任意给每一行补上协议前缀。批量导入完成后，逐一检查归属和备注；复制同一段内容多次，可能得到多个相同条目，后续测试时容易把重复结果误当成不同服务器。

按“读取、解析、保存”分段排错

扫描没有取到内容，属于读取阶段的问题，优先检查画面清晰度、二维码完整性和权限；读取到文本但提示格式不支持，属于解析阶段的问题，应核对链接类型与当前入口；已经生成条目却连接失败，则应检查参数和服务器可达性。把这三个阶段拆开，能避免反复换扫描方式却一直没有检查参数。二维码边缘被裁掉、图像压缩后模块模糊，都会影响识别；适当放大原始图片比重复拍摄低清截图更有帮助。

导入成功后还需要做一次字段复核。查看服务器类型、主机名、端口与传输设置是否符合原有信息，并确认条目出现在预期位置。若本来要导入订阅，却只得到一条服务器，应回头确认二维码是否承载了单条分享链接。若生成的是 Subscribe 条目，但列表仍为空，就转入订阅更新排查，而不是继续扫描。单条链接与订阅地址的区别也可结合分享链接与订阅链接说明阅读。

同一份资料通过扫码和剪贴板导入，理论上应得到相同的参数；两次结果不同时，先比较原始文本是否一致，再检查是否混入旧剪贴板内容。不要只根据条目备注判断它们是否相同，备注可以变化，真正决定连接的是协议字段。保留其中一份作为待确认条目，验证后再整理重复项，会比立即覆盖现有可用条目更稳妥。

分享链接：前缀、编码与配置边界

前缀帮助识别格式，不替代参数检查

ss://、vmess://、vless:// 与 trojan:// 通常用于描述单个服务器。它们使用不同的结构承载地址、认证与传输信息，不能简单地替换前缀来转换协议。HTTP 或 HTTPS 地址则可能指向订阅内容，也可能指向普通网页。判断方式应结合原始资料说明与实际返回内容，而不是看到一个可点击地址就直接保存成 Subscribe。某些格式存在不同实现约定，因此能识别前缀不等于所有扩展字段都能完整保留。

Shadowsocks 分享链接可能对认证部分或较大范围的内容进行编码；VMess 常见的是编码后的 JSON 描述；VLESS 与 Trojan 常见的是带查询参数的 URI 结构。对于日常使用者，最重要的操作不是手工解码，而是完整复制、使用匹配入口导入，再检查解析结果。自行解码后又重新编码，容易改变特殊字符、丢失填充符或重复处理百分号编码。若需要排查某一字段，应在本地查看并与已有资料比较，不把整条链接交给陌生在线工具处理。

备注、查询参数与编码字符各有用途

URI 里的查询参数可能包含传输方式、Path、Host 或其他连接设置；片段部分常用于备注，但具体仍以该格式的约定为准。备注中出现中文时，原始链接可能使用百分号编码，导入后显示为可读文字是正常现象。排错时不要把所有百分号内容替换成中文后再粘贴，也不要把参数中的连接符当成排版符号。若链接经过文档软件或聊天软件转发，需特别检查半角引号是否被替换、末尾是否附加标点，以及原本一行的内容是否被实际插入换行。

分享链接还涉及敏感信息范围。即便屏幕上只显示一个简短备注，完整链接仍可能包含密码、UUID 或其他认证资料；二维码与分享功能只是把这些内容换一种方式传递。复制链接给另一台自己的设备前，确认传递路径和接收对象，完成后按需要清理临时文件。反馈格式问题时，可以仅提供协议前缀、字段名称和错误提示，并用示例值替换地址与认证信息。隐藏一部分备注并不能隐藏真正的连接凭据。

服务器链接不等于 Config 规则文件

导入服务器后，Global Routing 选择 Config 时仍要依靠当前规则决定流量去向。下面是用于说明匹配顺序的真实规则语法，不包含可连接的服务器参数，也不会生成订阅。规则通常从上到下匹配，末尾的 FINAL 处理此前未命中的流量；其中 PROXY、DIRECT 是策略含义，不能把它们误当成服务器域名。准备编辑配置时，应先保存原文件，并核对当前配置中所使用的策略名称。

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

将一段规则粘贴到 Subscribe 的 URL 输入框不会变成订阅；把服务器分享链接直接当作规则行写入，也不会自动创建对应策略。服务器、订阅和规则分别维护，正是排错时最需要保持的边界。需要了解 Config、Proxy、Direct 对实际流量的影响，可继续阅读Global Routing 三种模式说明，再回到当前服务器进行对照验证。

更新策略：请求结果与列表变化

更新订阅不是更新应用，也不是续期

Subscribe 更新是重新请求已有地址，并按返回内容刷新服务器列表。它不会替代应用更新，也不会改变服务账户的有效状态。应用本身的获取与更新渠道见下载指南；订阅内容是否仍可访问，则取决于原有地址、账户权限与网络状态。明确这个区别后，遇到更新失败就不会把重新安装应用当作第一步。先记录当前订阅是否还能请求、现有服务器是否还能连接，再决定检查哪一层。

建立更新习惯时，先完成一次手动更新，确认地址能正常返回列表，再根据当前界面提供的设置决定是否自动更新。更新频率不宜只追求更密集：服务器列表没有变化时，频繁请求通常不会改善连接，反而增加排查噪声。长时间未使用、已知资料发生变化或当前条目普遍失效时，可先执行一次手动更新。设备休眠、后台限制和网络切换可能影响定时任务，不能把“设置了自动更新”理解成每个时刻都会严格执行。

按错误阶段建立检查顺序

请求超时优先检查当前网络与订阅域名是否可达；认证或访问权限错误优先核对完整 URL 与账户状态；返回内容无法解析则需判断拿到的是服务器列表，还是说明页面、登录页面或其他响应。不要只看有没有内容：浏览器打开后显示一段网页，并不等于 Shadowrocket 得到了它能够解析的订阅格式。若错误发生在导入后的第一次更新，重新从原始资料复制完整地址通常比反复修改可选设置更有效。

更新请求与现有代理连接之间也可能存在依赖。某个订阅端点在当前网络下不可达，而原有服务器仍能连接时，可以在受控条件下比较连接前后的请求结果；但不要假定所有平台的订阅请求都必然经过同一种路由。记录当时是否连接、Global Routing 的模式和所选服务器，才能进行有意义的对照。反复切换多处设置却不记录结果，容易把偶然恢复误认为某个无关开关起了作用。

更新后检查归属、数量与选中状态

服务器列表在更新后增加、减少或改名，不一定是本地数据损坏，也可能是返回内容已经调整。先检查变化是否只发生在对应订阅分组，再确认当前选中的服务器是否仍然存在。若旧条目被替换，原先记住的名称不一定还能准确定位同一个目标。重要操作前可记录所选条目的名称与协议类型，但不要公开完整参数。不要依靠列表位置记忆服务器，因为排序或更新都可能改变位置。

更新后出现空列表时，先停止连续重试，保留错误提示并检查是否影响现有连接。不同导入与更新路径对旧内容的处理可能不同，不能假定失败时一定保留所有条目，也不能假定空列表表示远端确实没有服务器。先确认请求返回是否有效，再决定恢复备份或重新导入。若其他订阅正常、只有一个订阅异常，应把问题范围限制在该订阅及其请求条件内，避免同时删除所有来源。

手工修改订阅生成的条目时，还要考虑下次更新可能覆盖这些更改。如果确有临时修正需求，可在界面支持的情况下建立明确标注的独立副本，并记录原因，而不是把临时值写回订阅地址。恢复原始资料后及时清理临时副本，避免以后误把过时参数当成正式维护结果。有关副本与多订阅命名的方法，下一章给出统一整理顺序。

多订阅整理：归属、命名与规则关系

先按来源分组，再在组内识别条目

多个订阅同时存在时，首要任务不是把所有服务器排在一起，而是让每个条目都能追溯到对应订阅。为订阅设置稳定、简短的备注，例如按用途或自定编号区分；服务器名称则尽量保留原有信息，避免更新后难以对照。若两个订阅恰好生成同名服务器，应先查看分组归属与实际参数，而不是仅凭名称删除其中一个。不同来源出现相同名称，并不能证明连接地址或认证信息相同。

整理时可依次检查订阅条目、其下服务器和手动条目。先确认哪些内容会由更新维护，哪些是自己建立的独立条目，再决定是否重命名或移除。命名最好表达用途与维护方式，而不是保存敏感数据；例如“手动测试”可以说明条目性质，完整密码、UUID 或订阅参数则不应出现在列表备注里。界面没有自定义分组功能时，也可以依靠清晰的订阅备注与独立记录保持归属，不必假设每个平台都具备同样的整理菜单。

去重应依据参数，而不是显示文字

判定重复至少要结合协议类型、地址、端口、认证与传输设置。两条记录即使连接到相同域名，也可能使用不同端口或不同传输方式；备注不同的两条记录，也可能只是同一份信息被导入了两次。先比较关键字段，再选定需要保留的一份。涉及订阅生成条目时，应优先清理重复订阅来源，因为只删除其中一条服务器，后续更新可能又将其恢复。这样能避免每次更新后都重复做同一轮手工删除。

不要为了列表整齐而一次移除全部旧记录。可以先标记已确认的重复项，保留当前可用服务器，完成一次订阅更新和连接验证后再清理。暂时无法确认是否重复的条目，留待逐条测试比直接删除更合适。若同一订阅被导入两次，应先确认两份 URL 是否完全一致，再判断是否只是备注不同。订阅地址中的查询参数可能决定返回内容，不能只比较域名和路径就认定它们相同。

服务器选择与规则策略分开管理

Home 中选中的服务器与 Config 中的策略引用存在关联，但列表整理不等于规则调整。Global Routing 处于 Proxy 时，测试更直接地反映所选代理连接；处于 Config 时，目标流量可能按规则走 DIRECT，因此打开网页成功并不能单独证明当前服务器已经承担这次连接。整理后若需要验证某条服务器，应使用明确的测试流程，并在完成后恢复日常模式，不要让临时排查状态长期保留。

如果配置中使用了特定服务器或策略组名称，重命名前先查看相关引用，修改后再验证。直接在列表中改名，不一定会同步更新配置中的文字引用。整理数量较多时，应采用“一个订阅、一组变更、一次验证”的节奏；完成当前组后再处理下一组，故障出现时范围更清楚。配置规则的具体设置可查阅设置页，不必为整理列表重新建立整份 Config。

多设备使用时，建议保持相同的订阅备注逻辑，但不要依赖相同的列表次序。每台设备的排序、缓存测试结果和最后选择都可能不同；迁移后应重新核对归属与所选条目。用于管理的简短清单只需记下订阅名称、维护方式和用途，完整地址则放在受控备份中。这样既能解释列表结构，也能在某个设备出现异常时定位需要恢复的那一部分。

延迟测试与排序：读懂结果再选择

Connectivity Test 回答的是有限问题

Connectivity Test 用于观察当前测试条件下的连通表现。结果受到设备网络、测试方式、目标地址、服务器握手与瞬时负载影响，不能直接等同于下载速度，也不能保证所有应用都能访问。不同测试方式测量的阶段可能不同：有的偏向连接建立，有的还涉及实际请求。因此，比较前先确认各条目使用相同测试方式与相近的网络条件。不要把不同时间、不同网络下的结果直接排列成稳定的性能结论。

测试前先选择一个能够代表日常使用的网络环境，并暂停正在进行的大量传输，以减少干扰。若刚从移动网络切到 Wi-Fi，先等待系统网络状态稳定，再开始测试。批量测试会在短时间内产生较多连接；数量较多时可以分组执行，避免一次并发过大让本地网络或远端响应受到干扰。某个条目第一次超时，不宜马上删除，应先复测并与同组其他条目进行比较。

把失败结果分成单条、整组与全局

只有一条失败时，优先核对该条目的协议、端口、认证和传输字段；一个订阅下多条同时失败时，检查该订阅是否已更新、账户状态是否变化，以及这些条目是否共享同一组网络条件；所有条目都失败时，再检查设备联网、DNS、连接权限与当前测试设置。这样的分层比不停切换服务器更有效。若测试失败但实际访问正常，也应检查测试目标本身是否可达，而不是直接改写所有服务器参数。

测试成功但实际访问失败，需要进一步查看流量是否真正走了所选服务器。Config 中某条规则可能让目标直连，DNS 解析也可能出现独立问题。可以在明确记录当前设置后，对照 Proxy 与 Direct 的表现，再恢复 Config。对照的目的在于缩小故障范围，不是永久改变路由习惯。连接开关显示已启用，也只是运行状态的一部分；是否完成握手、目标请求是否成功，仍要依赖具体访问结果判断。

排序是观察工具，不是自动维护结论

按测试结果排序可以帮助找到值得进一步验证的条目，但列表靠前并不必然适合所有任务。低延迟反映较短的某段响应时间，持续传输还涉及带宽、拥塞和目标服务。选择时应综合重复测试的稳定程度、一次实际访问和日常使用表现，而不是只追逐一次最小数值。排序后先确认选中状态，有些列表只改变显示位置，并不代表客户端已经自动切换到第一条。

显示为空、超时或失败的结果也不应简单按一个固定数值处理。空白可能表示尚未测试，失败可能来自暂时网络问题，旧结果则可能是在另一种网络下产生。需要比较时重新执行相同测试，并在记录里注明环境，而不是给旧结果赋予长期含义。订阅更新后新增的条目也应重新测试，不能因为它排在熟悉的分组里，就认为它已经通过之前那轮验证。

保留测试记录时，重点记录现象而不是堆积数值。例如“同一网络下连续出现握手错误”“订阅更新成功但某条目连接超时”“Direct 正常、Proxy 失败”都能指向下一步检查。公开反馈时删除地址、认证字段和账户标识，仅提供模式、协议类型与错误阶段。若需要完整的首次连接检查流程，可返回使用教程的验证步骤，将单条服务器先恢复到可理解的基线状态。

删除与备份：保留可恢复的管理状态

区分删除服务器、订阅与 Config

删除前先确认对象。删除单个服务器通常针对一份连接参数；删除订阅条目会影响后续更新关系，并可能连同其生成内容一起处理；删除 Config 则针对规则与相关配置，不等同于移除服务器。不同平台的确认对话框与关联处理可能不同，因此应阅读实际提示，而不是按记忆直接确认。尤其在多订阅同名的情况下，先看归属再操作，避免删掉仍在使用的来源。

订阅生成的服务器可能在下次更新时重新出现，所以“想长期移除一条”与“临时让列表简短一点”是不同需求。若只是暂时不使用某条目，未必需要删除整个订阅；若确定某份重复订阅不再保留，则先验证另一份仍能更新，再处理重复来源。删除手动条目前应确认原始参数还能找回，因为它不一定存在可重新拉取的订阅地址。清理完成后再做一次连接验证，确认当前选择没有指向已移除条目。

按信息类型建立备份清单

完整恢复所需的不只是列表截图。至少应区分订阅地址、手动服务器参数、Config 文件以及必要的自定义设置。订阅地址可以重新取得服务器列表，但未必保留你在本地改过的备注与排序；规则文件可以恢复分流逻辑，但不一定包含所有服务器认证信息；截图便于辨认界面，却不能可靠恢复长密码、密钥或隐藏字段。先明确每种备份覆盖什么，再判断是否足以完成迁移。

如果当前界面提供导出或备份功能，使用前阅读实际导出范围，并检查生成文件是否包含敏感信息。不能仅凭文件名称里有“备份”就认为所有数据都已保存。涉及密码、UUID、订阅令牌或 WireGuard 私钥的内容，应放在访问受控、可加密保存的位置，避免留在公开相册、共享下载目录或可被他人读取的文档中。用于日常查阅的管理清单与完整凭据备份最好分开存放。

恢复时按依赖顺序逐层验证

迁移到另一台设备时，先确认 Shadowrocket 已按对应平台的渠道获取，再恢复订阅与手动服务器，接着恢复 Config，最后检查 Global Routing、DNS 和按需连接等设置。不要导入后立即启用所有自动行为，先手动连接一个已确认条目，再验证规则。iPhone / iPad 的系统要求以 App Store 页面标注为准；其他平台获取与安装放行步骤统一查阅安装说明，不在备份流程里重复尝试安装修复。

恢复订阅后需要重新执行更新，恢复服务器后需要重新连接测试，恢复 Config 后需要核对当前选中状态。旧设备的延迟缓存、排序与最近使用项不应被当成新设备上的有效测试结论。若恢复后只有部分内容出现，先检查备份范围与导入类型，避免把缺失全部归因于应用异常。对于已经更换过的认证信息，应以现有资料为准，旧备份只能帮助解释历史状态，不能保证仍具备连接权限。

发现订阅地址或认证资料意外公开时，仅删除本地条目并不能使已经泄露的信息失效。应根据原有账户管理方式撤销或更换对应凭据，再更新客户端中保存的内容，随后清理旧备份与临时副本。日常维护结束后，留下简短的变更记录：处理了哪个订阅、保留了哪些手动条目、验证采用什么模式。记录不包含凭据，也不需要编写复杂日志，却能在下次更新或迁移时说明当前状态从何而来。

本页的管理闭环到此完成：先识别内容，按入口导入，再验证连接；通过可控更新维护列表，通过归属与命名减少混淆，最后用经过验证的备份保留恢复能力。需要从头操作时使用快速上手教程；需要解释规则如何影响连接时查阅设置说明；单条分享链接的识别问题则转到链接格式文章继续核对。