Nginx默认不因502重试，因其视完整HTTP响应为通信完成；需显式配置proxy_next_upstream error timeout http_502，并确保upstream含多节点且配置位于location块内。
默认情况下，Nginx 遇到后端返回 502 Bad Gateway 并不会自动切换节点重试——它只把 502 当作一个合法的 HTTP 响应原样返回给客户端。要让它在收到 502 时尝试下一个 upstream server，必须显式启用并精准配置 proxy_next_upstream。
为什么 502 默认不触发重试？
Nginx 的设计逻辑是：只要成功建立了 TCP 连接、收到了完整的 HTTP 响应（哪怕状态码是 502），就认为“通信完成”，不再视为可重试的失败。而 proxy_next_upstream 默认仅响应两类底层异常：
- error：连接被拒、连接重置、DNS 失败等网络级错误
- timeout：建连超时、发送请求超时、读取响应头超时
502 属于应用层响应，不在默认列表中，所以必须手动加上 http_502 才能激活重试行为。
基础配置：让 502 触发切换
关键配置需放在 location 或 server 块中（不能只写在 http 顶层），且依赖 upstream 定义：
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
- 定义至少两个后端节点：
upstream backend { server 10.0.1.10:8080; server 10.0.1.11:8080; } - 在 location 中启用重试：
proxy_next_upstream error timeout http_502; - 确保
proxy_pass指向该 upstream：proxy_pass http://backend;
这样当第一个节点返回 502，Nginx 就会立即发起第二次请求，打到第二个节点。
避免重试失效的常见坑
即使写了 http_502，仍可能不切换，原因通常有：
- upstream 里只有一个 server → 没有“下一个”可切，重试无意义
- 配置写在
http块但没被具体 location 继承（Nginx 不自动继承该指令） - 后端虽返回 502，但已开始传输响应体 → Nginx 认为响应已发出，拒绝重试（此时需靠
invalid_header或更早的 timeout 拦截） - 未配
proxy_read_timeout，导致慢响应未被识别为 timeout，错过重试时机
推荐增强配置（生产可用）
单加 http_502 不够稳健，建议组合以下参数：
-
proxy_next_upstream error timeout http_502 http_503 http_504;—— 覆盖常见网关类瞬时故障 -
proxy_next_upstream_tries 3;—— 最多尝试 3 次（首次 + 2 次重试） -
proxy_next_upstream_timeout 10s;—— 整个重试过程总耗时不超 10 秒 -
proxy_read_timeout 5s;—— 让卡在响应头阶段的“假死”节点更快暴露为 timeout
配合 upstream 中的 max_fails=2 fail_timeout=30s，还能实现被动健康检查，让连续出错的节点暂时剔除。
