本页目录（8）
一句话结论：备用机场是一份很便宜的保险：主力机场遇到敏感时期、线路故障或跑路时，你不会突然失联。备用最好选线路架构不同的按量套餐，再用 fallback 策略组让客户端自动在主备之间切换。
为什么要准备备用机场
很多人只用一家机场，平时也确实没什么问题。但单一机场意味着所有风险都集中在一个点上，下面这些情况任何机场都可能遇到：
- 敏感时期大面积失联：同一家机场的节点往往使用相近的协议和线路，一旦被针对，可能整体不可用，详见 敏感时期机场连不上怎么办。
- 线路或机房故障：中转服务器宕机、上游线路调整，可能导致一段时间内大部分节点超时。
- 官网和订阅同时被墙：节点失效后你却无法更新订阅，也打不开官网看公告，陷入「需要翻墙才能修好翻墙」的死循环。
- 跑路：机场停止运营，往往没有任何预告，参见 机场跑路的征兆与防范。
有了备用机场，上面任何一种情况发生时，你都能立刻切过去，再从容地处理主力机场的问题。对于依赖境外网络工作的人来说，这比主力机场快一点慢一点重要得多。
主备机场怎么搭配才互补
备用机场的价值在于「主力出问题时它没出问题」。如果两家机场线路、协议都差不多，很可能一起失效，备了等于没备。搭配时可以参考以下原则：
| 维度 | 建议 | 原因 |
|---|---|---|
| 线路架构 | 一家以直连为主，一家以中转或专线为主 | 不同架构受同一类故障或封锁影响的概率更低 |
| 协议 | 备用至少提供 VLESS Reality 或 Trojan | 高伪装协议在敏感时期更可能存活 |
| 付费方式 | 备用选按量付费或便宜的低流量套餐 | 平时几乎不用，不应占用太多预算 |
| 流量有效期 | 备用流量最好长期有效或有效期较长 | 一年用不上几次，按月清零的流量多半浪费 |
常见的组合思路有两种：
专线主力 + 低价备用
主力选稳定的专线机场，保证工作和高峰期体验；备用选便宜的直连机场，主要用于主力维护、跑路或流量用完时的过渡。专线机场可参考 IPLC 专线机场推荐。
三种自动策略组：url-test、fallback、load-balance
手动切换主备完全可行，但用 Clash / mihomo 内核的客户端可以让切换自动完成。核心是理解三种自动策略组的区别（以 mihomo 文档为准）：
| 类型 | 选择逻辑 | 适合场景 |
|---|---|---|
url-test | 定期测试延迟，选延迟最低的节点；tolerance 设定切换容差（毫秒），新节点比当前快不到这个值就不切换 | 同一机场内自动挑快节点 |
fallback | 按列表顺序，选第一个可用的节点，前面的不可用才往后切 | 主备机场，主力优先 |
load-balance | 把连接分配到多个节点，策略有 round-robin、consistent-hashing、sticky-sessions | 多线程下载等少数场景 |
对于主备机场，fallback 是最合适的：平时始终用主力，主力不可用时才切到备用，主力恢复后又会切回来。url-test 只看延迟，可能在主备之间频繁跳动；load-balance 会让出口 IP 不断变化，访问 ChatGPT、银行、游戏等对 IP 敏感的服务时容易触发风控，参见 节点 IP 被风控怎么办。
用 proxy-providers 和 fallback 配置主备自动切换
思路是：用 proxy-providers 分别引入两家机场的订阅，各自建一个 url-test 组挑出本机场最快的节点，再用一个 fallback 组把「主力组」放在前、「备用组」放在后。示例如下：
proxy-providers:
main-sub:
type: http
url: "主力机场的 Clash 订阅链接"
path: ./providers/main.yaml
interval: 86400
health-check:
enable: true
url: https://www.gstatic.com/generate_204
interval: 300
backup-sub:
type: http
url: "备用机场的 Clash 订阅链接"
path: ./providers/backup.yaml
interval: 86400
health-check:
enable: true
url: https://www.gstatic.com/generate_204
interval: 300
proxy-groups:
- name: 主力自动
type: url-test
use:
- main-sub
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50
- name: 备用自动
type: url-test
use:
- backup-sub
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50
- name: 主备切换
type: fallback
proxies:
- 主力自动
- 备用自动
url: https://www.gstatic.com/generate_204
interval: 300
- name: 节点选择
type: select
proxies:
- 主备切换
- 主力自动
- 备用自动
- DIRECT
rules:
- GEOIP,CN,DIRECT
- MATCH,节点选择几点说明：
- provider 的名字不要和策略组同名，否则可能冲突。
- 健康检查分两层：按 mihomo 文档，策略组的
url只检查写在proxies里的成员，通过use引入的节点由 provider 自己的health-check负责，所以两处都要配置。 - 间隔单位是秒：
interval: 300即五分钟检测一次。故障到切换之间会有一段延迟，这是正常的。 - 可以用
filter筛节点：例如只让主力组使用香港、日本节点，或排除高倍率节点，正则写法以 mihomo 文档为准。 - rules 只是示意：实际使用时应保留完整的分流规则，这里只演示策略组之间的关系。
如果你用的是 Clash Verge Rev，一般不需要从零手写整份配置，可以在它的扩展配置（覆写）功能里追加 provider 和策略组；OpenClash 用户则可以在自定义配置中实现同样的结构。客户端的具体操作见 Clash Verge Rev 教程 和 OpenClash 教程。
主备方案的几个常见误区
- 备用买得太贵：备用一年可能只用十几天，买一个和主力同价位的大流量月付套餐，大部分钱都浪费了。按量付费、流量长期有效的套餐更合适。
- 两家都是年付：年付本身就有跑路时损失较大的风险，两家都年付等于把风险翻倍。主力是否年付可以权衡，备用尽量避免，参见 机场年付还是月付。
- 以为 fallback 能解决一切：fallback 只在节点「完全不可用」时切换。如果主力只是变慢、丢包严重但还能通过健康检查，它不会切到备用，这种情况仍需手动切换或参考 晚高峰很慢的排查方法。
- 账号用同一个邮箱和密码：两家机场最好使用不同的密码，避免一家泄露牵连另一家。
- 备用订阅从不更新：机场会更换节点地址，几个月不更新的备用订阅很可能已经失效，而真正需要时你可能已经无法更新它了。
不想折腾配置：手动主备也够用
自动切换不是必需的。对大多数人来说，下面这种手动方式已经足够：
- 两份订阅都导入客户端：平时启用主力订阅，备用订阅放在列表里。
- 定期更新备用订阅：每个月左右切过去用一次，确认能用。
- 主力出问题时一键切换：在订阅列表里点选备用配置即可，手机上的 Shadowrocket 也可以同时添加多个订阅。
- 用备用修复主力：通过备用机场访问主力的官网和官方频道，查看公告、更新订阅，参见 机场官网打不开怎么办。
无论自动还是手动，关键都在于：备用要提前准备、定期验证，而且和主力尽量不同。
常见问题
备用机场选什么类型比较好？
fallback 和 url-test 有什么区别？
url-test 定期测延迟，自动选最快的节点；fallback 按你写的顺序，选第一个可用的节点，只有前面的不可用时才往后切。前者追求速度，后者追求主次分明，适合主备机场。fallback 切换是即时的吗？
interval 决定（单位秒），所以从故障到切换可能有一段延迟。间隔设得太短会频繁发起测试请求，一般设几分钟即可。