proxy_next_upstream_timeout 限制重试全过程累计耗时（含首次请求及所有重试环节），不包含客户端超时和单次 proxy_read_timeout；不设会导致用户长时间等待，合理值建议按“单次合理耗时×最大重试次数”估算并留余量，如 proxy_read_timeout 5s、tries 3 时设为 10s。
要限制 Nginx 在后端故障时重试的总耗时，关键不是控制单次请求超时，而是用 proxy_next_upstream_timeout 设定从第一次发起请求开始、到最终放弃重试的完整时间窗口。
它管什么、不管什么
这个指令只约束重试全过程的累计耗时：
- ✅ 包含：首次连接建立、等待响应头、判定失败、选择下一个 upstream、新建连接、再次发请求、再次等待响应……所有环节加起来不能超过设定值
- ❌ 不包含：客户端与 Nginx 之间的超时（由
client_header_timeout等控制） - ❌ 不叠加：后端单次的
proxy_read_timeout仍独立生效，它只是触发重试的条件之一，不会因重试而延长
为什么必须设，不设会怎样
没有总时间限制时，Nginx 可能按顺序逐个尝试所有后端节点，尤其当多个节点都“慢而不死”时，用户等待时间会被严重拉长：
- 比如 upstream 有 4 台机器，
proxy_read_timeout 15s，proxy_next_upstream_tries 4 - 若每台都卡在 14.9 秒才返回 504，用户最长可能等近 60 秒
- 而设为
proxy_next_upstream_timeout 10s，就能在第 10 秒整强制终止，立刻返回 502，避免无意义干等
怎么设才合理
推荐按“单次合理耗时 × 预期最大重试次数”来估算，同时留出余量，但不超过客户端可接受的总等待上限：
- 若
proxy_read_timeout是 5s，且最多允许 3 次尝试（1 次原发 + 2 次重试），建议设为 8–12s，例如10s - 这样即使前两次各耗尽 5s，第三次只剩不到 1s，大概率直接失败，不继续等待
- 若前端整体超时是 30s，这个值就不宜设成 25s，否则留给 Nginx 处理和网络传输的时间太紧
搭配使用的典型组合
生产环境建议采用“短窗口 + 少次数”策略，兼顾容错与可控性：
-
proxy_next_upstream_timeout 6s：覆盖一次 RTT + 两次处理缓冲，足够应对瞬时抖动 -
proxy_next_upstream_tries 3：最多尝试 3 个节点（含首次），防止轮空或打向全部慢节点 -
proxy_read_timeout 5s：让慢响应快速触发重试逻辑 -
proxy_connect_timeout 3s：快速识别完全不可达节点，不浪费总窗口
