proxy_next_upstream_tries 表示最多尝试转发请求的总次数（含首次），设为3即首次+最多再试2次；必须配合proxy_next_upstream使用，且仅在upstream多节点、启用错误触发条件时生效。
proxy_next_upstream_tries 是 Nginx 中用于控制当上游服务器（后端）响应失败时，Nginx 最多尝试多少次转发请求到其他可用 upstream 服务器的关键指令。它必须配合 proxy_next_upstream 使用，否则无效。
作用与生效前提
该指令仅在以下条件下起作用：
- 当前请求已启用 proxy_pass 指向一个 upstream 块；
- 设置了 proxy_next_upstream，明确指定哪些错误会触发重试（例如
error timeout http_500）； - upstream 中定义了多个服务器，且至少有一台处于可选状态（未被标记为
down或因健康检查失效而暂时剔除）。
基本配置写法
在 location 或 server 块中设置：
location /api/ {
proxy_pass http://backend;
proxy_next_upstream error timeout http_500;
proxy_next_upstream_tries 3;
}
上面配置表示：若首次请求遇到 error（连接失败）、timeout（超时）或返回 500，Nginx 将最多再尝试 2 次（即总共最多 3 次请求），每次换一台 upstream 服务器。注意：tries = 3 表示总尝试次数上限，不是额外重试次数。
常见误区与注意事项
-
不包含初始请求：
proxy_next_upstream_tries 1表示只发一次请求，不重试；设为 2 才表示“失败后最多再试 1 次”； - 不解决单点故障：它只切换服务器，不修复后端问题。若所有 upstream 都不可用，最终仍返回 502/504；
-
与超时联动更有效：建议同时设置
proxy_connect_timeout、proxy_send_timeout、proxy_read_timeout，避免某台慢节点拖垮整体重试效率； -
和健康检查配合使用效果更好：启用
health_check（NGINX Plus）或check（Tengine），能更快剔除异常节点，减少无效重试。
调试与验证方法
可通过开启 Nginx 错误日志（error_log /path/to/error.log debug;）观察重试行为：
- 查找类似
upstream timed out、no live upstreams的日志； - 确认是否出现
next upstream字样，以及重试次数是否符合预期； - 用
curl -v配合后端模拟故障（如 iptables 拦截某台机器端口），观察客户端是否收到响应或明确错误。
