Apache mod_proxy通过mod_proxy_balancer配合lbmethod=byrequests、maxattempts≥2、nofailover=Off及timeout/retry/failonstatus等参数可实现请求级自动重试；需启用mod_proxy_balancer模块，后端支持HTTP/1.1 keep-alive，并验证X-Balancer-Worker响应头或后端日志确认重试生效。
Apache 的 mod_proxy 本身不主动重试失败请求，但配合 mod_proxy_balancer 和合理参数组合，可实现请求级自动重试补偿——即当某后端节点在本次请求中失败（连接拒绝、超时、返回特定错误码），Apache 自动换一个可用节点重发该请求，而非直接报错。
关键不在“重试多少次”，而在于让重试逻辑真正触发并生效。以下是必须配置的要点：
启用支持重试的负载均衡算法
mod_proxy_balancer 必须使用能轮询多个 worker 的调度方法，且显式开启重试尝试次数：
-
lbmethod=byrequests或lbmethod=bytraffic（推荐byrequests，行为更确定） -
maxattempts=2（或更高，如3）：表示单个请求最多尝试几个后端节点，默认为1（即不重试） -
nofailover=Off：确保故障时允许切换节点（默认就是Off，但建议显式写出）
⚠️ 注意：
bybusyness在新版 Apache 中已标记为废弃，不推荐用于新部署。
aperture: the L402 aware reverse proxy下载安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
设置每个后端节点的失效判定与恢复节奏
单靠 maxattempts 不够，还需让节点“可被跳过”且“能及时回归”：
-
timeout=5：单次请求等待上限，超时即视为失败，触发重试 -
retry=15：该节点失败后，15 秒内不再分配新请求（冷却期，非探测间隔） -
failonstatus=500-599：收到 5xx 响应也标记为本次失败，参与maxattempts计数 - （可选）
ping=5：Apache 2.4.33+ 支持，每 5 秒对后端发 HEAD 探测，失败则本次请求跳过该节点（不消耗maxattempts，但提升前置规避率）
示例配置片段：
<Proxy "balancer://api">
BalancerMember http://192.168.1.10:8000 timeout=5 retry=15 failonstatus=500-599
BalancerMember http://192.168.1.11:8000 timeout=5 retry=15 failonstatus=500-599
ProxySet lbmethod=byrequests maxattempts=2 nofailover=Off
</Proxy>
ProxyPass "/api/" "balancer://api/"
ProxyPassReverse "/api/" "balancer://api/"确保底层模块和协议兼容
- 必须启用
mod_proxy_balancer（仅mod_proxy和mod_proxy_http不够） - 后端需支持 HTTP/1.1 及
Connection: keep-alive，否则每次重试都新建 TCP 连接，开销大且易触发连接数限制 - 若后端是 PHP-FPM、Tomcat 等长连接服务，建议额外配置
ProxySet min=2 max=20 acquire=3000控制连接池，避免重试时排队阻塞
验证是否真重试成功
不要只看日志里有没有 proxy: error —— 那只是第一次失败。真正生效的表现是：
- 客户端收到 200 响应，且响应头中
X-Balancer-Worker（若启用）显示不同 route - 后端日志中，同一请求 ID（如
X-Request-ID）出现在两个不同节点上 -
balancer-manager页面中，各节点的 “Elected” 数差异不大，说明流量被重新分发
不复杂但容易忽略。
