client/subscription · 集群 A · 订阅原理与格式 · 4/6

多个机场订阅如何合并：代理集合、覆写与转换三种做法对比

为什么要合并订阅

合并订阅的主要价值是“单一入口、主备切换”，即在一个客户端里同时持有两家服务商的节点，一家出问题时可以立刻切到另一家。

常见的合并动机包括：

• 分散风险：不把所有使用需求压在一家服务商上，这与 机场跑路风险 专题讨论的分散策略一致。
• 场景分工：一家负责日常通用访问，另一家负责特定场景。
• 流量调配：小流量套餐用于日常，大流量套餐用于下载或视频。

不建议为了“节点越多越好”而合并。节点数量多不等于可用节点多，合并过多订阅还会让测速组变慢、配置变臃肿、排障更困难。

三种合并方式对比

三种方式的核心差异在于“订阅令牌在谁手里”和“各订阅是否独立更新”。

从隐私与稳定两个角度看，代理集合与客户端覆写都在本机完成，是更推荐的做法；转换合并若要使用，应当在本机或自建环境中运行，原因见 第三方订阅转换服务有哪些隐私风险。

代理集合方式的结构

代理集合把“节点来源”与“策略组”解耦：每个订阅是一个独立的集合，策略组按名称引用集合。

proxy-providers:
  provider-A:            ← 主服务商订阅，独立更新间隔
    type: http
    url: <A 的订阅地址>
    interval: <秒数>
    path: ./providers/a.yaml
    health-check: 开启，定期探测
  provider-B:            ← 备用服务商订阅
    type: http
    url: <B 的订阅地址>
    ...

proxy-groups:
  主力选择:   use: [provider-A]
  备用选择:   use: [provider-B]
  故障转移:   proxies: [主力选择, 备用选择]   ← 主力不可用时切换

这样做的好处：

1. A 订阅更新失败不影响 B 订阅已缓存的节点。
2. 每个集合可以单独设置更新间隔与健康检查，间隔怎么设可参考 订阅更新间隔怎么设置。
3. 规则与策略组写在本地，不会被任何一家订阅更新覆盖。

需要注意的是，代理集合要求订阅返回的内容是内核能解析的节点列表，具体支持的格式以所用内核版本的文档为准。

客户端覆写方式的要点

如果不想手写 YAML，可以利用图形客户端的覆写、合并或脚本功能，把多个订阅与个人规则组合起来。

各客户端的功能名称不同，常见思路是：

• 分别导入多个订阅作为独立配置；
• 新建一份“合并 / 覆写”配置，引用前面的订阅并追加自定义策略组；
• 启用合并后的配置作为当前运行配置。

这种方式的风险点在于客户端版本更新后功能入口可能变化，建议记录自己的配置步骤。桌面端的具体操作可参考 桌面客户端 专题。

合并后的常见问题

合并后最常见的问题是节点重名、分组为空和流量显示混乱，这三类问题都能通过命名与分组设计避免。

流量显示问题尤其要注意：客户端面板上显示的剩余流量和到期时间，往往只来自其中一个订阅的响应头，另一家的用量需要到其后台查看。相关机制见 订阅里的流量与到期信息是怎么显示出来的。

合并前先规划命名与分组

在动手合并之前，花几分钟规划命名与分组，比合并后再修修补补省事得多。规划的核心是让每个节点一眼就能看出“来自哪家、在哪个地区”。

命名规划示例：
  来源前缀 + 原节点名
  [A] 香港 01      [A] 日本 02
  [B] 香港 01      [B] 新加坡 01

分组规划示例：
  主力（仅 A）  ← 日常默认
  备用（仅 B）  ← 手动或故障转移
  按地区（A+B 混合，按关键词筛选）← 可选

有了来源前缀，即使两家都有名为“香港 01”的节点也不会冲突；按来源分组则让主备边界清晰，切换时不会误选。至于是否需要“按地区混合分组”，取决于你是否真的需要在两家之间按地区挑节点——对大多数主备场景来说，按来源分组已经足够。

小结

合并订阅首选本地完成：代理集合适合愿意写配置的用户，客户端覆写适合图形界面用户；转换合并只在可控环境里用。合并的目标是主备切换而非堆节点。

如果你正在为主备方案挑选第二家服务商，可以在 机场品牌库 按价格类型与流量筛选，再用 对比工具 对照资料字段；注意年付折算价与月付价不能直接比较。