多个订阅应先按来源辨认，再整理显示顺序，最后清理重复项。本文以用户已有自己的服务商与订阅为前提，说明 Home 中订阅组与组内服务器的区别、删除前需要保留的信息，以及为什么更新后手动删除的条目可能再次出现。整理过程中一次只处理一组，避免把来源不同但名称相同的服务器误删。
一、先区分订阅组、服务器与 Config
Shadowrocket（小火箭）的订阅管理主要围绕 Home 中的订阅组进行。订阅地址是获取服务器列表的来源，一条订阅可以返回多个服务器；服务器条目才包含实际连接所需的协议、地址、端口和认证参数。两个组都出现同一个名称，不足以证明重复导入。
Config 管理的是配置文件与分流规则，不等于订阅服务器列表。删除一个旧订阅，不代表同时删除了 Config 中的文件；反过来，删除配置文件也不是清理重复服务器的方法。Settings 中的更新相关选项会影响获取行为，但不会替代 Home 中对订阅来源的核对。
订阅与服务器
- 检查位置
- Home 中的订阅组及组内条目
- 来源依据
- 订阅编辑页中的 URL
- 连接依据
- 服务器协议、地址、端口与认证参数
- 更新影响
- 重新获取该来源返回的服务器列表
组名用于辨认，URL 用于核对来源；两者不能相互替代。
配置与路由
- 配置位置
- Config
- 路由入口
- Home → Global Routing
- 规则姿态
- Config 按所选配置处理连接
- 其他姿态
- Proxy、Direct、Scene
调整列表顺序不等于更改 Global Routing，也不等于改写配置中的策略选择。
二、按来源命名，再整理组与组内顺序
先打开 Home，展开现有订阅组，逐组进入订阅编辑页检查 URL 与备注。部分操作入口以信息按钮、编辑按钮或长按菜单呈现，具体外观可能随界面调整；操作前应确认当前编辑对象是订阅本身，而不是组内某一台服务器。组名可采用“用途－来源－状态”，例如“日常－来源A－保留”和“备用－来源B－待核对”。
- 记录对应关系：为每个订阅组记下可辨认的备注、来源及当前服务器数量。完整 URL 可能包含访问凭据，只保存在个人可控的位置，不粘贴到公开反馈中。
- 先改备注：保存后返回 Home，确认组标题已经变化。重命名不会把两个订阅合并，也不会改变服务端返回的内容。
- 再处理组顺序：在当前界面提供的编辑或排序操作中，将常用组放前、待核对组放后。若出现拖动手柄，拖动后退出编辑状态，再确认位置是否保存。
- 单独检查组内排序：名称、延迟或原始顺序针对的是组内服务器，不是订阅组之间的优先级。使用延迟排序前先完成测试，未返回结果的条目不能直接视为不可用。
- 验证更新后的变化：对一组执行更新，再检查排列。若更新后恢复为来源返回的顺序，说明本地显示顺序不宜作为长期分类依据，应主要依赖清楚的组名。
排序只是整理显示。把一组移到第一位，并不会自动切换当前连接，也不能保证配置中的策略组改用这一来源。若当前界面没有独立的组排序入口，保留清楚的备注即可，不要通过反复导入来尝试改变位置；重复导入反而容易制造第二个相同来源的组。
三、重复节点先查来源，不要只看名称
重复现象通常分为三类：同一 URL 被保存为两个订阅；两个不同 URL 返回了部分相同服务器；某个订阅本身包含名称相近或连接参数相同的条目。第一类适合清理重复订阅，后两类则需要先确认来源与参数，不能只凭 Home 中的显示名批量删除。
| 看到的现象 | 需要核对 | 处理方向 |
|---|---|---|
| 两个组的名称和数量都相同 | 订阅 URL 是否完全相同 | 确认选中状态后，保留一个有效来源 |
| 同名服务器出现在不同组 | 地址、端口、协议及传输参数 | 参数不同就保留，不按名称去重 |
| 删除条目后更新又出现 | 最新订阅内容是否仍包含该条目 | 从来源内容或可用筛选设置处理 |
| 只有一个组中出现相似名称 | 是否为不同端口、协议或线路标识 | 逐项检查，不把名称相似当作重复 |
以两个 Trojan 条目为例，同为 edge.example.com:443 仍不足以认定完全相同，还要核对认证信息、TLS 相关设置与传输参数。如果一个端口是 443，另一个是 8443，则已经存在明确的连接端点差异。比较认证信息时只在设备内查看，不要把完整参数放进公开截图。
结论：先清理重复来源，再考虑组内去重
两个组指向同一完整 URL 时，优先保留其中一个有效组；只有名称相同而来源或连接参数不同的条目，先保留并补充备注，不做批量删除。
四、删除旧订阅前，先把当前连接移开
删除订阅会影响本地保存的列表，但不等于终止与服务商之间的服务关系，也不会替用户撤销服务端的访问凭据。操作前先确认新组能更新、能连接，再处理旧组。不要在尚未确认新地址有效时删除唯一可用来源。
- 保存恢复依据：记录旧组备注与订阅地址，并妥善保存自己的手动服务器参数。仅记录显示名无法重新导入订阅。
- 选中替代条目：在 Home 选择准备保留的组内服务器；若原来正在连接，断开后重新连接，再访问一个已知可用的目标确认结果。
- 检查配置引用：如当前配置使用按名称选择的服务器或策略组，进入 Config 检查相关引用。不能只看 Home 的选中标记就认定所有规则都已切换。
- 删除正确层级：在 Home 对旧订阅组执行删除，阅读确认提示，确认对象是整组订阅。若只对某条服务器执行删除，订阅来源仍可能保留。
- 退出后复核：确认旧组消失、保留组仍在，并再更新一次保留组。若出现误删，使用此前保存的来源重新添加，而不是凭记忆手填一批服务器。
五、更新后重复出现，检查“删除”与“来源”的关系
订阅更新会重新获取来源内容。手动删除组内一条服务器，并不意味着服务端也删除了它；只要后续返回内容仍含有这条记录，它就可能再次出现。这种现象不一定是删除失败，而是本地列表再次由来源生成。
先更新单个订阅，而不是立刻更新全部。更新前记下该组数量与几个代表性名称，更新后再比较。数量不变只能说明总数相同，不能证明内容未变；地址、端口或认证参数都可能已经变化。反过来，数量增加也可能是来源新增了条目，不能直接算作重复。
- 同一组恢复旧条目：检查来源是否仍返回该条目；如当前订阅编辑界面提供筛选设置，先确认它作用于哪些名称，再小范围验证。
- 多出第二个组：回查是否又执行了添加订阅。更新现有组与重新导入地址不是同一个操作。
- 出现同名不同参数：查看是否为来源调整了端点或协议，不要为了名称整齐而删掉有效替代项。
- 新旧 URL 并存：查询参数不同不一定代表不同服务内容；需要分别更新并核对返回结果，再决定保留哪个来源。
如果整理目标是长期隐藏某些条目，应优先使用来源允许的内容调整方式，或当前应用界面明确提供的筛选能力。不要把一次手动删除当作持久过滤规则，也不要编写未经确认的 URL 参数。每次只修改一个条件，更新后检查其他条目是否被误排除。
六、多个订阅管理中的常见问题
把备用组移到最上面，就会自动用它连接吗？
不会仅因显示顺序改变而自动确定连接目标。回到 Home 检查当前选中的服务器，再检查 Global Routing。使用 Config 时，还要核对当前配置里的策略选择；不要用组的位置推断实际出站。
旧订阅删了，为什么连接又自动打开了？
订阅列表与自动连接条件是不同设置。进入 Settings → On Demand 检查触发条件，同时确认当前连接使用的服务器。自动连接再次触发，不等于旧订阅已恢复。
两个组的服务器名称一样，留一个就够了吗？
先分别打开条目详情，核对协议、地址、端口和认证、传输参数。只有名称相同不能判断为同一条连接；如果连订阅 URL 也完全相同，再按删除旧订阅的步骤清理多余组。
新组更新失败，还能马上删旧组吗？
先保留旧组。单独更新新组，核对 URL 是否完整、访问凭据是否有效以及当前网络是否能获取该地址。确认新组能返回服务器列表并完成连接验证后，再迁移选中项和配置引用。
手动修改的服务器备注，更新后为什么变了？
来源返回的名称可能在更新时重新写入。用订阅组备注标记来源更适合长期辨认；若需要保留独立手动条目，应明确记录它不再随原订阅同步，后续参数变更也需要单独维护。