Subscribe：建立订阅与服务器的归属关系
订阅是可再次请求的远程资源地址，服务器条目是客户端实际连接时使用的一组参数。两者不能只凭外观相似就混为一谈：订阅更新可以返回多条服务器信息，单条分享链接通常只描述一个服务器。导入之前先判断拿到的是哪一种资料，能避免把订阅地址填进服务器地址栏，也能解释为什么某些条目会在更新后重新出现。
先确认资料类型，再进入 Subscribe
从你的服务商处获取订阅后，先保留原始文字，不要直接改写其中的查询参数。订阅通常表现为网页地址，但“能够在浏览器打开”不是判断标准；登录页面、帮助页面和订阅资源可能具有相同的域名。应核对服务商给出的用途说明，确认该地址用于 Shadowrocket 订阅，而不是账户管理或普通说明页面。
在 Home 的添加入口中选择 Subscribe 对应的订阅类型；部分界面会在 Add Server 的 Type 内列出 Subscribe。进入后把完整地址粘贴到 URL，填写便于辨认的备注，再保存并触发更新。不同平台的入口排列可能不同，判断依据应是 Subscribe 和 URL 的用途，而不是某个按钮必须位于屏幕的固定角落。
备注建议记录资源归属和使用目的，例如“个人订阅／日常”“个人订阅／备用”。不要把完整订阅地址、账户密码或访问凭据写进备注。备注主要供用户整理列表使用，不能代替服务端参数；修改备注不会自动改变实际服务器地址，也不会使过期凭据重新有效。
用条目和更新结果确认导入完成
保存订阅后，观察其下是否出现服务器条目，再查看更新是否报告错误。出现了一个订阅名称，不等于已经取得有效服务器。若列表为空，应依次检查地址是否完整、当前网络能否请求该资源、服务端是否返回了客户端可识别的内容。先记录错误信息，再决定是否需要重新添加，避免连续创建多个相同订阅。
订阅中的服务器名称通常由远端数据决定。更新后名称、数量、排列或具体连接参数发生变化，并不必然说明客户端丢失资料；也可能是远端删除了旧条目或调整了配置。需要追踪变更时，先记录更新前后的订阅名称和条目名称，再比较归属，不能只凭列表总长度判断某次更新是否正常。
订阅导入成功后，还需要选择可用服务器并完成连接验证。订阅负责提供服务器资料，Config 中的规则负责决定流量如何处理，二者是不同层次。只有服务器信息而没有合适的 Global Routing 设置，实际访问路径仍可能与预期不同；只有规则文件而没有可连接的服务器，也不能完成 PROXY 连接。
| 资料类型 | 导入后的主要对象 | 后续维护 |
|---|---|---|
| Subscribe URL | 订阅及其服务器列表 | 请求原地址更新 |
| 单条分享链接 | 独立服务器条目 | 重新导入或手动编辑 |
| Shadowrocket .conf | Config 配置文件 | 维护规则与配置内容 |
订阅地址按凭据保管
订阅地址可能包含能够识别账户的参数，应当按敏感资料保管。复制到聊天、截图或问题描述之前，需要遮住完整路径中的凭据以及查询参数。只隐藏域名通常没有意义，因为真正允许读取资源的内容可能位于后半段。求助时可提供协议类型、错误类别和发生步骤，不需要公开可直接访问的订阅地址。
若怀疑地址已经泄露，应从你的服务商处确认是否能够重置订阅凭据，再替换客户端保存的 URL。仅修改本地备注或者删除一个服务器条目，不会让旧地址失效。替换后先更新并测试一个条目，确认新的资源能够工作，再清理旧订阅，避免在资料尚未验证时失去原来的可用配置。
Add Server：按协议填写服务器参数
手动添加适用于已经掌握完整服务器信息，或者需要核对某个字段的情况。进入 Add Server 后，先选 Type，再填写对应字段。不要先把所有资料塞进默认表单，再切换协议类型；不同协议的必填项和可用选项并不相同，切换类型后还应重新检查原先填写的内容是否仍然适用。
地址、端口与身份凭据分开核对
Address 一般填写服务器域名或 IP 地址，不包含网页路径，也不应连同协议前缀一起粘贴。Port 应与服务端监听端口一致，不能把管理网页端口当成代理端口。对于 IPv6，使用表单单独提供的地址和端口字段，不要自行套用网页地址的拼接方式；若原始资料只提供完整链接，优先使用链接导入。
身份凭据必须按协议核对。Shadowsocks 常见的是加密方法与密码，VMess 和 VLESS 使用相应的用户标识，Trojan 使用其认证信息。看到一长串字符并不能判断它应填入哪个字段。复制后注意首尾空格、换行以及字符大小写，尤其不要把界面自动换行误认为原始凭据中真的包含换行。
参数说明若只给出“密码”和“地址”，仍可能不足以恢复一个完整连接。服务端可能还要求特定传输方式、TLS、SNI、路径或其他选项。此时应从你的服务商处取得完整资料，而不是靠逐个切换开关试出一组看似能保存的值。表单能够保存，只说明输入形式被接受，不代表服务器认可这组参数。
| 参数组 | 核对内容 | 常见混淆 |
|---|---|---|
| Address / Port | 连接目标与监听端口 | 把网页地址当服务器地址 |
| 认证参数 | 密码、用户标识或密钥 | 填入其他协议的凭据 |
| TLS / SNI | 是否启用及验证名称 | 把 SNI 当成 Address |
| 传输参数 | 传输方式、Host、路径 | 遗漏路径或改变大小写 |
TLS 与传输参数不是同一个开关
TLS 负责连接加密及相关验证，传输参数描述协议数据通过何种方式承载。启用了 TLS，不代表可以省略传输路径；填写了 Host，也不代表 SNI 已经正确。若资料给出的 Address、Host 和 SNI 不一致，应分别放入对应字段，不能为了“统一”而把三个位置都改成同一个域名。
证书验证失败时，先核对设备时间、SNI、服务器证书状态和资料是否已经变更。不要把关闭证书验证当成通用修复步骤。绕过验证可能掩盖连接目标错误，也会降低对服务器身份的确认能力。若必须分析特定测试环境，应清楚记录改动，测试结束后恢复原先的验证设置。
WireGuard 等协议使用不同的密钥和接口参数，不能套用普通用户名密码表单。私钥属于敏感凭据，不应放进截图或普通备注。涉及本地地址、对端公钥及路由范围的字段，应作为一组核对；只替换其中一个值，可能导致握手成功但流量无法到达预期目标。
保存后先做最小验证
建议给手填条目添加明确备注，标出“手动”及用途，与订阅条目分开。保存后先选中该服务器，在固定网络下完成一次连接和访问测试；暂时不要同时切换规则文件、DNS 和多个传输选项。若失败，先回到原始资料逐项比较，把“参数错误”和“当前网络不可达”分成两条排查路线。
需要修改订阅内的服务器时，先考虑复制为独立条目再测试。直接编辑远端管理的条目，下一次更新可能重新写入原始参数，使本地改动消失。独立副本便于实验，但也意味着今后不会自动得到订阅中的新参数；测试通过后仍需记录其维护方式，不能长期把副本误当作自动更新的条目。
不同平台和界面语言可能显示略有差异的字段标签，应按字段用途与协议资料对应，不要照着其他协议的截图机械填写。常用界面词可参考界面英文对照。保留原始资料、一次只改一个参数、每次改动后验证，是比反复删除重建更容易定位问题的方法。
扫码与剪贴板：先识别内容再导入
扫码、剪贴板和手动填写只是不同的输入方式，不会改变服务器本身的权限或能力。二维码中可以包含单条分享链接，也可以包含订阅地址或普通文字；剪贴板同样可能存放任何内容。导入前应明确预计得到一个服务器、一条订阅还是一个配置文件，导入后再按这个预期核对结果。
Scan QR Code 的识别与权限
打开 Scan QR Code 时，系统可能要求相机权限。仅在准备扫描自己已有资料时授予所需权限；此前拒绝过权限的设备，可以在系统对应应用设置中检查相机访问。相机无法启动属于权限或设备层问题，并不说明二维码中的服务器失效，更不需要因此重建订阅。
扫描前让二维码完整出现在画面中，保留四周用于识别的边界，避免反光、遮挡和明显模糊。含有较长参数的二维码图案会更密集，缩得过小容易识别失败。若资料来自另一块屏幕，可适当放大显示；不要为了截取图案而把外围裁得只剩黑白方块本身。
二维码位于当前设备的图片中时，只有在界面提供从相册识别入口的情况下，才使用该入口。若当前界面没有相应选项，可以回到原始文字资料，通过复制链接导入。不要把“相册中能看到图片”与“应用能够识别此图”视为同一件事，也不要反复给与导入无关的系统权限。
剪贴板只保留完整的一条资料
从你的服务商处复制链接时，尽量使用其提供的复制功能，避免手指选中时漏掉开头或末尾。复制完成后立即回到 Shadowrocket 使用相应的剪贴板导入入口。系统若弹出粘贴访问提示，应在确认当前确实要导入时允许；拒绝后没有读取到内容，不代表原始链接格式错误。
聊天软件、邮件和文档可能在链接外添加引号、项目符号或说明文字。导入前应只保留真实链接，不把“点击这里”之类标题一起复制。某些长地址在屏幕上分成多行只是显示换行，复制后仍是一条；如果原始文本真的插入了空格或换行，就需要重新从原始资料复制，而不是随意删改字符。
一次只导入一份能够明确识别的资料，尤其是排查问题时。把多个订阅地址、多个单条链接和说明段落混在一起粘贴，可能只解析其中一部分，甚至得到与预期不同的对象。批量处理之前先用一个条目验证格式，再检查批量导入后的数量与归属，不能只看是否弹出了成功提示。
导入后分三层检查
第一层检查对象是否正确：预期是一条订阅，就应看到可更新的订阅对象，而不只是一个地址相似的服务器。第二层检查参数是否完整：打开条目查看 Type、Address、Port 以及必要的传输设置。第三层检查连接：选中条目后完成测试，并访问一个你本来就有权使用的目标服务。
若同一份资料手动填写可以连接、扫码导入却失败，应比较两者的字段，而不是立即判断二维码“失效”。可能是编码时省略了传输参数，也可能是分享格式与当前导入器的支持范围不同。保留两个条目用于对照，但用不同备注标记，避免在后续测试中误选了另一个。
反过来，如果扫码导入能够工作、手动输入无法工作，通常应先检查手填时遗漏的字段和特殊字符。分享链接可能包含不明显的 TLS 或路径选项，表面上只显示服务器名称。不要仅比较名称与端口就认定两条配置完全相同，应展开完整设置逐项检查后再清理重复项。
完成导入后，可以清除不再需要的剪贴板内容，并删除临时保存的凭据截图。若资料已经同步到其他设备或云端，清理本机不等于清理了所有副本。需要向他人描述识别问题时，提供错误提示、资料类型和操作入口即可；不要直接发送仍然有效的二维码或完整链接。
更新策略：控制时机并保留可回退状态
订阅更新是重新请求远程资料，不是简单检查本地列表是否还在。远端内容改变后，更新可能增加、删除或修改服务器，也可能调整备注和排列。合理的更新策略应同时考虑资料变化频率、当前网络是否能访问订阅资源以及本地是否存在需要保留的手动修改，而不是把更新次数越多当成越可靠。
第一次更新采用可观察的手动流程
首次建立订阅后先手动更新，观察请求是否成功、返回内容是否能够解析以及条目是否符合预期。确认这一过程正常，再根据界面实际提供的选项设置自动更新。不要在首次导入还未完成时同时启用多个自动行为，否则难以判断某次列表变化来自自己的操作还是后台更新。
更新前记录当前可用服务器的名称、所属订阅和正在使用的配置文件。对于重要的手动改动，可另存独立副本或进行本地备份。订阅中的条目由远端资料管理，本地更改不一定能够在刷新后保留。若某个参数必须长期不同于订阅原值，应明确把它作为独立条目维护，而不是依赖偶然没有被覆盖。
自动更新间隔应以实际需要为依据。资料长期稳定时，不必在很短时间内连续请求；正在处理服务端变更时，可以在确认资料已经调整后执行一次手动更新。高频重试可能触发远端限流，也会让错误记录重复堆积，却不能修复地址失效、认证失败或返回格式不匹配。
把网络失败和内容失败分开判断
请求超时通常需要检查当前网络与订阅地址的可达性；返回了内容但无法解析，则应检查资源是否变成登录页面、错误页面或另一种格式。若界面明确显示认证相关错误，应从你的服务商处核对地址和凭据是否仍有效。此时更换本地服务器备注，通常不会影响订阅请求结果。
订阅资源的访问路径与服务器连接路径不一定相同。服务器仍然能连接，不代表订阅地址也一定可访问；订阅能够更新，也不代表其中每一条服务器都能连接。应分别记录更新结果和连接测试结果，不要仅凭其中一个成功，就排除另一个层面的问题。
排查时一次只换一个条件，例如保持同一订阅地址，改用另一条自己可用的网络后重试。不要同时修改 URL、DNS、Global Routing 和多个服务器参数，否则即便恢复也无法知道原因。若更新会替换已有列表，应先确认旧资料已备份，再进行可能改变大量条目的操作。
| 现象 | 优先检查 | 暂缓操作 |
|---|---|---|
| 请求超时 | 当前网络与资源可达性 | 反复删除订阅 |
| 内容无法解析 | 返回格式及是否为错误页面 | 改写编码后的正文 |
| 更新后条目减少 | 远端变更与订阅归属 | 立即清空剩余列表 |
| 本地参数恢复原值 | 是否被订阅数据覆盖 | 持续编辑同一远端条目 |
更新完成后做一次小范围验收
成功提示之后，至少检查一个常用条目和一个备用条目，确认协议、地址以及连接表现没有异常。若服务器名称发生变化，应同时检查规则或选择记录中是否依赖这些名称。列表能够显示并不意味着原来固定使用的对象仍然存在，尤其在远端重命名或合并条目之后。
如果更新失败但旧条目仍然可以连接，可以暂时保留原状态，先处理订阅请求问题。不要为了清除错误提示而清空整个列表。若更新成功后反而无法连接，则应比较更新前后的具体参数，并从你的服务商处确认变更内容；仅恢复旧名称并不能恢复已经变更的服务器认证信息。
最后区分应用更新与订阅更新：前者改变 Shadowrocket 程序，后者改变远程服务器资料。应用更新的获取与安装说明见下载页。更新订阅不会自动升级客户端，重新安装客户端也不会自动修复一个失效的订阅地址；两条维护链路应分别验证和记录。
多订阅整理：用命名与归属减少重复
多订阅管理的核心不是把所有服务器混成一张更长的列表，而是能够回答每个条目来自哪里、何时会被更新、是否还有独立副本。先建立归属关系，再考虑排序和删除。只按名称去重容易误删用途不同的服务器，只按数量判断整理成果，也容易把仍在使用的独立配置一起清除。
给订阅和独立条目建立两层命名
订阅名称用于表示资料来源和用途，服务器备注用于区分具体连接对象。两层命名应避免互相替代：把全部服务器都改成同一个订阅名称，会失去条目之间的差异；只保留远端服务器名称、不记录订阅归属，则在多个列表出现相同名称时难以判断应该更新或删除哪一组。
可以采用“用途／资源组”的简短订阅名称，例如“日常／个人”“测试／个人”。对手动副本添加“手动”标识，并记录原订阅名称。无需在每个条目中写入完整日期和长篇说明，更不要把密码或订阅凭据作为命名的一部分；命名应帮助识别，而不是成为另一份敏感资料清单。
先完成一组订阅的更新和验证，再处理下一组。每增加一条订阅，都检查是否已有相同 URL，以及是否曾经把其中的服务器作为独立链接导入。重复来源不一定表现为相同名称，因为同一个订阅可以被多次添加并使用不同备注；需要回到订阅对象本身比较归属和地址。
判断重复不能只看服务器名称
两个名称相同的条目，可能使用不同地址、端口、认证信息或传输参数；两个名称不同的条目，也可能实际指向同一组连接参数。需要去重时，应先比较协议类型与目标地址，再核对端口、身份凭据和关键传输设置。凭据比较应在本机完成，不要为了对照而上传到公开表格或网页工具。
即使连接参数相同，也要考虑维护方式是否不同。一条来自订阅，另一条是独立手动副本，前者会随远端更新，后者不会。删除前应确定保留哪一种维护方式。若手动副本包含必要的本地调整，就不能只因为地址相同而删除；若它只是旧的临时测试记录，则可以在验证订阅条目后清理。
同一条订阅内删除某个服务器，下一次更新后它可能再次出现，因为远端列表仍包含该对象。这不是去重失败，而是本地删除与远端管理的边界不同。若界面提供针对订阅的筛选或管理选项，可按实际功能配置；没有相应选项时，应接受更新会恢复远端条目，不要靠反复删除维持列表外观。
按使用流程分组，而不是按一次测试结果分组
较稳定的整理依据是日常、备用和测试等实际用途。一次延迟结果只代表当时的网络条件，不适合作为永久归属。若把某次测试较慢的所有条目立即移出常用范围，下一次换网络后还需要重新整理。保留少量已验证的备用对象，比频繁重建整个列表更容易维护。
在界面提供排序或移动功能时，可以把常用订阅与常用服务器放到容易访问的位置；若当前界面不支持某种自定义排列，则使用清晰备注和分组查看，不必追求所有平台完全一致的显示顺序。远端更新也可能改变原始排列，因此不要把“排在第三行”当成识别服务器的可靠依据。
清理时先处理明确的重复订阅，再处理临时副本，最后处理长期不使用但仍可能需要恢复的资料。每一轮都只处理一类对象，并检查当前选中的服务器是否受影响。不要在连接仍依赖某组资料时直接删除整组，最好先切换到已经验证的保留对象，再进行清理。
完成整理后，抽查每个保留订阅能否更新、每个常用组是否至少有一个可用条目，并保存新的管理状态。更集中的分组与重复条目案例见多订阅管理文章。长期维护应追求归属清楚、改动可追踪，而不是让列表看起来最短。
延迟测试与排序：把测试结果放回连接场景
延迟测试用于观察某种测试方法下的响应，不等同于完整的应用体验。一个数值较小的条目，仍可能在实际访问时受到带宽、丢包、认证、TLS 或目标服务响应的影响；显示超时的条目，也需要结合测试目标和方法判断。先明确测的是什么，再决定结果是否足以影响服务器选择。
固定网络、测试方法与比较范围
在 Home 或相关测试入口使用 Connectivity Test 时，先查看界面实际提供的测试方式。不同方式可能只检查到服务器的某个阶段，也可能通过代理请求特定目标。只有使用相同方法、相同网络和相近时间取得的结果，才适合直接比较；不能把不同条件下保存的旧结果混在一起排序。
建议先测少量常用服务器，确认测试目标正常，再扩大范围。一次对很长的列表集中测试，可能受到本机网络和并发连接的影响。若所有条目几乎同时超时，应先检查设备网络、测试目标以及当前设置，而不是立即认定每个服务器都失效。先用一个已知可用条目做基线更容易定位问题。
单次结果容易受瞬时波动影响。对候选条目重复测试几次，关注结果是否稳定，以及是否经常出现超时，而不是只挑最小的一次数值。若更换了无线网络或移动网络，之前的排序就未必适用；应在当前实际使用环境重新验证，不把某次测试结果当成服务器的固定属性。
区分连到服务器与访问到目标
能建立到服务器的连接，不代表代理协议认证已经成功；协议认证成功，也不代表目标网站一定能够正常响应。排查时可以按网络可达、协议握手、目标请求三个层次记录。若某个阶段失败，优先核对与该阶段相关的参数，不要把所有失败都归结为“延迟太高”。
实际访问验证还需要检查 Global Routing。配置姿态 Config 按启用的规则决定策略，代理姿态 Proxy 用于让代理流量验证更直接，直连姿态 Direct 则不能用于证明服务器代理是否正常。这里的姿态名称对应界面词 Config、Proxy、Direct；测试后应恢复日常使用的姿态，避免临时设置长期保留。
| Global Routing | 诊断用途 | 需要留意 |
|---|---|---|
| Config | 验证实际规则分流 | 目标可能匹配 DIRECT 或 REJECT |
| Proxy | 集中检查代理连接路径 | 仍受系统及配置例外影响 |
| Direct | 观察直连条件下的表现 | 不能证明所选服务器可用 |
在 Config 下，某个目标如果命中 DIRECT，访问成功并不能证明选中的服务器已经工作；命中 REJECT 导致失败，也不能说明服务器本身不可达。应结合当前规则、连接记录和目标域名判断实际策略。相关规则关键字可查术语手册，不要为了一个目标的测试结果立即替换整套订阅。
排序只用于缩小候选范围
按测试结果排序后，先从表现稳定的几条中选择，再用实际需要的服务做验证。交互请求、长时间传输和持续连接对网络的要求不同，不能用一次短请求测试代替所有场景。也不要把不同服务器备注中自行声明的速度或用途，当成客户端已经测量并确认的结果。
保留一个稳定候选和一个已经验证的备用条目即可满足不少日常管理需求。切换到备用条目时，尽量保持同一 Config 和同一目标服务，便于比较。若同时更换规则、网络与服务器，虽然可能恢复访问，却会失去对故障原因的判断；之后遇到同类问题仍需重新排查。
如果测试正常但连接后部分应用失败，应继续检查 DNS、规则匹配、应用已有连接和目标服务限制，而不是不断重复排序。有些应用会复用先前建立的连接，修改设置后需要重新发起请求才能观察新路径。先结束测试目标的旧请求，再进行比较，避免把缓存表现误认作当前配置结果。
最后记录本次网络环境、测试方式、选用条目和最终访问结果，不必追求保存每一次数值。真正有用的记录是“什么条件下可用、什么条件下失败”。首次连接的常见停顿位置可结合入门常见问题查阅，再按本章的分层方法继续定位。
删除与备份：先确认恢复范围再清理
删除操作应从最小对象开始，备份操作则应先确认覆盖范围。一个服务器、一个订阅和一个 Config 文件是不同对象，删除其中之一通常不能替代对其他对象的管理。清理之前先明确希望移除的是显示条目、整组远端资料还是不再使用的规则，避免用“全部重来”处理一个局部问题。
删除前检查当前连接依赖
如果准备删除当前选中的服务器，先切换到已经验证的保留对象，并确认连接正常。若准备删除整个订阅，检查其下是否包含仍在使用的备用条目，以及是否有规则或选择记录依赖某些名称。删除不只是让列表变短，还可能改变之后能够选用的连接对象，因此应先处理依赖，再执行清理。
删除订阅内的单个服务器后，下次更新可能再次出现；删除订阅对象则可能连同其服务器一起移除，具体范围应以界面确认内容为准。执行前认真阅读确认提示，不要根据按钮文字长度推断影响范围。若目的只是暂时停用，优先考虑切换选择或使用界面提供的停用方式，而不是直接删除全部资料。
删除 Config 文件与删除服务器也应分开。当前使用的规则文件可能决定 DIRECT、PROXY 和 REJECT 的匹配，删除或替换后访问行为会变化，即使服务器参数没有改变。清理规则文件之前，先确认保留哪个配置作为日常使用项，并记录其中是否存在自己添加的局域网或域名规则。
备份清单比“有一个文件”更重要
备份至少应考虑订阅地址、独立服务器、当前 Config、重要本地改动以及需要重新设置的连接选项。不同导出入口可能覆盖不同对象：单条服务器分享不能代替整份配置备份，只有规则的 .conf 也不能自动恢复全部服务器。导出之后应核对文件或内容类型，不要仅凭文件已经保存就认定恢复资料齐全。
在 Settings 或对应对象的管理入口中，仅使用界面实际提供的导出、备份或分享功能。若没有完整备份入口，就分别保存需要恢复的对象，并制作一份简短清单。记录中说明每份资料的用途和恢复顺序即可，避免在普通笔记中重复明文保存所有密码，增加不必要的泄露面。
备份中可能含订阅凭据、服务器密码、用户标识或私钥，应保存到自己控制且有访问保护的位置。通过系统云存储同步时，还需要考虑账户保护和其他已登录设备。不要把备份当作普通附件长期散落在聊天中，也不要为了让别人检查格式而发送完整的有效配置。
按顺序恢复，再做连接验收
恢复时先确认客户端来自正确渠道，再导入订阅和独立服务器，随后恢复 Config，最后设置 Global Routing 与其他连接选项。iPhone / iPad 的正版核对包含开发者 Shadow Launch Technology Limited、官方图标和应用 ID 932747118；其他平台的获取说明及本站安装包入口统一见正版核验分区。
恢复订阅地址后应执行一次更新，再检查远端资料是否已经变化。旧备份里的服务器可能仍能导入，但认证信息或目标地址已经不再有效，因此“能够看到旧条目”不是恢复完成的标准。独立服务器则需要逐项确认是否仍适用，不能期待订阅更新自动修复那些已经脱离订阅管理的副本。
恢复完成后，依次检查常用条目、备用条目、当前规则和实际目标访问。若使用了 On Demand，还应检查自动连接行为是否符合预期，但不要在基础连接尚未验证时同时开启自动行为。发现问题时保留原备份，先在恢复后的资料上做小范围调整，避免覆盖最后一份可供对照的状态。
换机后也不必把全部历史资料长期保留。确认新设备能够更新、连接和使用日常规则之后，再清理旧设备中的凭据与临时导出文件。若旧设备不再由自己控制，应进一步从你的服务商处处理可能需要撤销或更新的凭据；仅删除本机应用，不能保证此前复制出去的地址和备份同时失效。
日常维护可固定为一个闭环：变更前备份，变更时只调整一类对象，变更后测试，确认稳定再清理。需要重新走完整连接主线时，返回快速上手教程；需要整理多份资源时，回到本页的多订阅章节。保留明确的恢复路径，才能让下一次更新和排错仍然可控。