proxy_next_upstream_tries 3 表示首次转发加最多2次重试，共最多3次请求；必须配合timeout、健康检查和错误类型筛选，否则易引发雪崩。
直接设 proxy_next_upstream_tries 3 不够，必须配合超时控制、健康检查和错误类型筛选，否则重试反而会把压力复制几遍，加速雪崩。
明确 tries 是总次数，不是额外重试次数
设为 3 表示：首次转发 + 最多再试 2 次，总共最多打 3 个节点（或同一节点多次，若它没被踢出）。默认值是 0（不限次），生产环境绝不能留这个默认。
- 设为 1 → 禁用重试，适合订单提交、支付回调等非幂等操作
- 设为 3 → 覆盖常见瞬时故障，又不显著放大负载
- 避免设为 0 或 ≥5，尤其 upstream 节点少于 3 台时，极易反复打同一台坏机器
必须绑定 proxy\_next\_upstream\_timeout 控制总耗时
只控次数不管时间，等于给慢节点开了绿灯。timeout 是从第一次请求发出开始计时的总窗口，超时就立刻终止并返回错误。
- 若单次合理响应在 3–4 秒内，建议 timeout 设为 8–10 秒
- 典型组合：
proxy_next_upstream_tries 3; proxy_next_upstream_timeout 10s; - 单独设 tries=3 但 timeout=30s，前两次各卡 12 秒，第三次根本来不及执行；反之 timeout=2s 但 tries=3，可能刚发第一次就超时退出
只对真正可重试的错误开启重试
不是所有失败都该重试。500/502/503/504 和 timeout/error 可考虑，但 4xx 错误（如 404、403）代表客户端问题，重发无意义。
- 推荐写法：
proxy_next_upstream error timeout http_502 http_503 http_504; - 慎加
http_500—— 如果后端因业务异常返回 500，重试大概率还错 - 禁用
non_idempotent，除非你 100% 确认 POST/PUT 接口幂等（比如带唯一请求 ID + 服务端去重）
必须搭配主动健康检查，否则重试就是空转
proxy_next_upstream 是“出事才换人”，健康检查才是“提前把病人抬走”。没有后者，重试大概率还在往宕机节点上撞。
- upstream 块中加：
health_check interval=3 fails=2 passes=2; - 确保检查路径返回 2xx/3xx 才算存活，避免用 /health 返回 200 却实际不可用
- fail_timeout 别设太长（如 60s），否则节点挂了还要继续参与重试十几秒
重试不是负载均衡，而是风险放大器。配得对，能扛住单点抖动；配错了，一次超时就能拖垮整个集群。
