proxy_next_upstream_timeout 限制重试全过程累计耗时，从首次请求开始计时，涵盖连接、等待、失败判定、切换及重发等所有环节；不包含客户端超时，也不叠加单次 proxy_read_timeout；未设置会导致用户长时间等待，合理值建议按“单次合理耗时×最大重试次数”估算并留余量，如 proxy_read_timeout 5s、tries 3 时设为 10s。
proxy_next_upstream_timeout 是控制 Nginx 重试全过程总耗时的关键参数，它不是单次请求超时，而是从第一次发起 upstream 请求开始、到最终放弃所有重试的**累计时间上限**。
它管什么、不管什么
✅ 包含：首次连接建立、等待响应头、判定失败、选择下一个 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 不足以形成有效容错，需同步配置：
• proxy_next_upstream_tries 3：最多尝试 3 个节点（含首次），防止反复打向同一台故障机
• proxy_next_upstream error timeout http_502 http_503 http_504：只对可安全重试的错误类型启用，避免误重试 4xx 或业务 500
• upstream 中启用健康检查：max_fails=2 fail_timeout=30s，让被动失败也能快速下线节点
• 同时确保 proxy_connect_timeout 和 proxy_read_timeout 合理，比如分别设为 2s 和 4s，单次尝试上限约 6s，3 次理论总耗时约 18s，那么 timeout 设为 12–15s 更稳妥
