hcinterval、hcfails、hcpasses共同控制状态切换：hcinterval=5～15秒设定检查频率，hcfails=3要求连续3次失败才标为down，hcpasses=2需连续2次成功才恢复up，避免抖动误判。
hcinterval、hcfails、hcpasses参数如何影响状态切换
健康检查不是“一锤定音”，而是靠连续成功/失败次数触发状态变更。Apache 不会因为单次超时或 500 就立刻标记节点 down，必须满足 hcfails 次连续失败才进入 Down 状态；同样，恢复也不是一次成功就切回，得等 hcpasses 次连续成功才变 Up。
常见错误是把 hcfails=1 或 hcpasses=1 当成“实时响应”，结果导致抖动频繁上下线。实际中建议：
- hcfails=3（避免网络瞬断误判）
- hcpasses=2（防止后端刚恢复一半就导流）
- hcinterval=5～15（太短压后端，太长故障发现慢）
为什么 hcpass=2 成功后仍不恢复？检查 hcexpr 是否生效
默认情况下，mod_proxy_hcheck 只看 HTTP 状态码是否为 2xx/3xx。但很多后端的 /healthz 接口返回 200，body 却是 {"alive":false}——这时 hcpasses 计数根本不会累加，因为检查逻辑没通过。
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
必须配合 ProxyHCExpr 自定义判断，否则 hcpasses 形同虚设：
- Apache ≥2.4.49 才支持 %{hc resp body}
- 旧版只能用响应头，例如：ProxyHCExpr ok %{hc resp header X-Health} == "true"
- 表达式名（如 ok）需在 BalancerMember 中通过 hcexpr=ok 引用
failover 后 retry=60 和 hcfaillovertime 的区别
这两个参数常被混用，但作用完全不同：
- hcfaillovertime=30 是主动健康检查的“冷却期”：节点被标为 Down 后，30 秒内不再发起任何健康请求（哪怕 hcinterval=5）
- retry=60 是被动失败的“隔离期”：某次真实业务请求失败（如超时、502），Apache 会暂停向该节点转发新请求 60 秒，不管它当前健康检查状态是 Up 还是 Down
- 两者可共存：一个管探针节奏，一个管真实流量兜底
状态切换后请求是否立即绕过？注意 balancer-manager 的显示延迟
节点从 Up → Down 后，新请求确实会立刻跳过该成员；但从 Down → Up 的瞬间，可能仍有少量请求正在途经旧连接池。这不是 bug，而是 Apache 的连接复用机制决定的。
验证状态最准的方式不是看日志，而是访问 /balancer-manager 页面（需启用 mod_manager）：
- 状态列显示 Down 且“Failed”计数持续增长，说明 hcfails 已触发
- “Succ”列连续增加且“Failed”归零，说明 hcpasses 正在累积
- 如果“Succ”卡住不动，大概率是 hcexpr 表达式没匹配上响应内容
