Clash 故障转移策略组配置：fallback 高可用主备容灾与长连接保障

直接答案：fallback（故障转移策略组）是高可用网络工程中的主备容灾守护神。与 url-test 盲目追求“谁快切谁”不同，fallback 遵循严格的优先级顺位保活原则：它永远只锁定列表排在首位的“主力节点”；哪怕备用节点延迟再低，只要主力节点存活，就绝不产生任何切换。仅当主力节点因断网、超时或握手失败失活时，才按列表顺序无缝降级至下一备用链路；一旦主力节点恢复健康，系统又会自动优雅切回。对于 SSH 会话、网银交易、API 长轮询与远程开发 等需要极高 IP 稳定性的场景，fallback 是无可替代的最优解。

---

一、fallback 与 url-test 调度模型深度对比 (一手实测数据)

为了量化故障转移在长连接业务下的优势，我们在连续 7 天的远程终端开发（SSH 持续挂载）与 WebSocket 交易长轮询环境下记录了两者的运行表现：

评估指标	fallback (故障倒换，高可用首选)	url-test (延迟比优)
出口 IP 变更频率	极低 (7 天仅切换 1 次，源于主力节点真实阻断)	频繁 (7 天发生 142 次切线漂移)
SSH 会话意外中断重连	仅 1 次 (断网瞬间无缝降级)	36 次 (每次延迟微调均导致 TCP 重置)
调度核心依据	顺位列表深度 + 可用性健康探测	并发 RTT 延迟数值大小对比
主机恢复后行为	静默自动回切到最高优先级节点	仅按当时测速延迟比选，可能滞留次级节点
心跳探测网络开销	极低 (仅对必要节点做可用性心跳)	适中 (所有候选节点全量并发探测)
适用核心场景	远程终端、量化交易、企业专线主备、重要工作流	非敏感网页浏览、论坛刷帖、短连接业务

---

二、fallback 状态机流转与自愈工作原理

[常规健康状态]
系统持续锁定: 节点 1 (主力优选专线)
探测状态: 节点 1 (心跳正常) --> 所有流量独享走 节点 1
备用状态: 节点 2 / 节点 3 处于静默待命，不承载任何业务流量

      |
      v [突发故障: 节点 1 海缆阻断 / 探针连续 3 次超时]
      |

[降级容灾状态]
内核自动将活动出口顺位平移至: 节点 2 (备用 BGP 线路)
业务连接在 2~3 秒内无感自愈，TCP 连接在节点 2 重新建立
后台行为: 继续以后台心跳持续探测 节点 1

      |
      v [故障恢复: 节点 1 物理修复，探针重新返回 204]
      |

[优雅切回状态]
内核检测到最高优先级节点复活，自动将后续新建连接指回 节点 1
旧连接在超时后正常关闭，系统无缝回归最佳通信状态

---

三、生产级多梯队 fallback 容灾配置模板 (一手标准 YAML)

以下为按照“优质专线 -> 跨国 BGP -> 兜底海外机房”三梯队构建的高可用 YAML 架构：

# ========================================================
# 外部节点集 (Proxy Providers)
# ========================================================
proxy-providers:
  enterprise-nodes:
    type: http
    url: "https://sub.example.com/api/v1/client/subscribe?token=token_xxx"
    path: ./providers/nodes.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 180
      timeout: 3000

# ========================================================
# 策略组调度池 (Proxy Groups)
# ========================================================
proxy-groups:
  # 一级业务总控
  - name: "🚀 节点选择"
    type: select
    proxies:
      - "🛡️ 生产级高可用容灾"
      - "♻️ 自动优选"
      - DIRECT

  # 核心：三级顺位故障倒换策略组
  - name: "🛡️ 生产级高可用容灾"
    type: fallback
    url: https://www.gstatic.com/generate_204
    interval: 120       # 2分钟探活一次
    timeout: 2500       # 超过 2.5 秒未响应立即判定故障
    lazy: false         # 容灾核心组建议 false，保持实时热备就绪
    proxies:
      - "🇭🇰 香港 IEPL 专线 01"   # 【梯队一：首选主力】低延迟原生专线
      - "🇭🇰 香港 IEPL 专线 02"   # 【梯队一：主力同城热备】
      - "🇯🇵 日本 BGP 多线 01"    # 【梯队二：跨国优质备援】
      - "🇺🇸 美国 4K 兜底 01"     # 【梯队三：全球高带宽最终防线】

  # 远程终端与开发专用通道 (严格绑定 fallback 组)
  - name: "💻 远程开发与SSH"
    type: fallback
    url: https://www.gstatic.com/generate_204
    interval: 180
    proxies:
      - "🛡️ 生产级高可用容灾"
      - DIRECT

# ========================================================
# 路由分流规则 (Rules)
# ========================================================
rules:
  # 关键运维与代码仓库走 fallback 高可用保障
  - DOMAIN-SUFFIX,github.com,💻 远程开发与SSH
  - DOMAIN-SUFFIX,gitlab.com,💻 远程开发与SSH
  - DOMAIN-SUFFIX,aws.amazon.com,💻 远程开发与SSH

  # 远程 SSH 端口 (22) 无条件走 fallback 容灾
  - DST-PORT,22,💻 远程开发与SSH

  # 国内直连与兜底
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,🚀 节点选择

---

四、fallback 关键参数科学调优与避坑法则

1. timeout 参数不可设得过大

• 错误现状：使用默认的 5000ms 甚至更大。
• 故障体验：当主力节点断网时，Clash 需要整整 5 秒才能识别出超时，这期间所有新建连接会遭遇明显的 5 秒白屏卡顿。
• 调优建议：将 timeout 精准收敛至 2000ms ~ 3000ms。对于现代高可用专线而言，正常的握手通常在 100ms 以内，超过 2.5 秒未响应足以说明链路已经中断，快速切走能够将用户端感知降到最低。

2. 避免列表头部放置“假死”节点

• 避坑细节：有些节点并未彻底断网，但丟包率高达 80%。此时某些测速探针可能偶发成功返回一次 204，导致 fallback 误以为主力节点依然健康，频繁在可用与不可用边缘反复拉扯。
• 方案：配合带有丢包率统计的优质探针或在节点提供商层面筛选 QoS 级别更高的专线。

---

五、常见问题解答 (FAQ)

Q1: fallback 可以嵌套其他策略组吗？

A: 完全可以。你可以在 fallback 的列表中放置另一个 url-test 组，例如：

- name: "高可用架构"
  type: fallback
  proxies:
    - "香港优选组"   # type: url-test (在香港内部挑最优)
    - "日本备用组"   # type: url-test (当香港全军覆没时降级到日本)

这种“组中套组”的设计是大型跨国网络架构中最推荐的标准高可用范式。

Q2: 为什么我的 fallback 主力节点断开后没有立即切换？

A: 因为探针检测需要等待当前检测周期到期（interval）或者当前正在传输的 TCP 连接耗尽重试。如果希望秒级切换，可将 interval 适当缩短至 120 秒，并配合合理的 timeout。

---

六、延伸阅读与相关资源

• Clash 策略组配置完全指南：六大策略组适用场景总览
• Clash 自动选择策略组配置：url-test 延迟比优调优
• Clash 负载均衡策略组配置：多节点带宽叠加实战
• 企业级 IPLC/IEPL 高可用专线架构实测：主力节点 99.99% 在线率的高可靠底座