必须用ProxyHCExpr，否则mod_proxy_hcheck仅依据2xx/3xx状态码判断健康，完全忽略JSON响应体中的status字段；默认不解析body因模块设计极简，且%{hc resp body}变量在2.4.49前不可用，旧版只能依赖响应头。
必须用 ProxyHCExpr，否则 mod_proxy_hcheck 只看状态码，根本不会解析响应体内容。
为什么默认健康检查不识别 JSON 响应里的 status 字段
Apache 的 mod_proxy_hcheck 默认逻辑极其简单：只要 HTTP 状态码是 2xx 或 3xx，就认为健康。它完全忽略响应体（body）和大部分响应头。后端返回 200 OK + {"alive":false}，模块照样标记为 UP。
常见错误现象：/healthz 接口始终返回 200，但业务已挂；balancer-manager 页面显示所有节点 OK，流量照常转发，用户持续收到 502。
-
hcmethod=HTTP和hcuri=/healthz只负责发请求、收状态码，不触发内容解析 -
%{hc resp body}这个变量在 Apache 2.4.49 之前不可用，旧版只能依赖响应头（如X-Health: true） - 没配
ProxyHCExpr，等于只开了个 HTTP 请求壳子，里面什么都没判断
如何写一个匹配 JSON 中 "status":"ok" 的 ProxyHCExpr
表达式需提前定义，再在 BalancerMember 中引用。注意语法严格，空格、引号、转义都影响匹配结果。
ProxyHCExpr ok {%{hc resp body} =~ /"status"\s*:\s*"ok"/}
关键点：
- 必须用
{%{...} =~ /.../}格式，不能漏掉大括号或波浪线 -
\s*允许status:和"ok"之间有任意空白（含换行），避免因格式化差异失败 - 如果后端返回的是
"status": "UP"，得改成/"status"\s*:\s*"UP"/ - 若 Apache 版本 %{hc resp body} 无效，只能退到响应头方案：
ProxyHCExpr ok {%{hc resp header X-Status} == "ok"}
BalancerMember 中如何正确绑定表达式与检查参数
hcexpr 必须和 hcuri、hcinterval 等一起写在同一个 BalancerMember 行内，且表达式名要完全一致（区分大小写）。
<proxy balancer:> BalancerMember http://10.0.1.10:8080 hcexpr=ok hcinterval=5 hcuri=/healthz </proxy>
容易踩的坑：
- 写成
hcexpr="ok"（加引号）——Apache 会报语法错误 - 表达式名拼错，比如定义了
ok却引用OK或health_ok，检查直接退化为默认状态码逻辑 -
hcuri指向的路径未暴露、返回 404 或超时，hcexpr根本不执行，日志里只会报“no response” - 没设
timeout=5，后端卡住时健康检查线程阻塞，导致整个hcinterval失效
调试内容匹配失败最有效的办法
别信 balancer-manager 页面的状态图标，它只显示最终结果。真正的问题藏在 error.log 里，且必须开足够细的日志级别。
- 在配置中加一行：
LogLevel proxy_hcheck:trace8 - 重启 Apache 后，
grep hcheck /var/log/apache2/error.log - 重点看三类日志：
hcheck: sending request（是否发出）、hcheck: received status（状态码）、hcheck: expr 'ok' evaluated to（表达式结果是 true 还是 false） - 如果看到
expr 'ok' evaluated to false，但你确信响应体含"status":"ok"，大概率是编码问题（如 BOM 头）或正则没覆盖空格/换行
内容匹配不是“开了就灵”，它高度依赖 Apache 版本、响应格式稳定性、以及表达式与真实 payload 的严丝合缝。少一个 \s*，多一个空格，都可能让整个健康检查失效。
