本文适合已经把多个自有订阅导入 Shadowrocket（小火箭）的用户。操作重点是先在 Settings → Subscribe 管理订阅来源，再回到 Home 测试和整理服务器条目；清理时以来源分组为边界，重复项则按协议、主机、端口和认证参数逐项核对。
先区分订阅来源、服务器条目与当前连接
多订阅管理容易混乱，通常是因为三个层级被当成了同一件事。订阅来源是一条由用户已有服务商提供的 URL；服务器条目是订阅更新后写入 Home 列表的具体记录；当前连接则是 Home 中被选中并交给系统 VPN 配置使用的那一条。删除其中一个层级，不一定会自动改变另外两个层级。
例如，一条订阅可以生成十几条服务器记录，其中只有一条处于选中状态。单独删除某个服务器记录，并不等于删除订阅来源；如果来源仍然存在，下次更新时该记录可能再次出现。反过来，移除订阅来源后，也应检查与该来源关联的本地条目是否仍被保留。
按来源建立分组，先把订阅名称写清楚
进入 Settings → Subscribe 后，先逐条核对已经保存的订阅。名称应能说明来源和用途，不宜只保留“订阅 1”“备用”之类难以追溯的文字。多个来源出现同名服务器时，来源名称是判断重复项归属的第一条线索。
录入新来源时，只使用用户自己已经取得的订阅地址。用于说明格式的假值可以写成 https://example.com/sub?token=xxxx。URL 中的查询参数通常承担身份或授权作用，复制时要保留完整字符串，不要手动删去 ?token=xxxx。
主用订阅
- 入口
- Settings → Subscribe
- 名称
- 来源 A · 日常
- URL
- https://example.com/sub?token=xxxx
- 更新检查
- 确认时间与条目数量变化
名称承担来源标识，不要用服务器显示名代替订阅名称。
备用订阅
- 入口
- Settings → Subscribe
- 名称
- 来源 B · 备用
- 更新方式
- 按需要手动更新
- 异常记录
- 超时、空结果或认证失败
先确认备用来源可以正常更新，再清理旧来源生成的条目。
- 打开 Settings，进入 Subscribe，记录当前存在的每条来源及其名称。
- 依次触发更新，每次只处理一个来源，观察 Home 中对应分组或条目数量是否变化。
- 发现来源名称不清楚时先重命名，再进行删除或去重，避免把两个不同来源混在一起。
- 更新完成后回到 Home，检查选中的服务器是否仍属于准备保留的来源。
结论：先整理来源，再整理服务器
如果直接从 Home 删除同名条目而不检查 Settings → Subscribe，下一次更新可能重新写入这些记录。先给来源命名并确认更新结果，可以减少重复清理。
按延迟排序前，先完成同一轮 Connectivity Test
延迟排序只有在测试条件一致时才有参考意义。先保持同一网络接入方式，在 Home 对准备比较的服务器执行延迟测试或 Connectivity Test，再依据本轮结果排序。不要把昨天在 Wi-Fi 下得到的数值与今天在蜂窝网络下得到的数值直接混排。
测试结果可分为三类：显示具体毫秒数，表示探测目标在本轮有响应；显示 timeout，表示在测试时限内没有得到有效响应；没有结果或持续处于测试状态，则应检查当前网络、订阅参数和应用权限。一次 timeout 不足以判断服务器永久失效，可间隔一段时间复测两次。
- 低延迟且可连接：保留在常用分组，实际打开目标服务确认连接结果。
- 延迟较高但稳定返回：可移入备用范围，不要仅凭毫秒值直接删除。
- 连续 timeout：核对协议、主机、端口、TLS 与认证字段，再判断是否清理。
- 名称相同但延迟不同：检查主机和端口；显示名相同不等于服务器参数相同。
可达记录示例
- 协议
- Trojan
- 主机
- edge-a.example.com
- 端口
- 443
- 测试结果
- 186 ms
数值仅是记录格式示例，应以设备当次测试显示为准。
待复核记录示例
- 协议
- Hysteria2
- 主机
- edge-b.example.com
- 端口
- 443
- 测试结果
- timeout × 3
连续三轮超时后，仍要先检查 UDP 可达性和服务端参数是否已变更。
测试期间还要确认 Global Routing。Proxy 会让流量统一经过当前代理服务器，Direct 直接连接，Config 按当前配置文件中的规则处理，Scene 则依据场景设置工作。如果停在 Direct，网页能够打开并不能证明所选服务器已生效；如果使用 Config，则应检查 DOMAIN-SUFFIX、GEOIP、IP-CIDR 与 FINAL 的匹配顺序。
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY删除失效订阅时，以来源为批量清理边界
需要批量处理失效条目时，最清晰的边界是订阅来源，而不是服务器显示名。先在 Settings → Subscribe 确认某个来源确实已经停止更新、返回空内容或不再使用，再移除该来源。执行删除前，记录其中仍需保留的手动服务器，避免把来源条目与手动添加的条目混为一组。
具体按钮文字可能随 App Store 当前页面对应的应用界面调整，但判断顺序不变：打开订阅记录、核对 URL 和名称、确认准备删除的来源、阅读删除确认框，再回到 Home 检查关联条目。若确认框询问是否同时处理本地服务器，应根据是否还需要这些条目选择，而不是连续快速确认。
- 在 Home 记下当前选中服务器的协议、主机和端口，必要时先切换到准备保留的服务器。
- 进入 Settings → Subscribe，打开目标来源并执行一次更新，确认失败不是临时网络波动。
- 核对订阅名称和完整 URL，确保删除对象与记录的失效来源一致。
- 执行来源删除，并按确认框说明决定是否同步处理该来源生成的本地条目。
- 返回 Home，重新执行 Connectivity Test，检查列表中是否还存在原来源的残留记录。
结论：批量删除应从订阅记录开始
按来源移除比按显示名逐条删除更容易复核，也能避免下一轮订阅更新把同一批服务器重新加入 Home。
去掉重复节点，要比较连接参数而不是名称
重复节点最常见的表现是两个订阅生成了相同显示名，但显示名本身不能作为唯一判断依据。一个名称可能指向不同主机，也可能是同一主机的不同端口。真正的重复项应至少比较协议类型、服务器主机、端口和认证参数；启用 TLS 的协议还要比较 SNI、ALPN 等字段，使用传输层设置时还要检查 path、host 或其他对应值。
Shadowsocks 应重点比较主机、端口、加密方式和密码；VMess 与 VLESS 还需要核对 UUID、传输方式和 TLS 设置；Trojan 要比较密码与 SNI；Hysteria2 需要核对主机、端口、认证信息及相关 TLS 字段；WireGuard 则应比较公钥、Endpoint、Allowed IPs 和本地地址。参数不同的记录即使名称相同，也不应直接当作重复项删除。
可以判为重复
- 协议
- Trojan
- 主机
- edge.example.com
- 端口
- 443
- SNI
- edge.example.com
- 认证
- 完全一致
主要连接参数一致时，再根据来源更新可靠性保留其中一条。
不能仅按名称合并
- 显示名
- Tokyo 01
- 记录 A
- edge-a.example.com:443
- 记录 B
- edge-b.example.com:8443
- 协议
- 均为 VLESS
- 结论
- 主机和端口不同
显示名相同只是标签重复，不代表底层连接目标重复。
去重键示例：
协议 | 主机 | 端口 | 认证参数 | 传输方式 | TLS/SNI
Trojan | edge.example.com | 443 | password-A | TCP | edge.example.com
VLESS | edge.example.com | 443 | uuid-B | WS | cdn.example.com如果两个来源确实包含同一条服务器，应优先保留更新成功、来源标识清楚且参数完整的记录。删除另一条后立刻更新其原订阅进行验证：如果重复项再次出现，说明它仍由该来源维护。此时可以保留来源并接受重复显示，或在服务商提供的订阅管理范围内调整内容；不要通过随意修改密码、端口或 UUID 的方式制造表面差异。
更新订阅后，检查 On Demand 与规则状态
订阅整理完成后，应进行一次闭环验证。先在 Home 选择保留的服务器，再执行 Connectivity Test，随后确认 Global Routing 所处姿态。如果平时使用 Config，还要打开当前配置并确认规则按从上到下的顺序匹配，最后由 FINAL 处理未命中的请求。
如果启用了 On Demand，入口位于 Settings → On Demand。该设置可以依据网络条件触发连接或断开，测试多订阅时可能让连接状态自动变化。排查期间应记录当前 On Demand 条件，包括 Wi-Fi 与蜂窝网络下分别采取的动作，避免把自动切换误判为服务器失效。
订阅更新后，刚删除的服务器又出现了？
进入 Settings → Subscribe 找到它所属的来源。只删除 Home 中的条目不会改变订阅内容；需要整批移除时，应处理对应来源并再次检查本地列表。
两个节点名称完全一样，应该删哪一个？
分别打开记录，比较协议、主机、端口、认证参数、传输方式和 TLS/SNI。参数完全一致时，保留更新稳定且来源名称清楚的一条；参数不同则不要按名称合并。
延迟最低的服务器为什么无法打开目标页面？
先检查 Global Routing 是否处于 Direct，再运行 Connectivity Test。使用 Config 时继续核对规则顺序以及 FINAL 动作；延迟探测成功不等于所有应用请求都按预期分流。
订阅更新一直提示 timeout 怎么排查？
先确认设备网络和系统时间正常，再检查订阅 URL 是否完整。当前连接可用时，可在 Settings → Subscribe 核对 Update via Proxy 的设置，然后重新更新一次并观察是否返回条目。
整理列表后连接状态自己发生变化？
进入 Settings → On Demand，检查 Wi-Fi 与蜂窝条件下配置的动作。排查时同时记录 Home 的当前服务器、Global Routing 姿态和系统 VPN 状态。
- 确认 Settings → Subscribe 中只保留仍需使用且可以识别来源的记录。
- 确认 Home 当前选中服务器属于保留来源，并完成一次实际连接测试。
- 确认重复项已按完整参数核对，不以显示名作为唯一删除依据。
- 确认 Global Routing、Config 规则与 On Demand 条件仍符合原有使用方式。
- 后续每次新增订阅都先命名来源，再更新、测试和去重，避免列表重新失去边界。