mod_proxy_hcheck支持业务级健康检查，需Apache 2.4.47+，配置hcuri、hcmethod、hcinterval，并用ProxyHCExpr解析响应体判断ready等业务状态，避免误判副作用接口。
Apache 的 mod_proxy_hcheck 模块支持对后端服务发起真实 HTTP 请求，因此完全可以用于探测特定业务接口（如 /api/v1/health、/actuator/ready 或自定义的业务就绪路径），而不仅限于基础的 / 或 /healthz。关键在于把健康检查行为与业务语义对齐——既要发对请求，也要判对响应。
确认模块可用并加载
必须使用 Apache 2.4.47 及以上版本，且手动加载模块：
- 执行
httpd -M | grep proxy_hcheck，无输出则需添加：LoadModule proxy_hcheck_module modules/mod_proxy_hcheck.so - 路径要与
httpd -V | grep SERVER_CONFIG_FILE中显示的模块目录一致，常见错误是漏掉.so后缀或写成.c
绑定到具体业务路径与方法
在 <proxy></proxy> 块中为每个 BalancerMember 显式指定探测目标：
WebChat Voice Proxy
下载
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
-
hcuri="/api/v1/health"：指向你后端暴露的真实业务健康端点（不是 Apache 自身路径） -
hcmethod=GET或hcmethod=HEAD：优先用HEAD减少后端开销；若业务接口仅响应GET或需检查响应体内容，则用GET -
hcinterval=10：每 10 秒探测一次，频率需匹配业务接口稳定性（太密易压垮，太疏延迟恢复）
用 ProxyHCExpr 判断业务级健康状态
仅靠 HTTP 状态码（如 200）远远不够。很多业务接口返回 200 但 body 是 {"status":"degraded","db":"unavailable"}。必须用表达式解析响应内容：
- 示例：要求 JSON 中
"ready"字段为true：ProxyHCExpr ready {%{hc resp body} =~ /"ready"\s*:\s*true/} - 注意：
%{hc resp body}在 Apache 2.4.49+ 才支持；旧版本只能依赖状态码 + 响应头（如%{hc resp header X-Ready}） - 在成员中引用：
BalancerMember http://10.0.1.20:8080 hcexpr=ready hcuri=/api/v1/health hcinterval=15
避免常见业务误判陷阱
业务接口常有特殊行为，配置需针对性规避：
- 若接口返回
200 OK但含Set-Cookie或Vary头，健康检查可能失败（Apache 默认不缓存带这些头的响应，但 hcheck 不涉及缓存逻辑，此处影响的是日志或调试判断） - 若业务接口依赖请求头（如
X-Forwarded-For或认证 token），需配合RequestHeader set注入，或让后端健康端点忽略这些校验 - 不要用
hcmethod=GET探测有副作用的业务路径（如/api/v1/reset），否则会意外触发业务操作
