Shadowrocket 订阅怎么转换与合并？两种方式取舍
一句话回答：想统一管理就做转换合并，把多份订阅合成一条并附加统一规则；想保留灵活性就让多份订阅在客户端内并存，用分组区分并手动切换。
要点速览
- 转换合并适合想要一份配置搞定全部的场景，代价是节点变动需要重新生成。
- 多订阅并存适合需要随时切换服务方的场景，代价是列表更长、测速更慢。
- 合并时保留原始订阅链接，出问题可以立刻回退。
- 无论哪种方式，都不要在同一客户端重复导入同一条订阅。
手里有多份订阅时，选择合并还是并存，取决于你更看重统一管理还是切换灵活。两种方式没有优劣，只有适配场景的差别。
方式一：转换合并成一条
转换的做法是把多份订阅的节点与自定义规则整合，生成一条新的订阅地址，客户端只导入这一条即可获得全部节点与统一规则。
优点是一次配置处处可用，换设备时只需导入一条；缺点是服务方调整节点后需要重新生成，且转换环节本身是一个额外的依赖。
| 维度 | 转换合并 | 多订阅并存 |
|---|---|---|
| 节点列表 | 单一列表 | 多分组 |
| 规则统一 | 容易 | 需逐份维护 |
| 换机成本 | 低 | 中 |
| 切换灵活度 | 低 | 高 |
| 额外依赖 | 需要转换环节 | 无 |
方式二：多份订阅并存
在客户端内分别导入多份订阅，用备注或分组区分，需要时切换当前使用的分组。
这种方式没有额外依赖，服务方变动时自动同步；代价是节点总数变多，测速耗时增加，也需要自己记住每份订阅的用途。
- 给每份订阅起明确的备注名，避免日后分不清来源。
- 失效的订阅及时删除，长期留着会拖慢测速。
- 不同订阅的节点重名时，用分组而非名称来区分。
合并时的三条经验
第一，保留原始订阅链接作为回退手段，转换环节出问题时能立刻恢复可用状态。
第二，合并前先单独验证每份订阅可用，避免把一份失效订阅混进来导致整体不可用。第三，合并后先测速再投入日常使用，确认节点数量与预期一致。
获取规则分流客户端订阅合并的高频疑问
合并后节点变少了是怎么回事？
可能是转换环节过滤了重复或不支持协议的节点，也可能某份订阅已经失效。分别单独导入核对数量即可定位。
可以只合并节点、保留各自规则吗？
可以。转换时只处理节点部分、规则部分留空，再在客户端内单独维护规则，是常见的折中做法。
合并后的订阅还需要单独更新吗？
需要看转换环节是否自动同步原始订阅。若不自动同步，服务方变动时需要重新生成一次。