proxy_next_upstream_timeout仅限制单次upstream请求超时（如3s），不控制重试总耗时；总耗时需通过proxy_next_upstream_tries、proxy_connect_timeout与proxy_read_timeout组合控制，理论上限为tries×(connect+read)。
proxy_next_upstream_timeout 并不控制整个重试链条的总耗时，它只限制单次 upstream 请求（含连接、发送、接收）的超时时间。真正用于限制“从首次请求开始到所有重试结束”的总时间的是 proxy_timeout（即 proxy_read_timeout 和 proxy_connect_timeout 的协同作用），而更精确、推荐的方式是使用 proxy_next_upstream_timeout 配合 proxy_next_upstream_tries 与 proxy_timeout 的组合策略。
理解 proxy_next_upstream_timeout 的实际作用
该指令定义的是：每次向某个 upstream server 发起请求（包括重试中的一次）时，Nginx 等待响应的最长时间。它不累加，也不跨重试计时。例如设为 3s，那么每次尝试最多等 3 秒，无论这是第 1 次还是第 3 次重试。
- 若某次请求在 2.8 秒收到错误响应（如 502），Nginx 可能立即发起下一次重试（取决于
proxy_next_upstream条件） - 若某次请求卡在后端 3.1 秒才返回，本次尝试失败，Nginx 才会按需重试（前提是未超
proxy_next_upstream_tries） - 它无法防止“3 次重试 × 各等 3 秒 = 最多 9 秒”的总延迟
用 proxy_next_upstream_tries + proxy_timeout 控制总耗时上限
要逼近“整个重试链最大执行时间”，需组合以下三个参数：
-
proxy_next_upstream_tries：限制最多重试几次（含初始请求）。例如设为
3，表示最多尝试 3 台服务器（或同一台重试 3 次，取决于负载均衡配置） - proxy_connect_timeout：建立 TCP 连接的超时，建议 ≤ 总体目标时间的 1/3（如总控 6s，则设为 2s）
-
proxy_read_timeout：等待后端响应体第一个字节的时间，应覆盖单次业务处理合理耗时（如 4s），且需满足：
proxy_connect_timeout + proxy_read_timeout≤ 单次尝试上限，再乘以 tries 数可估算理论最大耗时
例如：设 proxy_next_upstream_tries 3，proxy_connect_timeout 1s，proxy_read_timeout 3s，则单次尝试最长 4s，理论总耗时上限 ≈ 3 × 4s = 12s（实际因串行+网络抖动略高，但可作为软上限）。
更可靠的做法：用 proxy_timeout（OpenResty / Nginx Plus）或 Lua 控制全局超时
标准 Nginx 开源版无原生“重试链总超时”指令，但可通过以下方式增强控制：
- 升级至 Nginx Plus，使用
proxy_timeout指令（支持对整个 upstream transaction 设总超时） - 使用 OpenResty，在
access_by_lua_block中记录起始时间，结合ngx.timer.at或重试逻辑手动判断是否超总时长 - 在 upstream 块中配置
keepalive和合理的max_fails/fail_timeout，避免反复试探已不可用节点，间接压缩无效重试耗时
调试与验证建议
启用日志定位真实耗时分布：
- 开启
error_log ... debug;（慎用于生产），搜索"upstream timed out"或"no live upstreams" - 在
log_format中加入$upstream_connect_time、$upstream_header_time、$upstream_response_time，分析各次尝试分段耗时 - 用
curl -v或ab模拟慢后端，验证重试次数和总延时是否符合预期
