failonstatus是唯一能基于响应码触发被动摘除的参数；它在真实请求中捕获500-599等状态码并计数，达阈值后按retry时长隔离节点，但不发起探测且需配合retry才生效。
mod_proxy_balancer 默认不会因为后端返回 500、503 就自动剔除节点——它只在连接失败、超时或被显式标记时才跳过该节点。要让状态码真正触发摘除，必须配合 failonstatus 参数，并理解它和健康检查模块的分工边界。
failonstatus 是唯一能基于响应码触发被动摘除的参数
这个参数作用于「实际请求转发过程」中：当 Apache 代理一次真实用户请求，收到后端返回的匹配状态码时，会将该 BalancerMember 计入失败计数，达到阈值后置为 DOWN（受 retry 控制恢复时机）。
-
failonstatus=500,502,503,504：明确列出需识别的状态码，逗号分隔 -
failonstatus=500-599：支持范围写法，覆盖全部服务端错误 - 它不发起额外探测，只观察真实业务请求的响应；因此对偶发性 503 有天然容忍，但无法发现“静默宕机”（如进程卡死但 TCP 连接未断）
- 必须搭配
retry才有效果，否则节点失败后立即重试，等于没隔离
为什么只配 failonstatus 还不够？常见失效场景
你配置了 failonstatus=503，但节点仍在持续接收流量，balancer-manager 显示仍是 OK。原因通常有以下几点：
- 没设
retry：默认retry=60，但若你显式写了retry=0或漏配，节点失败后不会冷却，下个请求立刻重试，状态始终不落为DOWN - 后端返回的是连接超时/拒绝，而非 HTTP 响应：此时根本收不到状态码，
failonstatus完全不生效，得靠timeout+ping或mod_proxy_hcheck - 请求未经过
balancer://路径：比如你用ProxyPass /app http://backend/直连单节点，绕过了负载均衡器，failonstatus不起作用 - 日志级别太低，看不到失败计数变化：加
LogLevel proxy:info到配置中，查error_log里是否出现worker ... failed status类提示
与 mod_proxy_hcheck 的关键区别：别混用逻辑
failonstatus 和 mod_proxy_hcheck 解决的是不同层面的问题，不能互相替代，也不建议同时对同一节点用两套独立判断逻辑。
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
-
failonstatus是「被动反馈」：依赖真实业务请求流，适合捕获应用层异常（如 DB 连接池耗尽导致的 500） -
mod_proxy_hcheck是「主动探测」：独立于业务流量发健康请求，适合发现进程级宕机（如 Java 进程 OOM 后无响应） - 如果你已启用
mod_proxy_hcheck，它的hcmethod和hcuri决定是否 DOWN，failonstatus对健康检查请求本身无效（它只管用户请求） - 调试时优先确认：你看到的 503 是来自用户请求，还是健康检查请求？前者看
failonstatus，后者看ProxyHCExpr
最小可靠配置示例（仅用 failonstatus）
适用于后端稳定、故障多表现为 HTTP 错误码的场景，无需额外模块：
<proxy>
BalancerMember http://192.168.1.10:8080 retry=30 timeout=5 failonstatus=500-599
BalancerMember http://192.168.1.11:8080 retry=30 timeout=5 failonstatus=500-599
ProxySet lbmethod=byrequests
</proxy>
ProxyPass / balancer://myapp/
ProxyPassReverse / balancer://myapp/
这里 retry=30 意味着：任一节点连续返回 503 后，30 秒内不再转发新请求过去；30 秒后首次重试，成功即恢复，失败则重新计时。这个时间要略长于后端典型自愈周期，否则容易陷入“刚恢复又失败”的震荡。
真正容易被忽略的是：状态码摘除没有“预热”或“渐进恢复”机制——它要么 DOWN，要么 UP，中间没有半开状态。如果后端重启后前几个请求仍不稳定，retry 时间一到就立刻涌入流量，可能瞬间打挂。这时候就得靠 mod_proxy_hcheck 的 hcpass（连续成功次数）来缓冲，或者把健康端点本身做得更严谨。
