proxy_next_upstream_tries 是单次请求最多转发总次数，非额外重试数；设为0即无限重试极危险，设为1禁用重试，设为3最常用；须配合timeout控制总耗时，并依赖健康检查提前剔除故障节点，且仅对幂等请求（如GET）启用重试。
proxy_next_upstream_tries 本身不防雪崩，但配错一定会引发雪崩。它是一道硬性闸门：控制单次请求最多发几次转发（含首次），而不是“失败后再试几次”。设为 3，就是最多打 3 次——第 1 次原目标，后面最多再换 2 个节点各试一次。关键不在“多试”，而在“及时停手”。
明确 tries 是总次数，不是额外重试数
很多人误以为 tries 3 = “失败后重试 3 次”，实际是整个请求生命周期内最多尝试 3 次转发。这个数字直接决定压力是否被放大：
- 设为 0（Nginx 默认）= 无限重试，生产环境极度危险
- 设为 1 = 禁用重试，适合订单提交、支付回调等非幂等操作
- 设为 3 = 最常用安全值，覆盖瞬时抖动，又不显著放大负载
- 设为 ≥5，尤其 upstream 节点少于 3 台时，大概率反复打同一台故障机
必须绑定 proxy_next_upstream_timeout 控制总耗时
只控次数不管时间，等于给慢节点开绿灯。timeout 是从第一次请求发出开始计时的总窗口，超时即刻终止所有后续尝试并返回错误：
- 若单次合理响应在 2–4 秒，建议 timeout 设为 6–10 秒（如 proxy_next_upstream_timeout 8s）
- 若 proxy_read_timeout 是 5 秒，timeout 不宜超过 12 秒，否则第三次尝试可能只剩不到 1 秒
- tries=3 但 timeout=30s → 前两次各卡 12 秒，第三次根本没机会执行
- timeout=2s 但 tries=3 → 首次请求刚发就超时退出，重试形同虚设
重试前先剔除坏节点：健康检查不能缺位
proxy_next_upstream 是“出事才换人”，健康检查才是“提前把病人抬走”。没有后者，重试只是空转：
- 启用主动健康检查：health_check interval=3 fails=2 passes=2
- 搭配被动摘除：max_fails=2 fail_timeout=30s
- 避免 health_check 间隔 >10s 或 fails ≥5，否则宕机节点会长期滞留
- 不配健康检查时，哪怕 tries=1，流量仍会优先打向已不可用的节点
按请求语义决定是否允许重试
重试本质是风险放大器。高并发下一次失败后立刻转给另一台机器，等于把压力复制 2–3 倍：
- GET 类查询可谨慎开启：proxy_next_upstream error timeout http_502 http_503 http_504
- POST/PUT/DELETE 默认不重试；强行加 non_idempotent 必须由业务层 100% 保障幂等（如带唯一请求 ID + 服务端去重）
- 绝对不要加 http_404、http_403、http_500 —— 它们多属业务错误，重试无意义，还可能重复扣款或生成重复订单
