管理 Shadowrocket（小火箭）的多个订阅，先确认每个分组对应的订阅来源，再做排序、更新和删除。本文以用户已有自己的服务商与订阅为前提，说明如何区分订阅分组与独立节点、如何核对重复条目，以及怎样在清理后检查当前选中项，避免把重复导入误判为更新故障。
先分清订阅、分组与当前选中项
Home 中的订阅分组用于组织订阅返回的节点，不等于规则策略组。一个订阅地址可能返回多个节点；同一地址重复添加，也可能形成多个来源相同的分组。管理多个订阅时，第一步不是按名称批量删除，而是逐组检查来源。
Home 主要用于查看节点、选择连接对象及管理订阅；Config 用于管理规则配置；Settings 用于应用设置。把某个分组移到列表顶部，只改变列表组织，不代表 Config 中的规则会自动改用该分组，也不代表所有请求都会使用它。
独立导入的节点还需要单独辨认。把某个节点的分享链接再次导入，并不等于更新它所属的订阅。订阅地址与单节点分享链接是不同对象，判断时应查看条目详情，而不是只看显示名称。
在 Home 给多个订阅建立可辨认的分组
开始整理前，先确保自己能够从原有服务商处重新取得订阅地址。地址中的 token 通常具有访问凭据的作用，不应把完整内容放入公开截图、群聊或问题描述。本文的 https://example.com/sub?token=xxxx 只是格式示例，不是可用订阅。
- 进入 Home，逐个查看订阅分组。展开需要检查的分组，确认其中节点是否与预期来源相符。
- 从分组的操作菜单进入订阅编辑信息。长按分组标题可检查可用操作；编辑入口与具体文字以当前应用界面为准。
- 核对订阅地址及备注。分别记录“主要使用”“备用连接”等用途，不把 token、密码或完整地址写进备注。
- 如果两个分组看起来来自同一来源，先比较完整地址，再核对节点详情。不要仅凭相同的分组名称认定重复。
- 保存备注后返回 Home，确认修改作用于预期分组，没有误改另一份订阅。
订阅来源记录
- 入口
- Home 中的订阅编辑信息
- 备注示例
- 主要使用
- URL 示例
https://example.com/sub?token=xxxx- 核对重点
- 完整路径、参数与所属账户
来源记录用于辨认订阅，不改变服务器连接参数。
节点身份核对
- Type
- 例如 Trojan，与已有服务资料一致
- Address
- 例如
edge.example.com - Port
- 例如
443，并非统一默认值 - 认证字段
- 按协议核对 Password 或 UUID 等信息
这些是假值示例；实际字段必须与用户已有服务配置一致。
调整列表顺序，不把排序当成自动切换
分组顺序与分组内节点顺序是两件事。前者用于减少查找成本，后者方便从同一来源中选择节点。先决定需要移动哪个层级，再使用当前界面提供的编辑、排序或拖动操作。只有出现拖动手柄时才按手柄调整；没有对应入口时，不要把普通长按误当成排序。
- 分组层级：把经常使用的订阅放在容易找到的位置，暂时不用的分组可以先折叠，而不是马上删除。
- 节点层级：如使用按名称或延迟排序，操作后检查它影响的是当前分组还是更大范围。
- 更新之后：重新检查顺序。订阅返回的排列与本地排序并不是同一个来源，不应假定手工次序会永久保留。
- 连接选择：移动条目后仍要核对当前选中标记；列表首项不等于当前连接项。
普通订阅分组不会因为排在最前就自动成为故障切换组。若配置使用策略组及其选择机制，应在 Config 中单独检查。Global Routing 为 Config 时，还要结合规则实际命中的策略判断请求去向；不能仅凭 Home 中某个节点被选中，就断定每条请求都经过该节点。
结论：先整理显示，再验证连接
每次只调整一个层级，保存后核对当前选中项及 Global Routing，再进行连接测试；不要同时排序、删除和修改规则，以免无法定位变化来源。
更新已有订阅，避免反复新增同一来源
更新的目标应是 Home 中已经存在的那份订阅，而不是再次使用添加入口导入同一地址。需要刷新节点时，从目标分组的操作菜单执行更新，并观察应用显示的结果。先单独更新一组，确认返回内容正常，再处理下一组，便于区分是某个来源异常还是当前网络无法获取订阅。
- 更新前记下分组名称、当前节点数量与选中节点。这些只作为本次操作的对照，不作为长期固定值。
- 对该分组执行一次更新。若报错，保留错误信息，不要通过重复添加相同 URL 试图绕过。
- 更新成功后，展开分组检查条目是否发生变化。节点数量增加也可能来自订阅内容变化，不能单凭数量判定重复。
- 检查原来选中的节点是否仍存在；如已被来源移除，重新选择一个现有节点，再验证连接。
Settings → Subscribe 是检查订阅相关设置的入口。若调整其中的更新选项，先阅读当前界面的说明，确认影响范围。自动更新只能重新获取来源内容，不会替用户判断两份不同地址是否属于同一账户，也不等于跨订阅自动去重。
重复节点按来源和连接字段判断
同名不一定重复，不同名也不一定不同。两个节点可能共用服务器域名，却使用不同端口、协议、认证或传输参数；也可能名称分别带有用途备注，实际连接字段完全一致。判断时先分辨重复发生在分组层级还是节点层级。
| 观察到的现象 | 先核对什么 | 处理方向 |
|---|---|---|
| 两个分组的节点几乎一致 | 两份订阅的完整 URL 与账户来源 | 确认重复导入后保留一份，再删除另一份分组 |
| 同组中两个条目名称相同 | Type、Address、Port、认证及传输字段 | 字段不同则分别保留，不按名称直接合并 |
| 删掉条目后更新又出现 | 该条目是否仍由订阅来源返回 | 从来源内容或可用的订阅筛选设置处理 |
| 更新后还留有旧节点 | 旧条目是独立导入还是属于另一分组 | 按所属来源清理，不反复更新无关分组 |
例如，edge.example.com:443 与 edge.example.com:8443 的端口不同，不能因为 Address 相同就删除其中一个。即使地址和端口一致，也要继续核对认证与 TLS、传输等相关字段。对比认证信息只在本机进行，不应把完整凭据发给他人协助判断。
订阅更新会再次读取来源内容，所以只在本地删去一个由订阅持续返回的节点，不是长期排除它的可靠办法。如果当前订阅设置提供筛选功能，应先确认其匹配范围与效果；不确定时，保留原始地址及必要记录，再做小范围验证。
删除失效订阅前，确认清理范围
删除单个节点与删除整份订阅影响范围不同。操作前读清确认提示，确认删除对象是一个条目，还是分组及其关联节点。短暂更新失败不等于订阅已经失效，应先核对地址、账户状态及当前网络，再决定是否清理。
- 在 Home 中确认待删除分组的来源与用途，检查是否与准备保留的订阅重复。
- 如果当前选中节点属于该分组，先选择计划保留的节点；必要时断开连接后再整理。
- 从目标分组的操作菜单删除订阅，核对确认提示中的范围。删除独立节点时，同样检查它是否确实不属于需要保留的分组。
- 返回 Home 检查列表，并到 Config 检查是否有依赖已删除节点名称的选择或配置。
- 重新连接并测试实际访问。删除本地订阅记录不会取消服务商账户中的服务，也不会改变 App Store 中的应用购买记录。
多个订阅管理中的常见问题
同一订阅添加了两次，直接删一个可以吗？
先在 Home 的订阅编辑信息里比较完整 URL，再确认准备保留的分组能够正常更新。把当前选中项切到保留组中的节点后，删除多余分组；不要只凭两个分组同名就操作。
为什么删除节点以后，下次更新又回来了？
先检查它是否仍在原订阅分组内。若来源继续返回该条目，本地删除不等于修改远端订阅内容。检查来源内容或当前可用的筛选设置，不要反复手工删除后又用新增订阅处理。
把备用订阅移到最上面，会自动使用它吗？
不会仅因显示位置而自动切换。回到 Home 核对选中节点和 Global Routing；使用 Config 时，还要检查配置中的策略选择。需要自动选择行为时，应单独核对策略组配置，而不是依赖分组排列。
有一组更新失败，是否要删除全部订阅重来？
先只检查失败的那一组：核对 URL 是否完整、凭据是否仍有效，再重试该组更新。其他分组正常时，保留它们。必要时查看 Settings → Subscribe 的相关选项，避免把单一来源问题扩大为整个列表的重建。
整理完成后的检查顺序是：来源能够辨认、重复分组已经核实、当前节点仍然存在、Global Routing 与配置符合预期，最后验证连接。把订阅管理与规则修改分开操作，才能在异常出现时准确回到刚才改动的那一步。