Apache实现秒级故障转移关键在于hcinterval、hcfails、hcpasses协同控制状态切换节奏，并配合hcexpr精准判定及retry/hcfaillovertime双机制隔离，全过程可在5～10秒内完成。

apache 使用 mod_proxy_hcheck 实现秒级故障转移，关键不在“单次响应快”，而在于快速探测 + 合理计数 + 精准判定 + 即时路由调整。它不是靠一次超时就切走，而是通过连续失败/成功触发状态变更，并配合负载均衡器自动绕过 down 节点——整个过程可在 5～10 秒内完成，接近秒级。

hcinterval、hcfails、hcpasses 三参数协同控制切换节奏

这三者共同决定从“第一次失败”到“正式标记为 Down”，再到“恢复为 Up”的时间窗口：

• hcinterval=5：每 5 秒发起一次健康检查（推荐 5～10 秒，兼顾灵敏与压力）
• hcfails=3：连续 3 次失败才标为 Down → 最坏情况需 15 秒（3×5）才下线
• hcpasses=2：连续 2 次成功才恢复 Up → 恢复最快 10 秒（2×5）

实际中若希望更激进的秒级响应，可微调为：

• hcinterval=3（最低建议值，避免压垮后端）
• hcfails=2（两次失败即 Down，防瞬断可加 hctimeout=2 缩短单次等待）
• hcpasses=1（慎用！仅当后端恢复极稳、且能容忍误切时考虑）

⚠️ 注意：hcpasses=1 容易导致“刚恢复一半就导流”，引发雪崩；生产环境仍推荐 hcpasses=2。

hcexpr 必须写对，否则探测永远“假成功”

默认只看 HTTP 状态码（2xx/3xx），但很多 /healthz 接口返回 200 + {"status":"down"} ——这时 hcpasses 根本不累加。

必须显式定义判断逻辑，例如：

WebChat Voice Proxy

⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**

下载

ProxyHCExpr ok "%{hc resp body} =~ /\"alive\":true/"
BalancerMember http://node1:8080 hcexpr=ok

或旧版 Apache（

ProxyHCExpr ok %{hc resp header X-Health} == "ok"

验证方式：访问 /balancer-manager，看对应节点的 “Succ” 列是否随健康响应递增；若卡住不动，大概率是 hcexpr 没匹配上。

failover 的真正实现依赖 retry 和 hcfaillovertime 分工

故障发生后，Apache 不是“等状态变 Down 才切”，而是双机制并行：

• 主动探测层（hcfaillovertime）：节点标为 Down 后，hcfaillovertime=30 表示 30 秒内不再发健康请求（节省探针资源）
• 真实流量层（retry=60）：某次业务请求失败（如超时、502），立刻暂停向该节点派发新请求 60 秒，不管它当前健康状态如何

两者叠加，确保：

• 新请求在几秒内避开已知失败节点（靠 retry 隔离）
• 健康检查不盲目重试（靠 hcfaillovertime 冷却）
• 恢复后由 hcpasses 控制何时重新接纳流量（防抖动）

切换后请求是否立即绕过？要看连接池和 balancer-manager 状态

• 从 Up → Down：新请求立刻跳过，无延迟
• 从 Down → Up：少量请求可能仍在旧连接池中发出（Apache 复用 keepalive 连接），属正常行为，非 bug
• 最准验证方式：打开 /balancer-manager 页面（需启用 mod_manager），观察：
  • “Status” 列实时变化
  • “Failed” 计数持续增长 → hcfails 已生效
  • “Succ” 归零后重新上涨 → hcpasses 开始累积

不复杂但容易忽略。