mod_proxy_balancer不支持请求级自动重试，需组合配置实现快速故障切换：设timeout=3和connectiontimeout=1.5控制超时，ping=5主动健康检查，retry=15控制隔离时长，并配合keepalive、max连接数及lbmethod提升效率。

apache 的 mod_proxy_balancer 本身不提供“连接超时后立即重试另一节点”这种自动重发机制，它的重试（retry）是故障隔离策略，不是请求级重试。真正实现“快速失败 + 快速切换节点”，靠的是组合配置：缩短连接与响应等待时间、启用健康探测、合理设置故障冷却窗口。

用 ProxySet 控制单节点连接与首包超时

在 <proxy></proxy> 块中为每个 BalancerMember 设置细粒度超时，这是感知后端异常的第一道防线：

• timeout=3：从 Apache 尝试建连开始，到收到响应头第一个字节为止，最多等 3 秒。超时即放弃该节点，进入下一个可用成员（若存在）
• connectiontimeout=1.5：TCP 连接建立阶段单独限制（如 SYN 超时），建议比 timeout 小至少 1 秒，避免刚握手完成就被中断
• 这两个值共同决定“多快能发现节点不可达”，比全局 ProxyTimeout 更精准

用 ping 实现主动健康探测，提前剔除问题节点

仅靠请求失败触发 retry 是被动的；加 ping 可主动轮询，让节点在真正收请求前就被标记为不可用：

CPA Update - Secure CLI Proxy API Maintenance

安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。

下载

• ping=5,HEAD,/health：每 5 秒对 /health 发一次 HEAD 请求，5 秒无响应则标记为 ERR
• 要求 Apache ≥ 2.4.33，且已启用 mod_proxy_balancer 和对应协议模块（如 mod_proxy_http）
• 后端 /health 端点必须轻量、快速返回（建议 ≤ 200ms），否则探测本身会拖慢调度

用 retry 控制故障节点恢复节奏

retry 不是“重试次数”，而是“该节点被隔离的时间（秒）”。设小一点，能让流量更快回流或转向其他节点：

• retry=15：节点一旦失败（建连失败、ping 失败、响应超时等），15 秒内不会被选中
• 搭配 timeout=3 和 ping=5，实际故障发现+切换可在 5 秒内完成（ping 探测失败 → 标记 ERR → 下个请求直接跳过）
• 避免设为 0（无效）或过小（如 1 秒），可能造成抖动；也不宜过大（如 >60），影响恢复速度

配合负载策略和连接复用提升响应效率

光靠超时和重试不够，还需减少建连开销、避免线程卡死：

• 启用长连接：ProxySet keepalive=on，复用 TCP 连接，降低建连延迟
• 限制并发连接数：ProxySet max=10，防止单节点连接数暴涨压垮后端
• 选用合适算法：lbmethod=bybusyness 比 byrequests 更适合 Java 类应用（响应时间差异大），能自然避开繁忙节点
• 全局兜底：ProxyTimeout 15 作为完整响应生命周期上限，与 timeout=3 形成两级控制