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://mycluster>块内为每个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 做成真正校验数据库连接、缓存连通性、下游依赖可用性的端点，比调高检查频率重要得多。
