管理多个订阅，先辨认来源，再整理名称与顺序，最后删除已确认多余的条目。本文适合已经持有自己的服务信息、Home 列表出现多个订阅组或同名节点的用户；按步骤操作后，可以区分订阅分组与策略分组、判断重复导入，并在清理后核对更新与实际连接是否仍然正常。
一、先分清订阅、节点与配置文件
Shadowrocket（小火箭）的列表变长，不一定是订阅数量增加。一条订阅可以包含多个服务器条目；同一地址被反复作为新订阅添加，也可能出现多个内容相似的组。开始整理前，应先在 Home 查看组标题与节点归属，不要只凭节点的显示名称删除。
Home 中按订阅来源形成的分组，用于组织服务器列表；Config 中的配置文件承载规则和策略等设置。把订阅组改名、折叠或移动，不等于改变请求的分流方式。配置中的策略组也不是 Home 订阅组，两者即使名称相似，职责仍然不同。
例如，Global Routing 使用 Config 时，实际请求会受到当前配置规则和策略的影响，不能把“某个节点移到了列表首位”理解为“所有请求都会使用它”。整理列表期间，保持原来的模式与配置不变，更容易判断问题究竟来自清理操作还是路由设置。
二、按来源建立分组记录，再统一命名
先为每个现有订阅建立一条简短记录：用途、来源是否仍有效、对应的 Home 分组，以及是否还需要保留。记录应保存在自己可控的位置，不要把完整订阅地址或认证内容放进共享文档。订阅 URL 的查询参数可能包含访问凭据，名称中也不应嵌入这些内容。
- 打开 Home，逐组展开查看，确认每组包含哪些服务器。先记录当前选中的条目及所属组，方便稍后重新选择。
- 从订阅条目的编辑入口查看 URL 与备注。不要误把某个子节点的编辑页面当成订阅设置；前者通常显示服务器地址、端口和协议参数。
- 为订阅使用能辨认用途的备注，例如“日常使用”与“备用验证”。如有多个相近来源，可以增加自定的简短编号，但不要写入密码或 token。
- 保存后返回 Home，确认变化落在预期的订阅组。若组内节点仍使用原来的名称，这是正常的：订阅备注与服务器名称是不同层级。
以下两张卡是整理记录示例，不是可导入配置，也不表示提供任何服务。实际操作应使用自己已有的信息；示例地址 https://example.com/sub?token=xxxx 是假值，不应提交更新。
订阅组记录
- 显示备注
- 日常使用
- 检查位置
- Home 中对应的订阅条目
- 来源确认
- 与自己保存的有效订阅 URL 核对
- 保留条件
- 仍在使用，且更新结果可确认
备注描述用途，完整认证信息只留在受控位置。
独立节点记录
- 显示备注
- 备用验证
- 来源确认
- 手动添加或单节点导入
- 比对字段
- 类型、地址、端口及认证参数
- 维护方式
- 单独核对，不依赖某条订阅更新
独立条目与订阅内节点可能指向同一服务器，删除前先确认用途。
三、调整 Home 顺序，不把排序当成策略
建议把常用来源放在前面，把备用来源放在后面，并折叠暂时不用的组。排序的目的是减少查找，不是根据一次延迟结果决定长期优劣。列表的显示顺序、当前选中的节点、配置中的策略选择，是需要分别核对的三件事。
- 在 Home 使用列表提供的编辑或排序入口。若当前编辑状态显示拖动手柄，将目标条目移到预期位置，再结束编辑；没有手柄时，不要通过反复导入来“置顶”。
- 区分正在移动的是订阅组还是组内节点。只需提升常用来源的可见性时，优先调整组的位置，减少对组内内容的逐项改动。
- 如果使用按名称或延迟排序，先确认排序作用于哪个列表范围。需要固定查找顺序时，可先用统一备注提高辨识度，再选择界面支持的排序方式。
- 完成后退出编辑、重新进入 Home，检查顺序是否保留。随后只更新一个订阅，观察组内排列是否被更新结果重新组织。
整理期间无需同时修改 Settings → On Demand。On Demand 负责按条件触发连接，不负责给订阅分组，也不会替列表去重。把连接触发设置与列表管理分开处理，可以避免清理时出现自动重连而难以判断当前状态。
四、重复节点先比参数，再决定删除范围
节点同名只能说明显示文本相同，不能证明是同一连接；名称不同也不保证连接不同。比对时先看协议、服务器地址和端口，再继续检查认证与传输参数。例如同一服务器都使用端口 443，仍可能因为协议、TLS 设置或传输路径不同而代表两条不同配置。端口号本身不能作为去重依据。
| 观察到的情况 | 需要核对 | 处理方式 |
|---|---|---|
| 两个组的名称和节点高度相似 | 订阅 URL 是否相同，是否曾重复添加 | 确认后保留一个有效订阅组 |
| 两个节点名称相同 | 协议、地址、端口及认证参数 | 参数不一致时暂不合并 |
| 名称不同但地址和端口相同 | TLS、传输方式、路径及协议相关字段 | 完整配置一致后再判断是否多余 |
| 删掉的节点更新后又出现 | 该节点是否仍由订阅返回 | 回到来源层面处理，不反复手工删除 |
| 同一服务器既在订阅组也在独立列表 | 独立条目是否承担备用用途 | 先确认保留目的，再清理其中一份 |
不同协议需要核对的字段并不完全相同。Shadowsocks 应检查加密方法和密码；VMess、VLESS 应检查 UUID 及相关传输设置；Trojan 应检查密码和 TLS 参数。比较时不要只截取地址、端口两行，也不要公开包含认证信息的编辑页面。
结论：整组重复先清订阅，组内重复先查来源
确认同一 URL 被添加两次时，删除多余订阅组比逐个删除子节点更容易维护；只有一组却在每次更新后重复出现的条目，应先核对订阅返回内容，避免清理结果被下一次更新覆盖。
比对订阅 URL 时也应谨慎。域名相同、路径相同，不代表查询参数对应的权限或内容相同；只因两个地址都以 /sub 结尾就合并，可能删掉仍需保留的一组。没有足够信息时，先保留并标注待核对，而不是批量删除。
五、删除旧订阅与更新验证的操作顺序
删除前，先确认自己仍能从原有的受控记录中找回有效来源。删除本地订阅条目通常不等于注销远端服务，也不表示原来的 URL 已失效；反过来，保留一个旧组也不能保证它仍能更新。清理应以“这条来源是否仍需使用”为判断标准。
- 保留可恢复的信息。记录要保留的订阅名称、来源以及当前使用的节点，不把密码或完整链接发到公共位置。若需要备份，使用自己确认过的应用备份或导出流程，并妥善保护文件。
- 先切离待删条目。如果当前选中的节点属于旧组，先选用需要保留的有效条目，再处理删除；必要时暂时关闭连接，避免操作中断影响判断。
- 按订阅层级删除。在 Home 针对旧订阅组使用其删除操作；出现确认提示时，核对名称及删除范围。只删除组内一个节点，不等于删除订阅来源。
- 单独更新保留组。使用保留订阅的更新操作，观察是否成功以及节点列表是否符合预期。不要重新添加同一 URL 来代替更新现有条目。
- 回到连接验证。重新选择保留组内的节点，核对 Global Routing 与 Config 中当前配置，打开连接后访问自己熟悉的页面，确认解析和请求都能完成。
每次只清理一个确认多余的组。若一次删除多个来源，同时切换模式并修改配置，出现异常时很难定位原因。节点数量减少本身不是故障；真正需要检查的是保留来源能否更新、所需条目是否还在，以及当前连接与策略是否指向预期位置。
六、多个订阅管理常见问题
为什么删掉节点，更新订阅后又回来了？
先在 Home 确认它属于哪个订阅组。只要该来源仍返回这个节点，后续更新就可能重新写入。若整个来源已不需要，应删除对应订阅；若还要使用来源中的其他节点，可先折叠分组或调整显示方式，并向自己已有的服务信息提供方核对内容，不要反复删除同一个子条目。
同一条订阅换了地址，要再添加一次吗？
先确认新地址确实用于替换原来源，再进入原订阅条目的编辑入口修改 URL，保存后执行更新。若为验证而暂时新增了一组，测试完成后应明确保留哪一组，并删除已确认多余的旧组，避免两个入口长期并存。
节点名字一样，可以直接保留延迟更低的那个吗？
不宜仅凭一次延迟结果删除。先打开两个条目的编辑页面，比较协议、地址、端口与认证、传输设置。参数相同再核对来源；参数不同则属于不同连接配置。延迟测试只反映当时的测试条件，不能证明条目重复，也不能代替实际网页访问验证。
整理顺序后，为什么实际请求没有走第一项？
返回 Home 查看当前选中的服务器和 Global Routing。若使用 Config，再到 Config 检查当前配置及策略选择；若使用 Scene，核对对应场景的设置。列表第一项只是显示位置，不会自动覆盖当前选择或配置中的策略。
如何防止下一次导入又出现重复组？
导入前先搜索或查看已有订阅备注，确认来源是否已经存在。已有来源变更时编辑原条目，需要获取新内容时执行更新，只有确实新增来源时才添加新订阅。扫码、剪贴板与手动输入只是不同入口，不代表它们会自动识别并合并同一来源。