mod_proxy_balancer健康检查需显式启用：加载proxy_hcheck模块，为balancermember配置hcmethod、hcuri等参数，并用proxyhcexpr自定义状态判断；仅状态码匹配不足，须结合超时与连续失败次数才触发下线；恢复需满足连续成功+冷却期；调试应查日志而非仅看balancer-manager。

mod_proxy_balancer 的健康检查必须显式启用

Apache 默认不开启后端节点健康检查，mod_proxy_balancer 只做静态轮询。不配置 ProxyHCExpr 和 ProxyHCTemplate，节点即使持续返回 502/503 也不会被标记为失效。

实操建议：

• 确保已加载 mod_proxy_hcheck（Apache 2.4.33+），用 a2enmod proxy_hcheck 启用
• 在 <proxy balancer:></proxy> 块内为每个 BalancerMember 显式添加 hcmethod=HEAD hcuri=/health hcinterval=10
• hcuri 必须指向后端真实暴露的健康端点（如 /actuator/health），不能是 Apache 自身的路径
• 避免使用 hcmethod=GET 对高频接口，可能引发误判或压垮后端

故障剔除依赖响应状态码与超时组合判断

仅靠 HTTP 状态码不足以触发剔除——Apache 要求同时满足「状态码匹配」+「超时」+「连续失败次数」三个条件才会将节点置为 DOWN。

常见错误现象：后端返回 503，但节点仍显示 OK，流量继续转发过去。

原因和对策：

• 默认 hcstatus 只认 2xx/3xx 为健康，5xx 不自动触发剔除；需用 ProxyHCExpr 自定义表达式，例如：

  ProxyHCExpr ok {%{REQUEST_STATUS} =~ /^[23]/}

• hcfailures=3 表示连续 3 次失败才下线，若后端偶发超时，可调低至 2，但不宜设为 1（网络抖动易误剔）
• hctimeout=5 必须小于后端实际处理耗时，否则健康检查总超时，节点反复进出 DOWN 状态

恢复逻辑不是“检测一次 OK 就上线”

节点从 DOWN 恢复需满足两个独立条件：健康检查连续成功 + 经过冷却期（hcinterval × hcfailures），否则会立即再次失败并重新下线。

典型陷阱：

• 把 hcinterval 设为 2 秒、hcfailures 设为 3，意味着节点至少要空等 6 秒才允许首次恢复检查
• 后端刚重启，/health 返回 200，但业务接口尚未就绪，此时 Apache 已恢复转发，导致用户看到 502
• 未设置 retry=60（单位秒），节点一旦进入 DOWN，默认 60 秒后才尝试恢复检查；若设为 0，则永不自动恢复，必须手动 a2ctl graceful

调试时别只看 balancer-manager 页面

balancer-manager 显示的 OK/DOWN 是最终状态，不反映实时检查过程。真正的问题常藏在日志里。

关键操作：

• 开启 LogLevel proxy_hcheck:trace8，在 error.log 中搜索 hcheck 关键字，确认是否发起请求、收到什么响应、为何判定失败
• 用 curl -I http://localhost:8000/health 模拟健康检查请求，验证后端响应头是否含 Content-Length（某些精简框架会省略，导致 mod_proxy_hcheck 解析失败）
• 检查后端是否对 HEAD 请求返回了非 2xx 状态码（比如 Spring Boot 默认对 HEAD /health 返回 405），此时必须改用 GET 并配 hcexpr

最易被忽略的是健康检查与后端真实就绪状态之间的时序差：Apache 认为“能通”，不等于“能服务”。把 /health 做成真正校验数据库连接、缓存连通性、下游依赖可用性的端点，比调高检查频率重要得多。