mod_proxy_hcheck模块需正确加载并绑定到balancer成员才生效，健康检查依赖ProxyHCExpr自定义判断、hctimeout超时及hcfails连续失败阈值三者联动。
确认 mod_proxy_hcheck 模块已正确加载
运行 httpd -M | grep proxy_hcheck，若无输出，说明模块未启用。常见错误是写错路径或后缀：mod_proxy_hcheck.c（应为 .so）或路径与 httpd -V | grep SERVER_CONFIG_FILE 显示的实际模块目录不一致。正确写法是：LoadModule proxy_hcheck_module modules/mod_proxy_hcheck.so。
健康检查必须绑定到 BalancerMember 才生效
mod_proxy_hcheck 不是独立后台服务，它只在 ProxyPass + balancer:// 场景下触发。单独写 HCheck 或仅在
- 必须用
- 每个
BalancerMember必须显式带健康检查参数，例如：BalancerMember http://10.0.1.10:8080 hcmethod=GET hcuri=/health hcinterval=5 hcfails=3 hcpasses=2 -
hcmethod=GET发起真实 HTTP 请求（不是 TCP 握手），hcuri必须指向后端真实暴露的路径（如/actuator/health），不能是 Apache 自身的 location
仅靠状态码 2xx 默认不等于“健康”
Apache 默认把 2xx/3xx 视为成功，但很多后端健康接口返回 200 却带 {"status":"down"}。此时必须用 ProxyHCExpr 自定义判断逻辑，否则健康检查形同虚设。
- 基础写法：
ProxyHCExpr ok {%{REQUEST_STATUS} == 200} - 更稳妥写法（兼容 2xx/3xx 且 body 含 ok）：
ProxyHCExpr ok2xx {%{REQUEST_STATUS} =~ /^[23]/ && %{hc resp body} =~ /"status"\s*:\s*"ok"/}（注意：hc resp body仅在 Apache 2.4.49+ 支持） - 旧版本只能依赖响应头：
ProxyHCExpr ok {%{hc resp header X-Health} == "true"} - 每个
BalancerMember需通过hcexpr=ok引用对应表达式
调试时别只看 balancer-manager 页面
页面上显示的 UP/DOWN 是最终聚合状态，看不出每次检查是否发出、收到什么响应、为何失败。真正的问题往往藏在日志里。
- 临时开启高粒度日志：
LogLevel proxy_hcheck:trace8 - 在
error.log中搜索hcheck关键字，确认：是否发出了请求、目标地址是否正确、超时时间是否够用（hctimeout默认 5 秒）、响应体是否被截断 - 注意
hcfails=3和hcpasses=2是“连续”计数，中间穿插一次成功就会重置失败计数
健康检查的真实行为取决于三者联动：状态码匹配逻辑（ProxyHCExpr）、超时设置（hctimeout）、连续失败阈值（hcfails）。漏掉任意一环，节点就可能持续接收流量，即使后端早已不可用。
