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 显式设置以下关键参数：

aperture: the L402 aware reverse proxy

安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。

下载

• 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 记录，说明模块未加载或配置未生效。