Shadowrocket 节点管理

01Subscribe：导入已有订阅

先区分订阅地址与规则配置

Subscribe 用于从你已有的订阅地址读取服务器信息。一个订阅可以包含多个服务器条目，导入后通常按来源形成分组，后续更新仍依赖原地址。它与单个服务器不同：服务器条目保存一次连接所需的地址、端口和认证参数，订阅则保存取得这些条目的入口。先确认手中的内容是哪一种，再选择导入方法，避免把网页说明地址当成订阅地址。

Config 管理的配置文件主要承载规则及相关设置，不能因为同样使用网址，就把它与服务器订阅视为同一对象。某些完整配置也包含服务器或远程资源，但应按该文件的实际内容判断用途。若你拿到的是服务器订阅，应寻找 Type 为 Subscribe 的添加方式；若拿到的是规则配置，则到 Config 核对文件用途，不要用反复更换入口的方法碰运气。

按字段完成一次导入

在 Home 打开添加入口，进入 Add Server 后，将 Type 设为 Subscribe，填写已有的订阅地址，并为这一来源设置便于辨认的名称。界面布局可能随设备或应用调整，判断入口时以 Type 和字段名称为准。复制地址时应覆盖完整内容，尤其留意查询参数是否被聊天窗口换行、末尾标点或选中范围截断；显示成两行不一定表示地址里真的存在换行。

保存后，确认订阅分组是否出现，再检查组内能否看到服务器条目。导入过程需要先访问订阅地址，然后解析返回内容，因此“地址已保存”与“服务器已导入”是两个不同结果。若分组存在但内容为空，应检查更新提示和返回内容，不宜立即判断为服务器无法连接。服务器的认证与连通性，需要在确实取得条目后另行验证。

1. 确认复制的是自己的订阅地址，而不是账户页面或说明页面。
2. 选择 Subscribe，填写地址及可识别的名称，再保存。
3. 检查所属分组和条目是否形成，并核对其中一个服务器的参数。
4. 选中服务器，按使用教程完成模式选择和实际连接验证。

导入异常时按获取、解析、连接分层检查

订阅获取失败，先检查当前网络是否能够访问该地址，以及地址是否仍然有效。若请求返回的是登录页面、验证页面或错误提示，保存网址本身并不能让这些内容变成服务器列表。不要把账户密码填进无关字段，也不要为了测试而把订阅交给陌生网页。订阅地址常带访问凭据，应按私密信息保管，排错时只描述错误类别，避免直接展示完整地址。

获取成功但没有可用条目，重点检查内容格式与完整性。可以对照原始说明确认该地址是否用于 Shadowrocket 支持的订阅内容，而不是仅凭后缀判断。如果只有少数条目缺失，应先比较这些条目的协议及字段，不要清空整个分组。必要时保留当前可用内容，再尝试一次明确的手动更新，记录更新前后的差别，以免连续操作掩盖最初的问题。

导入完成后，应回到 Home 核对当前选中的服务器是否属于刚才的分组。应用不会因为你查看了某个订阅，就必然将其中某项作为当前连接。首次使用建议只验证一个已知条目，确认地址、模式和授权流程均正确，再处理整组排序。这样遇到问题时，能清楚区分导入失败、选错对象和连接失败三个环节。

02Add Server：手填服务器参数

以协议类型决定需要填写的字段

Add Server 适合你已经持有一台服务器的完整参数，或者需要核对自动导入后的具体字段。第一步是选择 Type，再填写该类型实际显示的项目。不能先填完某一种协议的字段，再仅修改类型名称：不同协议的认证方式和传输参数并不相同，切换类型后可能出现新字段，也可能留下需要重新确认的值。填写前应保留原始信息作为对照。

Address 通常填写服务器域名或 IP 地址，Port 填写服务端实际监听的端口。域名不应自行添加网页路径，端口也不能因为使用 TLS 就一律填写为某个常见值。服务器地址、TLS 的 Server Name 与传输层的 Host 可能相同，也可能各有用途；原始信息分别提供时，应分别对应，不要为了“保持一致”擅自把三个值替换成同一个名称。

认证、TLS 与传输是不同层次

Shadowsocks 需要匹配服务端的加密方法和密码；VMess、VLESS 通常需要核对 UUID，以及该配置要求的附加参数；Trojan 需要核对密码与 TLS 相关信息。这些内容不能互换。界面上能够保存，只说明字段通过了基本输入检查，不代表服务端会接受认证。若出现连接建立后很快断开，应优先重新对照原始参数，而不是随机更改加密或传输选项。

TLS 的作用与代理协议认证不同。Server Name 通常参与证书名称校验和服务端名称指示，不能把它当作备注填写。遇到证书错误，应检查名称、设备时间和原始设置是否一致，再确认服务端证书状态。关闭证书校验会改变连接的信任边界，不应被当成一般排错步骤。原始信息没有要求的选项，保持应用默认或先确认含义，避免引入第二个问题。

使用 WebSocket 等传输时，Host 与 Path 属于传输配置的一部分。Path 中的斜杠、大小写和查询内容都可能影响服务端路由，不能按普通备注改写。若原始信息同时列出 TLS、传输方式和路径，应逐项建立对应关系。Hysteria2、WireGuard 等类型也有各自的密钥或连接参数，不适合套用另一种协议的填写流程；只填写该 Type 实际需要且原始信息明确给出的值。

保存后先核对，再做单项验证

建议给手填条目使用能够辨认用途的备注，例如“手填验证”，不要在名称中放密码或完整密钥。保存后重新打开编辑页，确认类型、地址和端口没有误选，尤其检查复制内容前后是否包含空格。需要修正时一次只改一类参数，并记录修改理由。连续同时更改端口、TLS 和传输方式，即使最终连接成功，也很难知道真正解决问题的是哪一项。

自动导入的服务器也可以通过编辑页查阅参数，但订阅内的本地修改可能在后续更新中被覆盖。若需要做长期的本地调整，应先确认应用是否支持将其复制为独立条目，并在名称中区分原条目与测试副本。不要在未经验证时直接改动唯一可用的服务器。关于已有信息的其他导入入口，可参阅添加节点的四种入口说明。

03Scan QR Code 与剪贴板导入

二维码只是信息载体，不是另一套参数

Scan QR Code 读取的是二维码中编码的文本。它可能是一条服务器分享链接，也可能是订阅地址，甚至只是普通网页。扫码后应检查识别结果和导入对象，不能因为成功识别了二维码，就认为服务器参数必然正确。二维码里的协议、地址和认证信息，与手填 Add Server 最终保存的内容具有对应关系；两种方式的区别主要在输入过程，而不是连接原理。

扫描前先确认二维码来自你已有的服务器或订阅资料，并避免把包含凭据的画面投放到公共屏幕。使用相机扫描时，按系统提示授予所需权限；如果未授权，应到系统设置核对，而不是重复点击扫描入口。若应用当前提供从相册识别的选项，可以选择保存的二维码图片，但应保留完整边界和清晰度，不要裁掉定位图形或用过度压缩的缩略图。

二维码无法识别时，先改善读取条件：确保画面完整、亮度适中、没有反光或明显模糊，再尝试调整距离。若同一二维码始终失败，而原始文字仍在，应改用文字导入或按参数手填，避免反复截图造成信息进一步丢失。多个二维码拼在一张图片里时，应一次只识别一个；导入后核对名称与来源，防止重复添加而误以为内容已经更新。

剪贴板导入前先控制复制范围

从剪贴板导入适合你已经持有完整的服务器分享文本。先只复制需要的链接，再回到 Shadowrocket，使用当前界面提供的剪贴板导入入口；系统出现粘贴许可时，按实际操作确认。普通文字说明、聊天中的引号以及链接末尾的句号都不属于协议内容，混入后可能影响识别。不要为了方便把整段聊天记录复制进去，也不要期待应用自动判断所有附带说明。

批量文本应尽量保持一条链接一行，保留原始字符。显示换行与实际换行需要区分：长链接在屏幕上自动折行通常没有问题，手动插入的换行却可能把一条内容切成两段。若只能导入第一项，先检查其余条目是否使用相同的受支持格式，以及每项之间是否存在多余分隔符。遇到失败，应将一个条目单独验证，确认方法后再处理整批内容。

导入后的核对不能省略

无论扫码还是剪贴板，导入后都应打开一个条目的编辑页，对照 Type、Address、Port 和必要的认证字段。名称只是备注，不能用来证明内容正确；同名服务器可能对应不同地址，不同名称也可能指向同一地址。若识别结果是订阅，应检查它是否形成可更新的来源分组，而不是仅得到一次性服务器列表。需要长期更新的内容，必须保留正确的订阅关系。

导入结束后，可以用不含敏感信息的普通文字替换剪贴板内容，减少后续误粘贴的机会。不过，这不能保证其他设备或历史记录中没有副本；使用跨设备剪贴板时，也要考虑同步范围。保存在相册里的二维码同样应纳入隐私管理，尤其不要让其进入公开共享相簿。删除截图只能减少继续传播，已经暴露的凭据仍需通过原有管理渠道处理。

如果本次任务只是把已有信息迁移到另一台自己的设备，应先完成接收端的参数核对和连接验证，再清理中间文本与图片。不要在尚未确认新设备可用时，提前删除旧设备的唯一记录。完整迁移还涉及 Config、当前选中项和按需连接设置，不能只凭“扫码导入成功”就判断全部迁移完成；具体检查顺序见删除与备份。

04分享链接格式与配置边界

先读前缀，再判断后续处理方式

服务器分享链接通常使用协议相关前缀，订阅地址则常见为 HTTPS 地址。前缀有助于判断内容种类，但不能单独证明整条内容有效。例如一条使用正确前缀的链接，仍可能缺少认证字段、端口或必要的传输参数。反过来，HTTPS 地址也不必然是订阅，它可能指向账户页面或普通文件。导入前应结合已有资料说明，确认它表示服务器、服务器集合还是配置文件。

这些前缀只用于辨认常见内容，不是完整的兼容性清单。某些协议的分享形式存在不同约定，同一协议也可能使用不同编码方式。应用是否能导入，取决于完整内容以及当前应用支持的参数组合，不能仅看协议名称。对于不熟悉的格式，优先保留原文，查看已有资料中的字段说明，再在 Add Server 中逐项核对，避免随意改写后失去参照。

编码、查询参数与备注各有含义

分享链接中的认证信息可能以编码形式保存。编码不是加密，也不意味着可以公开传播；能够读取链接的人可能恢复其中的服务器凭据。遇到看似难读的一串字符，不应随意补空格、调整大小写或删除末尾符号。部分格式对这些字符敏感，文本编辑软件的自动替换也可能改变内容。若需要比对，尽量使用原始纯文本，而不是凭截图重新抄写。

问号之后的查询参数可能决定传输方式、TLS 或其他连接行为，井号之后通常用于备注，但具体解释仍取决于该格式约定。百分号编码用于表达某些特殊字符，不能把它当作乱码删除。中文名称出现显示异常时，应先判断问题是否只涉及备注；如果地址和认证均正确，不要为了修复名称而重新编辑整条编码内容，可以在导入后单独调整显示名称。

服务器信息不会自动替你完成规则设置

导入一个服务器，主要解决“连接到哪里、怎样认证”的问题；规则配置解决“哪些请求使用哪种策略”的问题。两者需要配合，但不能互相替代。Config 中的规则通常按从上到下匹配，命中后使用对应策略，FINAL 用于前面均未命中的情况。以下是规则语法示例，仅用于理解结构，不包含服务器凭据，也不是可直接覆盖现有设置的完整配置。

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

示例中的 PROXY、DIRECT、REJECT 是策略关键字。DOMAIN-SUFFIX 与 DOMAIN 的匹配范围不同，不能只按字面把两者交换；GEOIP 涉及 IP 归属判断，也不等同于按网页语言分流。规则必须放在正确的配置章节中，并与当前 Global Routing 的选择一起检查。若使用 Proxy 或 Direct 姿态，不应再用 Config 中某一条规则来解释所有访问结果。

需要深入调整规则时，可继续阅读匹配顺序、FINAL 与策略说明。本章的维护重点是把信息分层保存：原始分享文本用于核对服务器，订阅地址用于后续更新，Config 文件用于规则与相关设置。给三类资料分别命名，比把它们合并成一段“通用链接”更容易排错，也能减少迁移时遗漏关键对象的情况。

05订阅更新策略与结果核对

更新的是远端内容，不只是时间标记

订阅更新会重新请求已保存的地址，并按照返回内容刷新相关服务器条目。更新可能带来地址、端口、认证或名称变化，也可能增加或移除条目，因此不应把它理解为单纯刷新显示。更新前先确认当前使用的分组和服务器，必要时记录其可辨认信息。对于正在排查的连接，保留更新前后的差异，比只记录“已经点过更新”更有帮助。

手动更新适合在你已经得知信息变化、发现原有条目异常，或需要核对导入结果时使用。自动更新则适合日常维护，但是否启用、有哪些间隔选项，应以当前 Subscribe 设置界面为准。不要假定所有设备都严格按固定时刻完成后台请求；系统调度、网络条件和应用状态可能影响执行时机。需要确认最新结果时，仍应查看本次实际更新反馈。

按请求、解析、替换三步理解结果

请求失败时，应先检查地址是否完整、访问凭据是否仍有效，以及当前网络是否能取得该地址。服务器连接失败与订阅地址访问失败是不同问题，两者未必使用同一条网络路径。若原本可用的服务器还在，先保留它们，不要因一次请求失败就删除分组重建。重建通常不能修复地址失效，反而可能使你失去原有的可用记录和排错线索。

请求成功后仍需确认返回内容能被解析。某些错误页面也会正常返回网页内容，但并非服务器列表，因此“能够打开网址”不能证明订阅有效。若更新后分组突然为空，或内容与预期差异很大，应停止连续刷新，回查原地址及其用途。排查时不必公开返回的完整文本，只需描述它是服务器内容、网页提示还是空响应，避免泄露访问凭据。

替换完成后，重新核对当前选中项。条目被改名或移除时，不能假定旧选择仍指向同一台服务器；同名条目的内部参数也可能已经改变。建议先检查一个常用条目的地址与协议，再执行一次测试和实际访问。如果只有某一项变动异常，将问题限制在这一项上；整组均异常时，才进一步检查订阅获取、账户状态或共同参数。

本地修改与订阅维护要分开

订阅内手动编辑的名称或连接参数，可能被远端内容覆盖，具体保留行为应以实际更新结果为准。若某项本地修改需要长期保留，不要只依赖记忆；记录修改字段及理由，并明确它属于本地例外。可以在应用支持的情况下保留独立副本作验证，但必须与订阅内原条目分开命名，以免下一次更新后误选测试副本，并把旧参数当作当前参数。

更新频率应与实际变化需求相匹配。短时间连续请求通常不会让错误内容变正确，还可能使反馈变得难以比较。一次更新失败后，先读取提示、检查网络和地址，再决定是否重试。若需要临时关闭自动更新以观察问题，应在记录中标明，并在原因确认后恢复原计划，防止临时排错设置长期遗留，导致以后误认为内容一直在正常刷新。

更新后的服务器列表并不是规则配置的更新记录。Config 若引用独立的远程规则或其他资源，应按各自入口维护；更新 Subscribe 不代表这些资源已经同步。最终检查应覆盖三个对象：服务器是否为预期内容、当前选中项是否有效、Global Routing 与配置是否仍符合使用目的。三项都核对，才能把“订阅维护完成”与“当前连接可用”准确对应起来。

06多订阅分组与命名整理

以来源分组，以用途命名

同时管理多个已有订阅时，首先保持来源边界清楚。每个订阅应有可识别的名称，用于区分它从哪里更新，而不是把全部服务器混成一份没有出处的列表。名称可以包含设备用途或自定义分类，但不应包含密码、访问令牌和完整订阅地址。一个好的来源名称应让你在几天后仍能判断其维护入口，而不是只在刚导入时看得懂。

服务器备注与订阅名称承担不同任务：订阅名称标识一组内容的更新来源，服务器备注帮助识别具体条目。建议采用简单、稳定的命名顺序，例如先写自定义用途，再保留原有可辨识标签。不要把临时测试结果写进长期名称，因为网络表现会变化，名称却容易被当作事实。对于远端生成的备注，还应考虑下一次更新可能恢复原名，不宜依赖本地改名建立唯一记录。

重复条目要比较内容，不能只比较名字

两条同名服务器不一定重复，两个不同名称也不一定代表不同连接。判断是否需要清理时，应比较协议、地址、端口及关键传输参数，同时保留认证信息的私密性。一个来自订阅、一个来自手填的条目，即使当前参数相同，其维护方式也不同：前者可能持续更新，后者保持本地保存值。删除前先明确你希望保留哪一种关系，而不只是保留哪一个名字。

如果某个分组长期没有使用，先确认其中是否仍有当前选中项，或是否被配置中的策略组按名称引用。涉及名称匹配的配置，改名与删除都可能影响后续选择。界面中的列表排序只改变查找顺序，不应被当作修改规则优先级的方法。规则从上到下的执行顺序属于 Config 内容，与 Home 中服务器显示在前面还是后面并不是同一层概念。

多设备整理保持可解释，不追求表面一致

在 iPhone 与 iPad 上管理相同资料时，可以使用一致的来源名称，便于跨设备核对，但不要假设一台设备上的服务器、选中状态和 Config 会自动完整出现在另一台。是否同步以及同步范围，应以应用实际设置为准。即便两台设备显示相同名称，也要分别确认导入内容和当前配置；相同备注不构成参数一致或连接状态一致的证据。

订阅整理宜采用小批次操作。先处理一个来源，完成命名、重复检查、测试与备份后，再处理下一个。若一次同时删除多个分组、修改备注并切换配置，之后遇到连接异常很难回到明确的起点。对于准备停用的内容，可以先记录其来源及用途，再确认当前连接不依赖它，最后执行删除；暂时不用与永久废弃，应在维护记录里有所区分。

维护记录不需要保存所有秘密字段。通常记录分组名称、导入方式、配置用途、修改原因及验证结果，就足以帮助排错。服务器凭据和完整订阅地址应放在受保护的位置，不应与公开笔记混放。需要向他人描述问题时，可以说明“某一订阅更新后出现重复名称”或“手填副本仍可连接”，而不是直接发送整组导出内容。

整理完成后，回到当前使用场景检查，而不是只观察列表是否整齐：选中预期服务器，确认 Global Routing，打开所需网页，并在必要时查看连接记录。若列表清理后出现异常，应先恢复最近一次改动，而不是立即修改 DNS 或全部规则。让每次整理都可追溯、可验证，才能避免把日常维护变成范围不断扩大的连接排查。

07Connectivity Test、延迟与排序

测试结果只回答它实际测量的问题

Connectivity Test 用于辅助判断服务器相关连接情况，但结果必须结合当前选择的测试方式解释。不同方式可能检查不同层次：能否建立连接、能否通过代理完成请求，或者能否访问指定测试目标。测试项目与选项以应用界面为准。看到一个时间结果，只能说明那次测试完成了相应过程，不能据此推断所有网站、所有协议和持续传输都正常。

测试结果会受到当前网络、目标地址、服务器状态及测量时机影响。比较服务器时，应尽量保持测试方式和网络条件一致，不要把不同设备、不同时间或不同测试目标的结果混在一起排序。一次异常也不一定代表持续故障；可以间隔后复测，并与实际使用结果对照。相反，偶尔一次成功，也不能覆盖频繁断开的事实，应记录问题是否能够重复出现。

按连通、认证、解析、规则逐层定位

如果连基本连接都无法完成，先核对地址、端口以及当前网络能否到达服务器。能够建立传输连接但代理请求失败，再检查认证、TLS 和传输参数。若代理请求正常、部分域名无法打开，继续检查 DNS 与规则，而不是立即替换整份订阅。这样的检查顺序能让每一步只处理一个层次，避免把服务器问题、域名解析问题与路由选择混为一谈。

测试正常但网页打不开时，需要确认实际请求走的策略。Global Routing 为 Config 时，规则从上到下决定请求采用哪种策略；Proxy 与 Direct 则用于不同的整体路由姿态，不能只凭服务器测试结果判断网页走向。检查时先明确当前姿态，再看请求是否使用预期服务器。若有连接记录，应结合域名、策略和错误信息阅读，不要只盯着一个延迟数值。

排序帮助查找，不构成长期质量结论

按测试结果排序，可以把本次响应较快的条目放到便于选择的位置，但不应将这个顺序理解为稳定的质量排名。响应时间、持续吞吐和连接稳定性不是同一指标，适用的访问目标也可能不同。测试失败的条目应先检查是否缺少参数或暂时不可达，不必立即删除；如果它属于订阅，下一次更新也可能改变其实际连接信息。

需要验证一个条目时，建议选中它后完成一次完整的实际访问：确认系统连接状态，打开目标网页，再检查结果是否符合预期。对只有部分页面异常的情况，应分别比较可访问与不可访问的域名，并保持服务器和模式不变。每次只改一个条件，才能判断是换服务器有效，还是规则、解析或目标本身的差异造成了结果变化。

记录测试时保留必要上下文：使用的网络、测试方式、当前服务器、Global Routing 及可重复的现象。错误提示中的域名和参数可能包含私密信息，对外说明前应做遮盖。若只是某一目标异常，不要用批量测试结果替代对该目标的检查；若整个网络都不可用，则先确认设备基础联网正常，再回到 Shadowrocket 的服务器与配置层面。

排序后还应核对当前选择，因为列表位置改变并不意味着应用一定切换到了第一项。维护结束时保留一个明确的当前状态：使用哪个来源的条目、采用什么模式、是否已经恢复临时修改。这样下次出现问题时，可以从已知条件开始，而不是先猜测上一次测试留下了哪些变化。首次验证的完整步骤仍以使用教程为主线。

08删除、备份与换设备恢复

先确认删除对象的层级

删除一个服务器、删除一个 Subscribe 分组和删除一个 Config 文件，影响范围不同。单个服务器关系到某个连接条目，订阅分组关系到一组内容及其更新入口，配置文件关系到规则与相关设置。操作前先读清确认提示，再判断当前连接是否依赖该对象。不要因为界面上都使用删除操作，就认为它们具有相同的后果，尤其避免在排错时连同规则配置一起清理。

订阅内删除的条目，可能在下一次更新时重新出现，因为远端列表仍包含它；本地独立条目则不具备同样的恢复来源。若目的是长期排除某个条目，应先了解应用现有的筛选或管理选项，而不是不断重复删除。删除分组后想恢复，通常需要原订阅地址及有效访问条件；仅记住一个服务器名称，不能重建原有的完整订阅关系。

备份按来源、参数、配置分别检查

备份应覆盖你真正需要恢复的对象。订阅地址用于重新获取服务器，独立服务器需要保留完整参数，Config 需要保留文件及其相关依赖。当前选中项、Global Routing 和 On Demand 等设置，还应按实际需要记录。应用提供的导出、分享或备份功能，其覆盖范围以当前界面说明和导出内容为准，不能假定任何一种导出都包含全部状态。

1. 列出已有订阅来源，确认原地址仍可从受保护的记录中找回。
2. 核对手填服务器是否另有完整参数，区分它们与订阅副本。
3. 保存需要迁移的 Config，并检查其远程资源是否仍可取得。
4. 记录当前模式、选中条目及必要的按需连接设置。
5. 在恢复端验证后，再决定是否清理旧设备与临时导出资料。

导出内容可能包含密码、UUID、私钥或订阅访问凭据，应选择受保护的保存位置，并限制可访问范围。普通公开网盘链接、群聊文件和公开笔记都不适合保存完整连接资料。若使用系统文件存储或设备备份，也要确认自己的账户与设备访问保护。备份的目标是可恢复，而不是多复制几份；散落在多个位置且无法判断新旧的文件，反而增加误用和泄露风险。

恢复应用与恢复连接资料是两件事

换机或重装后，先通过 App Store 恢复已购 Shadowrocket，再处理订阅和配置。应用购买记录与服务器资料属于不同对象，重新取得应用不代表你的全部连接信息已经恢复。购买与重新下载的具体步骤见已购恢复说明；设备系统要求、购买适用性及兼容性均以 App Store 页面标注为准，不应根据另一台设备的状态直接推断。

在新设备上恢复时，先导入一个来源或一台服务器，完成参数核对和连接验证，再继续恢复其他内容。恢复 Config 后检查它是否成为当前选用配置，并确认规则引用的名称、资源与服务器关系仍成立。若旧设备中做过本地例外修改，应按维护记录逐项恢复，而不是把旧测试副本全部导入后再猜测哪个是最终结果。小批次恢复更容易定位遗漏。

删除前留出验证闭环

迁移完成的标准应是实际可用，而不是导入数量看起来一致。至少确认当前服务器能够连接、常用访问目标正常、Global Routing 符合预期，并检查 On Demand 是否仍按你的使用目的设置。连接授权可能需要在新设备重新确认，应阅读系统弹窗后操作。不要在验证尚未结束时抹掉旧设备中唯一可用的独立参数，也不要把截图中的名称当成备份本身。

如果完整订阅地址或服务器凭据已经误发，仅删除消息或本地文件不能使已传播的副本失效。应通过原有的账户或服务器管理渠道处理相关凭据，再更新设备中保存的信息，并重新验证连接。处理过程中保留必要的变更记录，但不要把旧秘密继续写进排错笔记。后续备份也应重新整理，避免恢复时再次导入已经失效或暴露的内容。