nginx 原生不支持对 502/503/504 等状态码单独配置重试，但可通过显式配置 proxy_next_upstream error timeout http_502 http_503 http_504 结合健康检查、proxy_next_upstream_tries 和 proxy_next_upstream_timeout 实现精准容错重试。
在 Nginx 中，原生不支持对特定 HTTP 状态码（如 502、503、504）单独配置重试逻辑，但可以通过 proxy_next_upstream 指令结合后端健康检查与上游分组，实现“仅对某些错误状态码触发重试”的效果。
明确哪些状态码可触发重试
Nginx 的 proxy_next_upstream 允许指定在遇到哪些响应状态时尝试下一个 upstream 服务器。默认只对超时、失败连接等网络层错误重试，不包含 5xx 响应体本身。要启用状态码重试，必须显式声明：
-
error：连接失败、超时、发送/接收失败 -
timeout：代理请求超时 -
invalid_header：后端返回非法响应头 -
http_500、http_502、http_503、http_504：明确匹配对应状态码响应 -
http_404等也可加入，但需确认业务是否真需重试 4xx
例如，只对 502 和 504 重试，不重试 500 或 503：
proxy_next_upstream error timeout http_502 http_504;配合 upstream 分组与健康检查提升可靠性
仅设重试状态码还不够——若所有后端都返回 502，重试只是快速失败。建议搭配以下机制：
- 定义多个后端 server，启用
max_fails和fail_timeout自动摘除异常节点 - 使用
health_check（需 Nginx Plus 或开源版 1.19+ 配合第三方模块）做主动探活 - 设置
proxy_next_upstream_tries限制最大重试次数（默认 0，即无限重试直到有可用 upstream） - 设置
proxy_next_upstream_timeout限制总重试耗时（避免长尾）
示例 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;
keepalive 32;
}
注意重试的副作用与边界条件
重试不是万能解药，需规避常见陷阱：
- 非幂等请求慎用：POST /order 可能被重复提交，除非后端有去重或事务控制
- 客户端超时需协同调整：若 Nginx 重试耗时 2s，而 client 设置了 1s timeout，用户仍会看到超时
-
日志中会记录多次 upstream 访问，但 access_log 默认只记最终响应；如需审计重试过程，开启
log_subrequest on并配合自定义 log_format - 不支持对 3xx 重定向响应重试（Nginx 将其视为成功响应），如需处理跳转失败，需用 rewrite + return 或 Lua 扩展
进阶：用 Lua 实现更精细的状态码判断（OpenResty）
如果需基于响应体内容、Header 字段或动态逻辑决定是否重试（例如只重试含 X-Retryable: true 的 503），标准 Nginx 不支持。此时可引入 OpenResty：
- 用
access_by_lua_block标记请求上下文 - 用
body_filter_by_lua_block捕获响应状态与 body 片段 - 用
header_filter_by_lua_block修改响应或触发内部重定向 - 通过
ngx.exec或ngx.redirect跳转到另一 location 实现“逻辑重试”
这种方式灵活但增加复杂度，建议仅在标准机制无法满足时采用。
