mod_proxy_hcheck模块需Apache 2.4.33+，正确加载为LoadModule proxy_hcheck_module modules/mod_proxy_hcheck.so；必须在BalancerMember中配置hc参数并绑定ProxyHCExpr表达式，且hcinterval、hcfails、hcpasses协同控制恢复逻辑。
确认 mod_proxy_hcheck 模块已正确加载
运行 httpd -M | grep hcheck，无输出说明模块未加载。常见错误是配置中写成 mod_proxy_hcheck.c 或漏掉 .so 后缀；正确写法必须是 LoadModule proxy_hcheck_module modules/mod_proxy_hcheck.so。路径要和 httpd -V | grep SERVER_CONFIG_FILE 显示的实际模块目录一致。Apache 2.4.33+ 才支持该模块，旧版本即使加了也会静默失败。
健康检查必须绑定到 ProxyPass 场景才生效
mod_proxy_hcheck 不是独立后台服务，它只在 ProxyPass 或 balancer:// 上下文中触发。单独写 HCheck 指令或只配 ProxyHCExpr 而不关联 BalancerMember，检查永远不会发起。典型结构是：
<proxy balancer:> BalancerMember http://10.0.1.10:8080 hcmethod=HTTP hcuri=/healthz hcinterval=5 hcfails=3 hcpasses=2 hcexpr=ok </proxy> ProxyPass "/api" "balancer://myapp/" ProxyPassReverse "/api" "balancer://myapp/"
注意：所有健康检查参数（如 hcinterval、hcuri）必须直接写在 BalancerMember 行内，不能提出来统一配置。
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
自定义响应判断必须用 ProxyHCExpr，否则默认逻辑几乎无效
默认只看 HTTP 状态码是否为 2xx/3xx，但很多后端健康接口返回 200 + {"alive":false}，这时候节点永远被标为 OK。必须显式定义表达式：
-
ProxyHCExpr ok {%{hc resp body} =~ /"status"\s*:\s*"ok"/}—— Apache 2.4.49+ 支持hc resp body - 旧版只能退而求其次：
ProxyHCExpr ok {%{hc resp header X-Health} == "true"} - 表达式名（如
ok）必须和hcexpr=ok中的值严格一致，大小写敏感 - 别忘了在
BalancerMember中引用它，否则表达式只是摆设
hcinterval、hcfails 和 hcpasses 的组合决定恢复节奏，容易卡住节点
节点从 DOWN 恢复不是“一次成功就上线”，而是要连续 hcpasses 次成功，且中间不能有间隔超过 hcinterval 的空档。比如 hcinterval=2 hcpasses=2，意味着至少得等 4 秒才可能恢复第一次检查；若后端刚启动但业务接口还没 ready，Apache 就已转发流量，导致用户看到 502。更隐蔽的问题是：retry=60（被动恢复）和 hcinterval（主动检查）会相互干扰——如果 retry 值小于 hcinterval × hcfails，节点可能根本等不到健康检查就又被跳过。
