nginx的proxy_next_upstream默认不重试任何http状态码，需显式配置http_502/http_503/http_504等及error/timeout/invalid_header；须配合proxy_next_upstream_tries、timeout和至少两台主节点upstream使用。

在 Nginx 中，proxy_next_upstream 默认不会对任何 HTTP 状态码（包括 502、503、504）自动重试，必须显式列出具体状态码才能触发切换。它不是“遇到非 200 就切”，而是只响应你明确允许的错误类型。

必须显式声明要重试的状态码

Nginx 使用内部标识符表示状态码，不能写 502 或 http/502，正确写法是：

• http_502 —— 后端作为网关/代理时上游不可达或返回无效响应
• http_503 —— 后端主动返回服务不可用（如过载保护）
• http_504 —— 后端网关超时（常见于上游响应慢）
• http_500 可加，但需确认是瞬时故障而非业务逻辑错误
• http_429 可用于限流场景下的重试（如多实例分摊请求）

不建议加入 http_404、http_403：它们属于客户端语义错误，重试不会改变结果，还可能引发副作用（如重复日志、误计费）。

搭配基础错误类型才完整覆盖故障场景

仅配状态码不够，网络层和协议层失败也要涵盖：

aperture: the L402 aware reverse proxy

安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。

下载

• error：建连失败、连接被拒、TCP reset、DNS 解析失败等
• timeout：含 proxy_connect_timeout、proxy_read_timeout 触发的超时
• invalid_header：后端返回空响应、缺失 Status 行、头字段格式非法等

典型组合：proxy_next_upstream error timeout invalid_header http_502 http_503 http_504;

必须限制重试边界，防止雪崩

没有约束的重试会放大延迟甚至拖垮整个集群：

• proxy_next_upstream_tries 3;：最多尝试 3 个不同 upstream server（含首次），不是“重试 3 次”。若 upstream 只有 2 台主节点，设为 3 是合理上限
• proxy_next_upstream_timeout 10s;：从第一次请求发出起计时，总耗时超 10 秒即终止并返回最终错误。该值应 ≥ 单次 proxy_read_timeout（如后者为 5s，则此处至少设 5s）

上游配置要支持切换，否则重试无效

确保 upstream 块中至少有 2 台可用主节点，并启用被动健康检查：

• 每台 server 加 max_fails=3 fail_timeout=30s：连续 3 次失败后，该节点被临时剔除 30 秒
• 避免误标 backup 或 down：只有真正需要灾备兜底的节点才用 backup
• 不推荐只配 1 台主节点 + 1 台 backup：backup 不参与常规轮询，无法被 proxy_next_upstream 选中作为“下一节点”

示例 upstream：

upstream backend {
  server 10.0.1.10:8080 max_fails=3 fail_timeout=30s;
  server 10.0.1.11:8080 max_fails=3 fail_timeout=30s;
  server 10.0.1.12:8080 backup;
}