Apache默认不主动探测后端健康状态，必须显式启用mod_proxy_hcheck模块并配置hcmethod、hcuri、hcinterval、hcfail、hcpass和hcexpr等参数，结合retry、failonstatus等被动机制，才能实现故障节点自动剔除与恢复。
Apache 本身不主动探测后端健康状态，mod_proxy_balancer 默认只做静态轮询。要实现故障节点自动探测与恢复，必须显式启用并精细配置健康检查模块与相关参数，不能依赖默认行为。
必须启用 mod_proxy_hcheck 模块
这是实现主动探测的前提（仅 Apache 2.4.33+ 支持）：
LoadModule proxy_hcheck_module modules/mod_proxy_hcheck.so
Ubuntu/Debian 可用 a2enmod proxy_hcheck；RHEL/CentOS 需确认 /etc/httpd/conf.modules.d/00-proxy.conf 中已加载该模块。
仅启用 mod_proxy_balancer 不够，不加载 hcheck 模块，所有 hc* 参数均无效。
为每个后端配置主动健康检查参数
在 <proxy balancer:>…</proxy> 块中，为每个 BalancerMember 显式设置以下关键参数：
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
- hcmethod=HTTP：使用 HTTP 请求探测（推荐 HEAD 或 GET）
-
hcuri=/health：指向后端真实暴露的健康端点（如 Spring Boot 的
/actuator/health），不能是 Apache 自身路径 - hcinterval=10：每 10 秒探测一次（不宜过短，避免压垮后端）
- hcfail=3：连续 3 次失败才标记为 DOWN（设为 1 易受网络抖动误判）
- hcpass=2：连续 2 次成功才恢复为 UP
- hcexpr="%{REQUEST_STATUS} == 200"：自定义判断逻辑，仅靠默认 2xx/3xx 匹配不够可靠，需明确指定期望状态码
示例：BalancerMember http://192.168.1.10:8080 hcmethod=HEAD hcuri=/health hcinterval=10 hcfail=3 hcpass=2 hcexpr="%{REQUEST_STATUS} == 200"
配合被动机制增强容错能力
主动探测无法覆盖所有异常（如连接建立但响应卡死），需叠加被动策略：
- retry=60：节点被标记为 DOWN 后，60 秒内不参与分发；超时后自动重试一次（成功即恢复，失败继续隔离）
- failonstatus=500-599：代理收到 5xx 响应即计入失败计数，加速触发下线
- timeout=5：单次请求超时设为 5 秒，避免长等待阻塞调度
- maxattempts=2：允许最多尝试两个后端，确保首次失败可快速切走
这些参数写在 BalancerMember 行内或通过 ProxySet 统一设置均可。
验证与调试不能只看 balancer-manager
balancer-manager 页面显示的是最终状态（OK/DOWN），不反映实时探测过程。
真正的问题常藏在日志里：
- 开启详细日志：
LogLevel proxy_hcheck:trace8 - 在 error.log 中搜索
hcheck，确认是否发出请求、收到什么响应、是否匹配 hcexpr - 检查后端 /health 接口能否被 Apache 进程稳定访问（如
curl -I http://192.168.1.10:8080/health）
若日志无 hcheck 记录，说明模块未加载或配置未生效。
