Shadowrocket（小火箭）的多个订阅应按来源分别保留：先核对 Subscribe 条目及备注，再单独更新，最后处理排序与重复项。本文适用于已经拥有自己的服务商与订阅的用户，重点区分订阅来源、生成的节点和 Config 中的策略，避免把删除节点误当成停止订阅更新。
先分清 Subscribe、节点列表与 Config
Subscribe 条目保存订阅地址，更新时读取该地址返回的内容。Home 中显示的节点是导入或更新得到的连接记录；Config 则用于配置规则和策略。它们有关联，但不是同一层数据：调整 Home 中的显示顺序，不等于改变 Config 中的规则顺序，也不等于修改订阅源返回的顺序。
例如，已有两个订阅来源 A、B，以及一个手动添加的节点，应先辨认三者的归属，再操作具体条目。不要因为两条记录都叫“备用”就删除其中一条；名称相同只能说明显示标签相同，不能证明服务器地址、端口、协议与认证参数相同。
多个订阅怎么分组：先用备注区分来源
日常所说的“订阅分组”，首先应理解为按 Subscribe 来源组织节点，而不是新建一个同名策略组。建议给每个订阅条目设置稳定、可辨认的 Remarks，例如“个人线路 A”与“个人线路 B”；不要把完整订阅地址写进备注，也不要用会随测速结果变化的数字命名来源。
- 进入 Home，先浏览现有订阅分组及其标题，确认要添加的地址是否已经存在。
- 确需添加时，点右上角的添加按钮，在添加页面将 Type 设为 Subscribe，再填写 URL 与 Remarks。各字段位置以当前应用界面为准。
- 保存后回到 Home，核对新条目归属与返回的节点内容；若已有同一地址，应编辑原条目，而不是再次添加。
- 修改已有订阅时，从 Home 的订阅分组标题进入其操作菜单，选择编辑操作，核对 URL 与 Remarks 后保存。不要误入单个节点的参数编辑页。
订阅地址中的查询参数可能承载访问凭据。比较两个地址是否相同时，需要核对完整值，但不要把完整值贴到公开截图、聊天记录或故障说明中。下方 URL 仅说明字段形式，不是可用订阅；实际操作始终使用用户已经持有的地址。
订阅条目核对
- Type
- Subscribe
- Remarks
- 个人线路 A
- URL
https://example.com/sub?token=xxxx
示例地址仅用于辨认字段；备注不能替代订阅地址。
节点归属核对
- 来源
- 确认属于哪个 Subscribe 条目
- 名称
- 只用于显示与引用，不是唯一身份凭据
- 参数
- 核对协议、服务器、端口及认证字段
先区分来源，再判断是否重复，避免误删不同连接。
单独更新：先确认操作对象，再检查返回结果
多个订阅同时存在时，排查问题应优先更新单个来源。这样可以判断是某个 URL 获取失败，还是全部订阅都受当前网络影响。批量更新适合已确认各来源正常的日常维护，不适合定位第一次出现的异常。
- 在 Home 找到目标订阅的分组标题，长按打开该订阅的操作菜单；核对标题后使用其中的更新操作。菜单措辞及可用动作以当前界面为准。
- 等待这一次请求结束，查看应用给出的成功或错误提示，不要连续重复触发更新。
- 返回目标分组，核对节点名称与内容是否符合预期。成功获取并不意味着每个节点都可连接，还需要另行测试。
- 若只有一个来源失败，打开该订阅的编辑页核对 URL，尤其检查复制时是否夹入空格、换行或遗漏查询参数。
遇到超时，应区分“订阅地址无法访问”和“地址返回的内容无法解析”。前者需要检查网络路径与地址有效性，后者需要核对返回内容是否仍为该订阅应有的数据格式。不要把错误页面的文字当作新节点导入，也不要仅凭浏览器能打开某个网页就认定订阅请求一定正常。
手动排序：区分显示顺序与策略选择
排序前先确定要改变哪一种顺序：订阅分组的排列、分组内部节点的排列，还是 Config 内策略的候选顺序。这三者不能互相替代。把某个节点排到 Home 顶部，并不代表规则会自动使用它；实际连接还受 Global Routing 与当前配置影响。
- 手动排列：在 Home 查找列表编辑或排序操作。若当前列表提供 Edit 与拖动柄，进入编辑状态后拖动目标行，再完成编辑；只对显示拖动柄的层级操作，不把长按节点弹出的功能菜单当成拖动排序。
- 自动排列：若当前界面提供按名称或延迟排序，先确认作用范围。按延迟排序会随测试结果改变，不能承担固定来源分组的作用。
- 更新后的顺序：订阅更新可能重新生成列表。整理前记录现有顺序，单独更新一次后观察是否保留；若恢复为来源顺序，就不要依赖本地位置保存长期分类。
- 没有排序入口：不同列表层级可能提供不同操作。没有编辑或拖动控件时，不应反复删除再导入来“调序”，应先用订阅备注维持来源辨识。
在 Global Routing 使用 Config 时，规则与策略由当前配置决定；Proxy 与 Direct 的处理方式也不等同于列表排序。管理订阅时无需为了让条目靠前而修改 Global Routing，更不应通过改写 FINAL 来解决显示顺序问题。
去除重复节点：先去重来源，再比对连接参数
重复项最常见的两种来源是：同一个订阅地址被添加了多次，或者两个不同订阅本身包含相同连接。先处理第一种，可以减少以后更新时反复出现的重复项。单独删掉订阅生成的某一行，通常不能保证下一次更新后仍保持删除状态。
| 看到的情况 | 核对内容 | 处理方式 |
|---|---|---|
| 两个订阅分组内容一致 | 比较两个 Subscribe 条目的完整 URL | 确认同源后保留一个，删除多余订阅条目 |
| 节点名称相同 | 比较协议、服务器、端口及认证信息 | 参数不同则保留，不能只按名称去重 |
| 名称不同但地址相同 | 继续比较传输、TLS 与认证参数 | 不能仅凭服务器地址相同就判定重复 |
| 删除后更新又出现 | 检查节点是否由订阅源持续返回 | 处理重复订阅来源，而非反复删除生成行 |
例如，同一服务器的端口 443 与 8443 不是相同端点；同为 443，若一个连接使用 Trojan，另一个使用 VLESS，也不能合并。即使协议与端口相同，UUID、password、TLS 的 server name 或传输路径不同，连接含义仍可能不同。比较敏感字段时只在自己的设备上核对，不对外展示完整参数。
结论：优先删除重复订阅条目
确认两个 Subscribe 条目的完整 URL 相同后，先保留一个有效来源，再处理多余分组；不要只删除它们生成的节点，否则后续更新仍可能重新出现重复列表。
删除前检查引用，删除后验证连接
删除单个节点与删除整个订阅条目，影响范围不同。前者针对一条连接记录，后者针对订阅来源及其关联内容。操作前应在 Home 核对当前选中的节点，再到 Config 检查是否有策略依赖即将删除的名称；只看分组标题不足以确认删除是安全的。
- 记下需要保留的来源备注，并确认它能正常更新；不要以“节点暂时还在列表里”替代更新检查。
- 若当前正在使用准备删除的节点，先改选一个确认可用的保留节点；使用 Config 时同时检查相关策略的实际选择。
- 回到 Home，对目标订阅分组打开操作菜单并执行删除；若界面通过侧滑提供删除入口，应先确认这一行是订阅条目而非单个节点。
- 阅读确认提示中的对象与范围，再确认删除。完成后检查分组、节点及 Config 引用是否符合预期。
- 重新验证所需网页或业务是否可用。客户端删除本地条目，不等于终止用户在服务商处的服务关系。
如果保留的来源尚未成功更新，不宜先清空全部订阅再重建。更稳妥的顺序是先确认可恢复的地址与参数，再逐个清理；备份或记录中包含凭据时，同样需要按敏感信息保存。
多个订阅管理常见问题
订阅更新后，刚删掉的节点为什么又回来了？
先在 Home 确认它属于哪个 Subscribe 分组。如果来源仍返回该条连接，更新就可能再次生成。检查是否重复添加了同一 URL；若只是希望少看某些条目，应优先使用当前界面提供的显示管理功能，而不是把删除生成行当作永久过滤。
两个分组名字不一样，能直接当作两个独立订阅吗？
不能。打开两个订阅条目的编辑页，核对完整 URL。Remarks 可以不同，但地址仍可能相同；反过来，备注相同也不能证明同源。先核对来源，再决定保留或删除。
只想更新一个订阅，为什么不能直接全部刷新？
全部刷新不利于定位失败来源。先从 Home 的目标订阅分组菜单执行单独更新，记录该条目的结果；确认各来源均正常后，再使用界面提供的批量更新方式。
节点排到最上面了，连接为什么还是走另一个？
Home 的显示位置不是选路规则。检查当前节点选择以及 Global Routing；若使用 Config，打开当前配置核对策略选择与规则引用。先确认实际选路，再判断是不是排序没有保存。