failonstatus是响应码驱动的被动故障隔离机制：当后端返回指定状态码（如500-599）时立即标记失效并进入retry冷却期，需配合retry、timeout和maxattempts才能启用自动重试与摘除。
Apache mod_proxy_balancer 本身不主动探测后端健康状态，但可以通过 failonstatus 参数，在**实际请求返回特定 HTTP 状态码时**，立即把对应后端节点标记为失效，并触发自动摘除——这是最直接、无需额外模块的响应码驱动故障隔离方式。
启用 failonstatus 实现响应码触发摘除
该参数作用于每次代理请求完成后的响应阶段：只要后端返回匹配的状态码，Apache 就将该 BalancerMember 计入失败计数，达到阈值后进入 retry 冷却期，期间不再分发新请求。
-
必须配合
retry：例如retry=30表示节点失败后 30 秒内不参与调度；不设 retry（或设为 0）会导致节点永久下线 -
状态码写法灵活：支持单个值（
failonstatus=502）、逗号分隔（failonstatus=500,502,503）、范围（failonstatus=500-599） - 仅对本次请求生效：它不改变节点长期状态，也不影响健康检查逻辑，属于“被动反馈式剔除”
配置示例与关键细节
在 <Proxy "balancer://mycluster"> 块中为每个后端成员添加参数：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
<Proxy "balancer://mycluster">
BalancerMember http://192.168.1.10:8080 failonstatus=500-599 retry=45 timeout=8
BalancerMember http://192.168.1.11:8080 failonstatus=500-599 retry=45 timeout=8
ProxySet lbmethod=byrequests maxattempts=2
</Proxy>
-
timeout=8控制单次转发最大等待时间，应略小于后端真实超时阈值（如后端设为 10 秒），避免因慢响应被误判为连接失败 -
maxattempts=2是启用重试的前提：首次请求失败后，自动选下一个可用节点再试一次 - 若所有节点都因
failonstatus进入冷却期，Apache 默认返回503 Service Unavailable
为什么单靠 failonstatus 不够？需搭配其他机制
它只捕获“已发出请求并收到明确错误响应”的场景。以下情况无法覆盖：
- 后端进程卡死、TCP 连接保持但无响应 → 需靠
timeout触发连接级失败 - 后端返回 200 但业务逻辑异常（如空 JSON、字段缺失）→
failonstatus无效，需mod_proxy_hcheck+ 自定义ProxyHCExpr - 偶发网络抖动导致单次 503 → 建议设
retry为 30–60 秒，避免过早恢复引发雪崩
验证与调试要点
不要只依赖 /balancer-manager 页面显示的 UP/DOWN 状态——它反映的是最终调度结果，而非触发原因。
- 开启详细日志：
LogLevel proxy:debug或更细粒度的proxy_balancer:info - 在
error.log中搜索关键词：proxy:balancer、failonstatus、retry，确认是否命中规则及何时进入冷却 - 手动模拟故障：用
curl -I http://apache-ip/触发请求，同时观察日志中对应后端是否被标记失败
