多个订阅应分别保留来源、分别更新，再处理重复条目。本文适用于已经持有自己服务商订阅的用户：从 Home 的分组辨认开始，说明命名与排序、单组更新、删除前检查，以及如何区分同名节点和重复导入。操作完成后，应能确认每个分组的来源、当前默认服务器，以及更新是否影响了自己的选择。
一、先分清订阅、服务器与 Config
在 Shadowrocket（小火箭）中，订阅地址用于获取服务器条目；Home 展示服务器与订阅分组；Config 管理配置文件与分流规则。这三者不是同一个对象。更新某个订阅，不等于切换 Config；把某个分组排到上面，也不等于让该分组自动成为所有流量的出口。
本文以用户已有服务商和有效订阅为前提。本站不提供、不销售、不推荐节点或订阅。订阅地址中的 token 通常属于访问凭据，记录来源时只写服务商简称、用途和识别备注，不要把完整地址贴到聊天记录或公开截图。
二、分别导入并建立可辨认的分组
先检查 Home 是否已经有同一来源的分组，再决定是否新增。订阅已有条目只是内容过期时，应更新原有订阅，而不是再次添加地址。重复导入会让同一批服务器出现在不同分组内，之后每次更新仍可能重复出现。
- 打开 Home，记录已有分组名称。展开分组，确认里面是订阅生成的条目，还是自己手动添加的服务器。
- 需要新增来源时，进入 Add Server，选择 Type 中的 Subscribe，填写自己的订阅 URL。不要把订阅地址填进单个服务器的 Address 字段。
- 使用可辨认的备注，例如“01-服务商甲-日常”“02-服务商乙-备用”。备注只帮助识别，不改变协议、路由或连接优先级。
- 保存后回到 Home，等待该来源的内容载入。确认新分组与原分组分开显示，再继续添加下一个来源。
下面两张卡是本地记录方式示意，不是可连接的服务。地址中的 example.com 与 xxxx 均为假值；实际导入应使用自己的服务商提供的完整地址，不要自行替换其中的参数名称。
来源记录 A
- 备注
- 01-服务商甲-日常
- 类型
- Subscribe
- 地址示意
https://example.com/sub?token=xxxx- 管理位置
- Home 中对应的订阅分组
更新原分组，不用同一地址反复新建订阅。
来源记录 B
- 备注
- 02-服务商乙-备用
- 来源标记
- 用户已有的第二个服务商
- 地址保存
- 私密保存完整原始地址
- 更新范围
- 仅操作第二个订阅分组
“备用”只是备注，不能据此推定会自动切换。
三、分组排序与节点排序分别处理
排序前先确认操作对象：订阅分组顺序决定查找来源的便利程度，分组内服务器顺序决定查找具体条目的便利程度，二者都不直接修改 Global Routing。不要用“排在最上方”代替“已选中默认服务器”的检查。
- 按来源命名：给订阅备注加两位数字前缀，能在采用名称排序时保持“01、02、03”的顺序。前缀只是名称的一部分，并不是连接权重。
- 调整分组顺序：在 Home 的编辑状态或分组操作菜单中检查可用的排序控件；出现拖动柄时，拖动对应分组后完成编辑。界面未提供拖动入口时，不要假定长按标题就一定能拖动。
- 调整组内顺序：使用当前界面提供的名称或测试结果排序选项时，先确认作用于哪个列表。按延迟排序只代表该次测试的顺序，不能据此判断带宽或长期稳定性。
- 处理更新覆盖：订阅再次更新后，条目名称、数量和排列可能随服务端返回内容变化。重要的来源标记应保留在订阅备注中，不要只依靠某个节点名称辨认来源。
结论：用备注找来源，用选择状态认出口
完成排序后，回到 Home 核对当前选中的服务器；若 Config 中存在指定服务器或策略组的规则，还要检查相应引用。列表位置不能替代这两项检查。
四、单独更新一个订阅，先验证再批量处理
要排查某个来源，先做单组更新。对所有分组一起刷新，会让多个来源同时发生变动，不便判断是哪个地址超时、返回了空内容，或者改变了条目名称。这里的“更新”是重新获取订阅内容，不是更新应用本身。
- 在 Home 找到目标订阅分组，记录现有条目数量及当前选中的服务器名称。数量记录用于比较，不作为服务质量判断。
- 打开该订阅的操作菜单，执行 Update。操作入口以当前界面为准；本次只选目标订阅的更新操作，不执行面向全部订阅的操作。
- 等待操作结束，检查报错信息和分组内容。成功返回但数量不变，可能只是服务端内容没有变化，不应仅凭数量认定更新失败。
- 如果出现超时，先确认设备可以联网，再检查订阅地址是否仍有效。若地址已被服务商重置，应编辑原订阅的 URL，而不是保留旧地址并不断新增分组。
- 如果原来选中的服务器被移除，在 Home 重新选择现有条目，再运行 Connectivity Test。保留仍可用的原始记录，直到确认更新结果符合预期。
五、重复节点先查来源，再比连接参数
两个条目名称相同，不足以判定重复。不同服务商可能使用相同的地区名；同一服务商也可能在同一地区提供不同协议或端口。反过来，名称不同的两个条目，也可能引用同一个服务器端点。应在条目详情中逐项核对，而不是只按显示名称批量删除。
| 观察到的情况 | 核对内容 | 处理方式 |
|---|---|---|
| 两个分组名称不同，内容基本相同 | 订阅 URL 是否来自同一来源，是否重复添加 | 确认保留的分组更新正常后，再删除多余订阅 |
| 名称相同，端口分别为 443、8443 | Type、Address、Port 及协议相关字段 | 端口不同就是不同连接参数，不能只按名称去重 |
| 名称相同，协议分别为 VMess、VLESS | 协议类型及各自所需的认证、传输配置 | 分别保留核对，不视为同一条配置 |
| 同一条目出现在手动列表和订阅分组 | 是否曾手动复制订阅中的服务器 | 决定保留订阅管理还是手动副本，避免两份长期混用 |
| 删除条目后，更新时再次出现 | 该条目是否仍包含在订阅返回内容中 | 将来源层面的重复与本地删除区分处理 |
表中的 443 与 8443 只是端口比较示例，不是应当统一填写的值。判断两个配置是否等价，还可能需要比较 UUID、Password、TLS、SNI、传输方式与路径等字段；只在自己的设备上核对这些内容，不要为了求助公开完整认证信息。
结论：重复导入要删除多余来源
若两个分组确实来自同一份订阅，应保留一个可正常更新的分组并移除另一个。只删除多余分组里的服务器条目，不能阻止下次更新重新生成这些条目。
六、删除订阅前，确认默认服务器和规则引用
删除整个订阅与删除单个服务器是不同操作。订阅分组被移除后，其管理的条目也会受影响；仅删除某个条目，则可能在下一次订阅更新时重新出现。删除前先读清确认提示，确认范围是目标分组，而不是整个列表。
- 私密保存仍需保留的订阅来源信息，核对准备删除的分组名称和 URL，避免同名分组误删。
- 如果当前默认服务器属于目标分组，先在 Home 选择另一个已验证可用的条目。需要中断连接进行维护时，先关闭连接开关。
- 如果 Config 中使用了被删服务器的名称，检查相关策略组或规则引用。不要假定删除分组会自动把这些引用替换为其他服务器。
- 打开目标订阅的操作菜单，执行 Delete 并核对确认提示。删除完成后检查其他分组是否仍在。
- 重新确认 Global Routing 和默认选择，再测试实际需要访问的目标。Connectivity Test 通过后，仍应验证相应应用或请求是否按预期工作。
Global Routing 中的 Proxy、Direct、Config、Scene 属于路由选择，不是订阅排序方式。使用 Config 时还要考虑配置文件中的规则和策略；使用 Direct 排查时，也不能把直接连接的结果当成某个服务器已经通过测试。维护期间应记录原来的设置，完成后按自己的用途恢复。
七、多订阅管理常见问题
为什么同一个订阅更新后，刚删掉的节点又回来了？
订阅更新会重新读取来源内容。先确认你删的是单个条目还是整个重复订阅；若只是本地删除条目，而来源仍包含它，更新后可能再次出现。重复添加同一来源时，应在确认保留分组正常后移除多余订阅。
我只想更新第二个订阅，怎样避免其他分组跟着变？
从 Home 中第二个订阅的分组操作菜单执行 Update，先不要使用面向全部订阅的更新操作。更新前记录该组条目，更新后只核对这一组的结果，确认正常后再处理其他来源。
把备用分组排到最上面，会自动切换过去吗？
不会仅因列表顺序改变就完成出口切换。回到 Home 检查默认服务器；若使用 Config，再检查策略组和规则实际引用。需要自动选择时，应单独核对配置中的相应机制，不能把分组备注或排列当成自动切换条件。
订阅更新成功了，但新节点连接失败，下一步查什么？
先在 Home 选中具体条目并运行 Connectivity Test，核对设备网络、服务器参数和 Global Routing。更新成功只验证内容获取；若只有某个来源的条目失败，向自己的服务商确认服务状态，提供必要的错误描述即可，不公开完整订阅地址。