mod_proxy_hcheck 默认不因500摘除节点，需通过failonstatus=500（被动）或ProxyHCExpr自定义表达式（主动）配置；摘除后分别按retry时间或hcpasses成功次数恢复。
apache 的 mod_proxy_hcheck 本身不因后端返回 500 就自动摘除节点——它默认只看连接是否通、状态码是否为 2xx/3xx，而不会把 500 当作“故障信号”主动下线。要让 500 触发摘除，必须显式配置策略。
需配合 failonstatus 实现 500 摘除
该参数属于 mod_proxy_balancer，需在 BalancerMember 或 ProxyPass 中声明，作用是：当后端真实响应中包含指定状态码时，立即将该成员标记为 Down，并进入 retry 冷却期。
例如：
<proxy>
BalancerMember http://backend1:8080 hcinterval=10 hcfails=3 hcpasses=2
BalancerMember http://backend2:8080 hcinterval=10 hcfails=3 hcpasses=2
</proxy>
ProxyPass / balancer://mycluster/ failonstatus=500
-
failonstatus=500表示：只要某次业务请求（非健康检查）收到 500 响应，该 backend 就被临时隔离 - 隔离后不再接收新请求，持续时间由
retry=60（默认）控制 - 注意：这不是健康检查行为，而是被动失败兜底机制，和
hcfails无关
若想用健康检查（hcheck）主动探测 500 并摘除
需绕过默认逻辑，用 ProxyHCExpr 自定义判断：
ProxyHCExpr is_500 {%{REQUEST_STATUS} == 500}
# 在 BalancerMember 中引用
BalancerMember http://backend1:8080 hcexpr=is_500 hcfails=1 hcpasses=1
但要注意：
WebChat Voice Proxy
下载
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
-
hcfails=1极易抖动，不建议用于生产 - 更稳妥的是结合响应体内容判断“是否真故障”，比如：
ProxyHCExpr backend_down { %{REQUEST_STATUS} == 500 && hc('body') =~ /Internal Server Error|NullPointerException/ } BalancerMember http://backend1:8080 hcexpr=backend_down hcfails=2 hcpasses=2
摘除后如何恢复？
- 被
failonstatus标记的节点，在retry秒后自动重试（如retry=60） - 被
hcheck标记为 Down 的节点，需连续hcpasses次健康检查成功才恢复 Up - 两者可并存：
failonstatus管业务请求失败，hcheck管探针稳定性
验证是否生效
访问 /balancer-manager 页面，观察：
- “Status”列变为
Down - “Failed”计数上升，且“Succ”停止增长（若用 hcheck）
- 日志中出现类似
proxy_balancer: down for maintenance提示
不复杂但容易忽略
