Nginx可通过proxy_next_upstream等指令实现对502/503/504等错误码的自动重试，需显式配置状态码、限制tries与timeout，并确保upstream至少含2个节点及健康检查。
Nginx 本身不支持对后端返回的特定 HTTP 错误状态码（如 502/503/504）自动重试，但可以通过合理组合 proxy_next_upstream、proxy_next_upstream_tries 和 proxy_next_upstream_timeout 等指令，实现“在满足条件时将请求转发给下一个上游服务器”的效果——这在功能上等价于“自动重试”，是生产环境中最常用且可靠的方案。
启用基于错误码的重试机制
关键在于正确配置 proxy_next_upstream，它定义了在哪些情况下 Nginx 主动放弃当前后端、尝试下一个 upstream server：
- 必须显式列出要触发重试的状态码，例如：
proxy_next_upstream error timeout http_502 http_503 http_504; -
error指连接失败、发送请求失败或接收响应头失败；timeout包含连接超时和代理超时 -
http_500等也可加入，但需确认后端确实会返回该码且重试有意义（避免幂等性问题） - 注意：
http_404、http_403等客户端错误默认不重试，也不建议重试
限制重试次数与时间窗口
防止无限循环或雪崩，必须设置重试边界：
-
proxy_next_upstream_tries 3;：最多尝试 3 台后端（含首次），即最多重试 2 次 -
proxy_next_upstream_timeout 5s;：整个重试过程总耗时不超过 5 秒，超时即返回最终错误 - 这两个值需结合后端平均响应时间和集群规模调整；例如 3 节点集群可设为
tries 3，高延迟场景可适当提高timeout
确保 upstream 配置支持轮询与健康感知
重试逻辑依赖 upstream 的可用节点列表，需保障基础配置健壮：
- 使用默认轮询（
least_conn或ip_hash也支持重试，但策略不同） - 推荐配合被动健康检查：
max_fails=2 fail_timeout=30s;，让 Nginx 自动屏蔽连续失败的节点 - 避免在 upstream 中写死单个 IP；至少配置 2 个后端，否则重试无意义
- 示例片段：
upstream backend { server 10.0.1.10:8080 max_fails=2 fail_timeout=30s; server 10.0.1.11:8080 max_fails=2 fail_timeout=30s; } server { location / { proxy_pass http://backend; proxy_next_upstream error timeout http_502 http_503 http_504; proxy_next_upstream_tries 3; proxy_next_upstream_timeout 5s; } }
注意事项与常见误区
以下情况会导致重试失效或引发问题，务必规避：
-
POST/PUT 等非幂等请求默认不重试：Nginx 默认仅对
GET和HEAD方法重试。如需对其他方法重试，必须加non_idempotent参数（Nginx 1.9.13+），但需业务层确保后端能安全处理重复提交 -
后端返回 5xx 但连接成功、响应头已返回，则不会触发重试：因为
proxy_next_upstream仅在“未收到完整响应头”或连接异常时生效。若后端返回了503响应头+空体，Nginx 会直接返回，不重试 -
不要滥用
proxy_intercept_errors on：它用于自定义错误页，与重试无关；开启后反而可能掩盖真实错误，干扰调试 - 可通过
log_format加入$upstream_addr和$upstream_status，观察实际重试路径
