mod_proxy_hcheck模块依赖后端真实http响应的状态码和响应体判定健康,需手动加载、绑定balancermember、用proxyhcexpr自定义表达式,并结合failonstatus等被动检测增强鲁棒性。

Apache 的 mod_proxy_hcheck 模块本身不“感知”业务逻辑,但它能基于真实 HTTP 响应的状态码(REQUEST_STATUS)和响应体内容,做出是否标记后端为健康的关键判断。核心不是 Apache 自己生成状态码,而是忠实转发并解析后端 Java/Go/Node 应用返回的原始状态码——这才是健康感知的真正来源。
确认模块可用并正确加载
该模块从 Apache 2.4.33 起引入,但默认不启用,且低版本(如 2.4.41)可能缺失关键特性(如 hc resp body)。必须手动加载:
- 执行
httpd -M | grep hcheck,无输出说明未加载 - 在主配置或虚拟主机中添加:
LoadModule proxy_hcheck_module modules/mod_proxy_hcheck.so - 路径需与
httpd -V | grep SERVER_CONFIG_FILE输出的模块目录一致;常见错误是漏写.so后缀或误写为.c
绑定健康检查到具体后端节点
mod_proxy_hcheck 不是全局守护进程,它只在 ProxyPass 或 <proxy balancer:></proxy> 场景下、针对每个 BalancerMember 生效。单独写 HCheck 指令无效。
PHP中文网提供Apache 2.4.62 官方 tar.gz 源码包下载,通过源码编译安装,开发者能够灵活定制模块、优化性能并精准控制安装路径,满足多样化的业务需求。
- 必须配合
mod_proxy_balancer使用,例如定义负载均衡组:<proxy balancer:></proxy> - 为每个后端成员显式设置参数:
BalancerMember http://10.0.1.10:8080 hcmethod=GET hcuri=/healthz hcinterval=10 hcfails=3 hcpasses=2 -
hcmethod=GET表示发完整 HTTP 请求(非 TCP 探活),hcuri是后端暴露的健康端点路径,需确保该路径返回标准 HTTP 状态码
用 ProxyHCExpr 定义健康判定逻辑
默认行为仅认 2xx–3xx 为成功,但很多服务健康接口返回 200 + JSON {"status":"down"}。此时必须用 ProxyHCExpr 自定义表达式,否则健康检查形同虚设。
- 先定义表达式,例如要求状态码为 200 且响应体含
"alive":true:ProxyHCExpr alive {%{REQUEST_STATUS} == 200 && %{hc resp body} =~ /"alive"\s*:\s*true/} - 注意:
hc resp body在 Apache 2.4.49+ 才支持;旧版只能依赖状态码或响应头,例如:ProxyHCExpr ok200 {%{REQUEST_STATUS} == 200} - 在
BalancerMember中引用:hcexpr=alive
结合被动检测增强鲁棒性
主动检查再准也有盲区(如网络瞬断、连接建立成功但请求卡住)。建议叠加被动机制,形成双保险:
- 设置
failonstatus=500,502,503,504:任一真实请求返回这些码即计为一次失败 - 配
retry=60:节点被踢出后,60 秒内不尝试转发新请求 - 加
timeout=5:单次代理请求超时设为 5 秒,避免长阻塞拖垮整个连接池 - 这样即使某次健康检查刚好错过故障,后续真实请求失败也会快速触发隔离









