已有自己的服务商与订阅时，先按来源整理订阅，再处理列表顺序和重复项。本文说明 Shadowrocket（小火箭）中订阅、节点与规则配置的区别，给出备注命名、逐组更新、核对重复节点及删除前检查的方法。核心原则是先确认来源，再修改内容；不要把名称相同直接当成连接参数相同。
一、先区分订阅、节点与 Config
订阅是用于取得一组连接配置的来源，节点是其中一条具体连接配置。一个订阅可以包含多个节点，同一节点也可能通过不同订阅或单独导入的方式出现在 Home（首页）。因此，Home 里出现两条相似记录，并不能直接证明导入出错。
Config（配置）管理规则配置；Settings（设置）管理应用设置。整理 Home 的订阅名称，不等于修改 Config 中的规则或策略组。规则配置中若按名称引用节点或筛选节点，改名、更新和删除后还应核对这些引用。
这里的“分组”首先指按订阅来源辨认列表，不是自动创建可供规则选择的策略组。若目标是按域名选择不同出站，需要另行检查 Config 中的规则及策略设置，不能只依靠订阅备注。
二、用 Remarks 固定来源，导入前先检查是否已有
建议给每个订阅设置稳定的来源备注，把订阅身份与节点用途分开表达。例如订阅备注使用“01-来源甲-日常”“02-来源乙-备用”，节点原有名称暂时保留。前缀用于人工辨认，不代表应用一定会按这个前缀自动排序。
- 打开 Home，先查看现有订阅分组；进入对应订阅的编辑页，核对 URL（订阅地址）是否已经保存。
- 确需新增时，在 Home 使用添加入口，将 Type（类型）选为 Subscribe（订阅），再填写用户已有的订阅 URL。
- 在 Remarks（备注）中填写可识别来源的短名称。确认保存后，检查该订阅下是否出现预期节点。
- 已有订阅只需改名时，编辑原订阅的 Remarks，不要为了更换显示名称再导入一遍。
订阅字段核对
- Type（类型）
- 新增订阅时推荐选 Subscribe；初始值以当前应用显示为准。
- URL（订阅地址）
- 使用本人已有的完整地址；没有可通用套用的默认地址。
- Remarks（备注）
- 推荐“01-来源甲-日常”；默认内容以当前应用显示为准。
- 保存后核对
- 确认分组备注与节点内容对应，不只检查是否出现新分组。
字段位置以当前应用界面为准；不要把节点编辑页误认为订阅编辑页。
命名记录建议
- 来源标识
- 用来源甲、来源乙等固定称呼，避免只写“新订阅”。
- 用途标识
- 用日常、备用等个人用途，不把备注当作质量结论。
- 数字前缀
- 统一使用 01、02、03，便于人工检查列表次序。
- 原始节点名
- 首次整理建议保留，便于与来源返回的内容核对。
这是一套人工命名约定，不是应用内的默认分组或排序规则。
订阅地址可能带有访问令牌。核对重复来源时可以在设备上比较完整地址，但不要把地址、二维码或完整编辑页发送给他人。两条地址即使域名和路径相同，令牌不同也可能对应不同权限，不能只看开头就合并。
三、排序以当前列表能力为准，不把编号当成自动规则
整理顺序时，应分别处理“订阅分组的位置”和“分组内节点的位置”。先确认当前操作面向哪一层，再使用界面实际提供的排序或编辑入口。不要在节点列表里操作一次，就认定所有订阅分组都已重新排列。
- 手动位置：若当前列表进入编辑状态后提供移动手柄，可将常用项目移动到便于选择的位置；未提供该入口时，不套用拖动步骤。
- 名称顺序：若当前界面提供按名称排序，先统一命名，再选择对应排序方式；数字前缀本身不会强制切换排序方式。
- 延迟结果：测试得到的数值属于当时网络环境，不能替代来源分类，也不等于持续下载速度。
- 更新后的顺序：来源返回的节点集合可能变化。完成一次更新后，重新确认常用节点位置及当前选中项。
结论：先稳定来源备注，再整理节点位置
把常用订阅标为“01-来源甲-日常”，并记录常用节点的原始名称。即使更新后节点位置变化，也能从订阅来源重新定位，不必依赖列表里的第几行。
若节点名被 Config 中的策略直接引用，不宜为了排序批量加前缀。更稳妥的做法是先改订阅层的备注，再检查策略的引用方式；确认没有名称依赖后，才考虑调整节点名称。
四、逐组更新：先记录，再刷新，再核对
更新订阅的作用是重新取得来源提供的节点内容，不是简单测试现有节点是否在线。来源可能增加节点、移除节点或修改连接参数，因此更新后数量和名称变化不一定是本地故障。建议先记录该组当前节点数量及正在使用的节点名称，再执行更新。
- 在 Home 找到目标订阅，使用该订阅提供的更新操作；入口名称与位置以当前应用显示为准。
- 等待本次操作结束，查看成功或错误提示，不连续触发多次更新。
- 比较更新前后的分组内容，确认原有常用节点是否仍在，新增项目是否属于该来源。
- 检查当前选中节点；若旧节点被移除，重新选择仍有效的节点，再检查依赖该节点的策略。
- 完成这一组后再更新下一组，把问题限制在单一来源内。
更新超时只能说明这次获取未完成，不能据此认定全部节点失效。先检查设备当前网络、订阅地址是否完整、来源是否提示访问权限变化，再查看应用给出的错误信息。已有节点能够连接，也不保证订阅地址此刻能够访问。
五、重复节点清理：比较连接参数，不只比较名称
同名节点可能使用不同服务器、端口或传输参数；不同名称也可能指向同一连接配置。清理前，应在各自编辑页比较参数，并记录它们来自哪个订阅。协议不同或认证信息不同的记录，不能仅因显示名称相近就删除。
| 核对项目 | 具体比较内容 | 处理判断 |
|---|---|---|
| 订阅来源 | 是否同一完整订阅地址被重复导入 | 先处理重复订阅，避免逐条删除后又随更新恢复。 |
| 协议与地址 | Type、服务器地址、端口是否一致 | 例如端口 443 与 8443 不同，不能仅凭同名认定重复。 |
| 认证信息 | 按协议比较密码、UUID 或密钥等字段 | 认证不同应保留区分；核对过程不公开这些内容。 |
| 传输与 TLS | 传输方式、路径、Host、SNI 及 TLS 相关设置 | 服务器和端口相同，也可能承载不同连接方式。 |
| 规则引用 | Config 中是否使用节点名或名称筛选条件 | 删除前确认引用不会指向已不存在的项目。 |
上述端口只是说明比较方法，不是推荐用户把端口统一改为某个数值。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 的字段并不完全相同，应按该节点实际协议检查，保持已有配置的有效参数。
若只是同一来源重复导入，优先保留备注清晰且引用关系已确认的一组，再删除多余订阅。若来自两个不同来源，即便连接参数相同，也应先确认是否需要保留各自的更新关系；本地删掉其中一条节点，不会要求来源以后停止下发它。
- 同名但参数不同：保留，并通过来源备注辨认。
- 同源重复导入：核对完整订阅地址后，在订阅层处理。
- 单独导入与订阅内记录重复：先确认独立记录是否仍有用途，再决定删除哪一条。
- 删除后更新又出现：说明该项目仍由订阅返回，应重新评估本地清理方法，而不是反复删除。
六、删除订阅前，先确认选中节点和策略引用
删除节点与删除订阅不是同一个动作。操作前先看清当前选中的是分组还是单条记录，并阅读确认提示。如果当前正在使用该组内节点，建议先切换到另一条已确认可用的记录，避免删除后连接目标不明确。
- 在 Home 进入待删除订阅的编辑或管理入口；若界面通过侧滑提供删除操作，也应先确认侧滑对象。
- 核对订阅 Remarks 与来源地址，确认不是准备保留的那一组。
- 阅读删除确认信息，确认是否连同组内节点一起移除；具体范围以当前应用提示为准。
- 删除后回到 Home 检查分组和选中节点，再进入 Config 检查相关策略引用。
- 需要恢复时，使用本人安全保存的原订阅重新导入；删除本地记录不等于取消来源侧的服务关系。
检查连接结果时，还应区分 Global Routing（全局路由）当前选择的 Proxy（代理）、Direct（直连）、Config（配置）或 Scene（场景）。这些选择决定请求如何使用出站，不负责管理订阅来源。若请求没有经过预期节点，应检查当前路由选择及配置，而不是继续删除订阅。
七、多个订阅管理常见问题
备注前面加了 01、02，为什么顺序没有变？
编号只是名称的一部分。先确认改的是订阅 Remarks 还是节点名称，再查看当前列表是否提供名称排序或手动移动入口。没有对应入口时，用编号辅助辨认即可，不把它当成自动排序设置。
删掉的重复节点，更新后怎么又回来了？
该节点可能仍包含在来源返回的内容中。先确认是否重复导入了同一订阅；若不是，保留订阅更新关系与永久移除某条来源记录是两件事，本地删除不能修改远端内容。
两个订阅都有同名节点，可以直接删一组吗？
先比较来源、协议、服务器、端口、认证和传输参数，再检查 Config 中的引用。名称相同不是重复的充分条件。确认是同一来源重复导入后，才按订阅层级删除多余组。
只想临时不用一个订阅，需要删除吗？
通常可先保留订阅记录，改选其他节点；使用 Config 或 Scene 时还要核对其策略选择。这样保留原有来源信息，恢复使用时不必重新导入。删除更适合已确认不再保留的本地记录。
完成整理后，保留一份个人记录：订阅备注、来源辨认信息、常用节点原名及策略依赖。含令牌的完整地址和认证信息应单独安全保存。后续每次更新只核对发生变化的部分，比定期清空全部列表更便于追踪问题。