1. 为什么手写合并配置文件是极其危险的劣质做法？
很多用户购买了两家不同服务商的套餐互备，通常会想办法把两家的节点复制到一个文件里：
- **致命缺点一：丧失自动更新能力**。一旦手动合成文件，远程机场更换节点 IP 时，你的本地配置无法再自动同步；
- **致命缺点二：格式冲突与重名崩溃**。两家机场可能使用了相同的策略组名称（如都叫 `PROXY` 或 `自动选择`），直接合并会引发命名空间冲突导致内核闪退。
**最佳工程实践是：利用 Proxy-Providers 将两家机场抽象为独立的动态供应源！**
💡 解耦后，机场 A 和机场 B 各自独立按时自动刷新，策略组自动感知节点变化。
2. 生产级多订阅聚合配置文件范例
以下展示如何用一个轻量的主配置文件聚合两家机场节点，并构建全自动故障转移：
yaml
# 多订阅聚合标准主配置文件
mixed-port: 7890
mode: rule
log-level: info
# 1. 声明两家独立机场作为动态供应源
proxy-providers:
airport-primary:
type: http
url: "https://sub.airport-a.com/api/v1/client/subscribe?token=TokenA"
path: ./profiles/proxies/airport-a.yaml
interval: 86400
health-check:
enable: true
url: "https://www.gstatic.com/generate_204"
interval: 300
airport-backup:
type: http
url: "https://sub.airport-b.com/sub?token=TokenB"
path: ./profiles/proxies/airport-b.yaml
interval: 86400
health-check:
enable: true
url: "https://www.gstatic.com/generate_204"
interval: 300
# 2. 跨机场聚合策略组构建
proxy-groups:
# 总代理出口：跨两家机场自动测速挑选延迟最低的香港专线
- name: "🇭🇰 香港-双机场跨源优选"
type: url-test
tolerance: 50
use:
- airport-primary
- airport-backup
filter: "(?i)香港|HK"
url: "https://www.gstatic.com/generate_204"
interval: 300
# 高可用熔断组：主力挂掉自动切备用
- name: "🛡️ 容灾主备-故障转移"
type: fallback
proxies:
- "🇭🇰 香港-双机场跨源优选"
- DIRECT
rules:
- GEOIP,CN,DIRECT
- MATCH,🇭🇰 香港-双机场跨源优选3. Clash Verge Rev 图形化 Merge 覆写实操
如果你使用的是 Clash Verge Rev，甚至不需要手动编辑文件：
1. 在「订阅」列表中正常导入机场 A 和机场 B；
2. 进入「扩展配置（Merge）」板块，新建一个 Merge 脚本；
3. 在脚本中通过 JavaScript 动态遍历两份配置的 `proxies` 列表并合并到自定义策略组中；
4. 保存后一键生效，享受极致的可视化多订阅管理体验。
❓ 常见疑问与排查步骤
同时拉取两家机场的订阅会导致流量翻倍消耗吗？
不会。拉取订阅只是下载几十 KB 的节点文本数据，实际消耗的套餐流量取决于你日常上网看视频产生的数据，用哪个节点就只扣哪个机场的流量。
两家机场的节点名称重复（比如都叫「香港 01」）会冲突吗？
在同一个策略组里如果出现完全同名的节点，内核可能会无法区分。可以在 Provider 中配置 `override: { prefix: '机场A-' }` 强制为节点名称添加前缀消除冲突。
多订阅聚合能叠加两家机场的物理下载带宽吗？
单个单线程下载连接无法叠加带宽；若使用多线程下载工具（如 IDM）搭配 `load-balance` 负载均衡组，可以在一定程度上实现并发带宽叠加。