Apache的mod_proxy默认不重试失败请求，因其设计定位为轻量代理，仅执行一次转发并将错误原样透传给客户端；所谓“重试效果”实为mod_proxy_balancer通过failonstatus标记故障节点、retry控制恢复时间实现的请求路由切换，而非对同一请求的重复发送。
Apache 的 mod_proxy 本身不提供「重试」或「补偿」语义，它只做一次转发；所谓“自动重试”必须靠被动故障检测 + 后端节点状态切换来模拟，且无法实现业务级补偿（如幂等回滚、事务对账）。
为什么 ProxyPass 默认不重试失败请求
mod_proxy 对每个请求只发起一次后端连接。即使后端返回 502/503/504 或连接超时，Apache 不会自动重发该请求到其他节点——它只是把错误原样透传给客户端。
- 这是设计使然：HTTP 是无状态协议，重试需由客户端或上层网关决策，Apache 定位为轻量代理，不介入业务语义
- 你看到的“重试效果”，往往来自
mod_proxy_balancer的被动健康检查机制：某个节点连续失败后被标记为down，后续请求自然落到其他节点，但这不是对同一请求的重试，而是路由切换 - 没有配置项叫
retry=3或failover-on-5xx，所有相关文档里都不存在这类指令
用 failonstatus + retry 实现有限的“故障转移式重试”
虽然不能重试单个请求，但可通过让 Apache 主动避开已知异常节点，间接提升请求成功率。关键参数是 failonstatus 和 retry：
-
failonstatus=502,503,504：当后端返回这些状态码时，Apache 将该节点临时标记为down（非永久），持续时间由retry=60（秒）控制 - 必须配合
mod_proxy_balancer使用，且至少定义两个BalancerMember - 示例配置片段：
<Proxy "balancer://api">
BalancerMember http://192.168.1.10:8000 failonstatus=502,503,504 retry=30
BalancerMember http://192.168.1.11:8000 failonstatus=502,503,504 retry=30
ProxySet lbmethod=bybusyness
</Proxy>
ProxyPass "/api/" "balancer://api/"
ProxyPassReverse "/api/" "balancer://api/"
注意：retry=30 不代表每 30 秒重试一次，而是指该节点被标记为 down 后，30 秒内不再接收新请求；30 秒后自动恢复参与负载均衡。
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
真正需要重试或补偿？别在 Apache 层硬扛
如果你的业务要求「一个 POST 请求失败后，自动用相同 payload 重试 2 次，且第三次失败时调用补偿接口」，mod_proxy 做不到。原因很实在：
- 它不解析请求 body，无法复制原始 payload（尤其含二进制或签名字段时）
- 它不维护上下文，无法记录哪次失败、是否已补偿、是否幂等
- 它没有钩子执行自定义逻辑（比如调用 webhook 或写 DB 日志）
- 所有重试行为都发生在网络/协议层，而非应用层
可行路径只有两条：要么把重试逻辑下沉到后端服务内部（例如 Spring Retry + Resilience4j），要么上移到专用 API 网关（Kong、Traefik、Envoy），它们支持 Lua/JS 脚本、重试策略、熔断和补偿回调。
容易被忽略的细节：timeout 和 keepalive 影响“重试感知”
很多用户以为加了 failonstatus 就万事大吉，结果发现节点明明挂了，请求还是持续打过去——问题常出在超时设置上：
-
timeout=5（单位秒）太短，导致健康检查还没完成，连接就超时断开，反而频繁触发failonstatus误判 -
keepalive=On可减少 TCP 握手开销，但若后端不支持长连接，会加剧连接池耗尽，引发连锁超时 - 建议组合使用：
timeout=30 keepalive=On smax=10 max=100 acquire=5000（smax控制空闲连接上限，acquire是获取连接超时毫秒数）
真正的重试边界不在 Apache，而在你能否清晰界定：这个失败是暂时的（可重试），还是永久的（需告警+人工介入）。把判断权交给 Apache，等于放弃对失败语义的控制。
