proxy_next_upstream_tries 的核心作用是限制单次请求的总转发次数（含首次），设为3表示最多尝试3次，非额外重试3次；必须与proxy_next_upstream_timeout配合使用，单独配置易导致超时卡顿或无效重试，典型组合为tries 3; timeout 6s。
proxy_next_upstream_tries 的核心作用，是给重试机制加一道“硬闸”——它不解决上游为什么慢，而是确保一次请求不会无休止地在多个后端间反复转发。
tries 是总次数，含首次请求
设为 3，意思是：Nginx 最多发起 3 次转发尝试，其中第 1 次是原始目标，剩下最多还有 2 次重试机会。不是“额外重试 3 次”。这个数字必须和 timeout 配合使用，否则只控次数不控时间，仍可能卡住。
- 单独设 tries 为 5，但 timeout 是 30 秒，若前两次都耗掉 15 秒，第三次根本没机会执行
- 单独设 timeout 为 3 秒，但 tries 是 1，等于禁用重试（首次失败就返回）
- 典型组合：proxy_next_upstream_tries 3; proxy_next_upstream_timeout 6s; —— 3 次尝试总耗时不能超 6 秒
重试不是负载均衡，而是风险放大器
很多人误以为开启重试能让流量更“均匀”，实际恰恰相反：当某个请求本身就很重（比如查全表、导大报表），一次超时后立刻转给另一台机器，等于把压力复制了 2–3 倍。数据库类场景最容易因此雪崩。
- GET 请求可重试，但不等于“应该重试”——要先确认该接口是否真能快速响应
- POST/PUT/DELETE 默认不重试，这是保护机制；强行加
non_idempotent必须确认上游 100% 幂等 - 如果发现重试后错误率上升、平均延迟翻倍，说明重试正在恶化问题，应优先调低 tries 或关闭特定状态码重试
和健康检查搭配，才能真正防雪崩
proxy_next_upstream 是“出事后再补救”，属于被动兜底；而 upstream 内的健康检查（health_check）是主动剔除病节点。两者缺一不可。
- 只靠重试：一台机器已宕机但尚未被踢出 upstream，所有请求都先打过去再超时重试，白白浪费资源
- 只靠健康检查：偶发网络抖动或单次超时无法及时感知，用户直接看到错误
- 推荐配置：
health_check interval=3 fails=2 passes=2;+proxy_next_upstream error timeout http_502 http_503 http_504;
非幂等请求重试，后果往往比失败更严重
Nginx 默认对 POST 等方法不触发重试，是因为 HTTP 协议语义上它们不可重复执行。绕过限制（如加 non_idempotent）等于手动拆掉安全阀。
- 订单提交接口返回 502，重试一次 → 用户收到两个订单号、扣两笔款
- 支付回调返回 504，重试两次 → 支付平台收到三次通知，可能重复发货
- 除非上游明确承诺“多次接收同一请求 = 一次处理”，否则不要开 non_idempotent
