Shadowrocket 多订阅管理:分组、排序、删除与重复节点清理

一、分清订阅来源、节点列表与 Config

订阅是获取节点资料的入口，节点是实际连接使用的服务器配置，Config 则主要承载规则等配置内容。三者不能互相替代：添加第二份订阅不会自动建立第二套分流规则，在 Config 中切换规则也不等于切换订阅来源。整理前应先明确，当前要处理的是哪一层内容。

将每份订阅视为独立来源，保留它的显示名称、用途和更新记录。手动添加的节点另行登记，避免误以为它们也会随订阅刷新。本站不提供、不销售、不推荐节点、订阅或服务商；本文操作以用户已有自己的订阅为前提，订阅地址从你的服务商处获取。

Shadowrocket 是闭源商业应用。客户端买断 ≠ 线路套餐，安装应用与已有订阅的服务期限是两件事。iPhone / iPad 的系统要求以 App Store 页面标注为准；Mac 提供 Apple 芯片与 Intel 选项。各平台获取说明统一见客户端下载页。

二、逐份导入订阅，按来源命名分组

不要连续扫描多张二维码或反复粘贴同一个地址后再开始整理。每次只导入一份，确认 Home 中出现的来源及其节点后再继续。这样即使发现空列表、导入失败或来源名称相似，也能定位到本次操作，而不是在多个混合列表中猜测。

1. 从你的服务商处获取订阅地址，并在本地私密记录中标注来源。订阅地址可能含有访问令牌，不要粘贴到公开截图、论坛或共享表格。
2. 在 Home 点击添加入口，进入 Add Server，将 Type 设为 Subscribe，再把完整地址填入 URL。字段是否齐全以当前平台显示为准，不要将订阅地址误填入单个节点的 Address。
3. 使用 Remarks 等名称字段标记来源。可采用“01-主用”“02-备用”的格式；编号用于辨认来源，不表示 Shadowrocket 会按编号自动切换。
4. 保存并等待该来源的节点载入。返回 Home，核对分组标题、节点数量与至少一个节点的参数，确认导入的是预期订阅。
5. 再导入下一份订阅。不要把已存在的同一地址再次添加为新来源；需要取得最新列表时，应对原有来源执行更新。

名称宜简短稳定，不必把全部用途和到期信息塞进节点名。对于订阅生成的节点，本地改名可能在更新后被来源内容覆盖；长期标签应优先放在订阅来源备注或自己的记录中。不要为保留名称而随意改动地址中的 token、参数顺序或编码。

三、按延迟排序前，先统一测试条件

延迟排序只改变列表展示次序，不等于稳定性排名，也不会自动改写 Config 的策略引用。不同测试方式测量的对象不一样：TCP 握手成功只能说明相应路径能够建立连接，不能据此确认认证、TLS 或目标网页访问都正常。比较前先统一测试方式和网络环境。

1. 在同一 Wi-Fi 或同一蜂窝网络下测试一份订阅。测试过程中不要切换网络，也不要同时执行大文件传输。
2. 在 Home 使用当前界面提供的 Connectivity Test 或延迟测试入口。若可选择测试方式，整轮保持相同设置，不把不同方式的结果直接混排。
3. 等待结果返回，再使用列表菜单中的延迟排序功能。不同平台的菜单位置可能不同，应以实际出现的测试与排序选项为准。
4. 间隔片刻再测一轮，观察超时是否持续。对候选节点执行一次实际访问，记录是否能够完成 TLS 连接并打开目标服务。
5. 选定节点后检查当前选择状态。不要仅凭列表第一行的位置判断它已经成为当前使用的节点。

四、重复节点清理：先查来源，再比连接参数

“名字一样”与“连接配置一样”不是同一件事。两个名为“备用”的节点可能分别使用不同地址或端口；两个名称不同的节点也可能连接同一服务器。同一地址上的 Trojan 与 VLESS 配置，或者同一地址上使用不同认证资料的配置，也不能直接当作重复项删除。

• 同一来源被导入两次：先比较两份订阅入口及更新内容。确认是重复导入后，保留一份有效来源，删除另一份，而不是逐条删除其下节点。
• 不同来源含有同名节点：先保留来源边界，再核对 Type、Address、Port 和认证资料。不要只按显示名称去重。
• 参数看似一致：继续检查 TLS、SNI、传输方式及相关路径等参数。端口同为 443 只是一项相同条件，不能证明配置等价。
• 手动节点与订阅节点重复：确认手动项是否为特意保留的不同配置。若决定清理，优先保留能够通过原订阅持续更新、且已经验证可用的记录。
• 删除后更新又出现：说明该记录仍在来源返回的内容中。反复本地删除不能改变源内容，应先确认是否导入了重复来源，再按服务商提供的订阅管理方式处理。

凭据比较应在自己的设备上进行，不要为了请求协助而公开密码、UUID、私钥或完整订阅 URL。确需记录差异时，只写“认证资料相同”或“认证资料不同”，无需复制具体值。清理前保留可恢复的配置记录，并妥善保管其中可能包含的敏感资料。

五、删除失效订阅与更新后的复查顺序

一次更新超时不等于订阅已经失效。先检查本地网络和地址是否完整，再核对服务商提供的有效状态。若地址已经更换，应编辑原来源或在验证新来源后移除旧来源，不要长期同时保留两份内容相近的入口。

1. 确认当前连接：在 Home 确认正在使用的节点属于哪个来源。若它属于待删除来源，先切换到另一条已验证可用的连接，避免删除后才发现当前选择失效。
2. 检查规则引用：在 Config 中检查是否存在指向特定节点名称或策略的引用。来源删除或节点改名后，这些引用也需要复核，不能只看 Home 列表是否整齐。
3. 区分删除层级：需要移除整份订阅时，操作来源本身；仅移除一条手动配置时，操作对应节点。确认删除提示所指的对象和范围，再提交操作。
4. 更新保留来源：对仍在使用的订阅执行更新。检查节点是否正常返回、原先删除的重复项是否重现，以及当前选中项是否仍然有效。
5. 验证实际访问：确认 Global Routing 与原计划一致，再测试一个应经代理访问的目标和一个应直接连接的目标。整理前后保持相同条件，才能判断是否引入了新问题。

Global Routing 中的 Proxy、Direct、Config、Scene 是路由使用方式，不是订阅分组。Proxy 与 Direct 可用于有目的的对照检查；Config 按当前配置中的规则处理连接；Scene 按已设置的场景条件工作。测试结束后恢复原定方式，不要长期停留在为排查临时选择的状态。

Settings → On Demand 管理按条件建立或断开连接的行为，不承担订阅去重，也不等于按延迟自动换节点。若测试期间连接状态自行变化，应同时检查 On Demand 条件，避免把自动连接行为误判为订阅更新造成的异常。

六、多订阅管理常见问题