Nginx故障转移关键在于“更准、更快、更可控”：需配置proxy_next_upstream含error/timeout/502-504，设tries≤3与timeout≤6s，配合max_fails/fail_timeout实现节点健康隔离，并严格限制非幂等请求重试。
Nginx 实现故障快速转移，关键不是让重试“更多”，而是让重试“更准、更快、更可控”。proxy_next_upstream 是核心开关，但单独启用它几乎没用——必须配合错误类型筛选、耗时约束、健康状态联动和请求幂等性判断，才能把一次后端失败变成用户无感的秒级切换。
明确哪些失败才值得换节点重试
Nginx 默认只对 error（连接拒绝、断连）和 timeout（建连或读响应头超时）触发重试，而生产中最常见的故障信号其实是后端返回的 502/503/504。这些状态码代表网关异常、服务熔断或上游超时，恰恰适合重试。
必须显式配置：
-
proxy_next_upstream error timeout http_502 http_503 http_504 - 可选加
invalid_header：防后端崩溃后返回空响应或非法头（如缺失Status:行） -
禁用
http_404、http_403、http_500：它们多属业务逻辑问题，重试不改变结果，还可能引发重复扣款、重复下单等风险
用 tries + timeout 锁死重试窗口，避免长尾拖垮体验
没有边界的重试等于放大延迟。比如 4 台后端各慢 14 秒，用户可能卡满 56 秒才看到错误。要实现“快速”转移，就得从时间维度硬性截断：
-
proxy_next_upstream_tries 3：最多尝试 3 个节点（含首次），即最多重试 2 次 -
proxy_next_upstream_timeout 6s：从第一次请求发出开始计时，所有重试累计不能超 6 秒 - 这两个参数必须成对出现，且
timeout值应略大于单次proxy_read_timeout（例如设为5s），否则首次请求就可能被截断，重试根本不会触发
让“失败感知”前置：靠 max_fails/fail_timeout 避免反复撞墙
proxy_next_upstream 解决的是“这次失败怎么办”，而 max_fails 和 fail_timeout 解决的是“下次还打不打它”。没有后者，Nginx 仍会把新请求轮询到已宕机但尚未标记的节点，导致每次都要先失败再重试。
在 upstream 中为每个 server 显式设置：
-
max_fails=2 fail_timeout=15s：连续 2 次失败（包括重试触发的502/504）后，该节点 15 秒内不再参与调度 - backup 节点也建议配相同参数，防止备用节点自己也出问题
区分请求方法，非幂等操作零重试是底线
重试本质是重复发送请求。对 GET/HEAD 安全；但 POST /login、PUT /order/status、DELETE /token 等操作一旦重试，极易造成业务异常。
Nginx 默认只对 GET/HEAD 启用重试，这是安全机制。若业务明确允许某些 POST 幂等（如带唯一 idempotency-key 的接口），可配合 proxy_buffering off 和 proxy_cache_bypass $sent_http_content_type 控制缓存行为，但需严格验证。
不复杂但容易忽略
