设 proxy_next_upstream_tries 为3（含首次请求，最多重试2次）、proxy_next_upstream_timeout 为6s，并启用 upstream 健康检查，是防止后端雪崩最务实的三板斧；tries 非额外重试次数，0=无限重试极危险，1=禁用重试，3=兼顾容错与安全，须与 timeout 绑定使用，否则无效。
直接说结论：设 proxy_next_upstream_tries 3，再配 proxy_next_upstream_timeout 6s，并确保 upstream 启用了健康检查——这是防止连环雪崩最务实的三板斧。
tries 是总次数，不是额外重试次数
很多人误以为 tries 3 表示“失败后再重试 3 次”，实际是：从第一次转发开始算起，最多只发 3 次请求。即 1 次原目标 + 最多 2 次换节点重试。
- 设为 0（默认）＝无限重试，生产环境极其危险
- 设为 1 ＝禁用重试，适合订单、支付等强一致性写操作
- 设为 3 ＝兼顾容错与安全，覆盖瞬时故障又不放大压力
- 设为 10 或更高 ＝在节点少于 3 台时，极易反复打同一台坏机器
必须和 timeout 绑定使用，否则形同虚设
proxy_next_upstream_timeout 是整个重试过程的总耗时上限，从第一次发起请求开始计时，超时就立刻失败返回，不等第三次。
- 若单次合理响应时间约 2s，设
timeout 6s刚好支持 3 次尝试（2+2+2） - 若
read_timeout是 5s，timeout建议设 8–12s，留出缓冲但不纵容长尾 - 单独设
tries 5却不设timeout，前两次各耗 4s，第三次可能卡到客户端超时才结束
重试不是负载均衡，而是风险放大器
尤其在数据库、报表导出、模型推理等重请求场景，一次失败后立刻转给另一台机器，等于把压力复制 2–3 倍。
- GET 请求可重试，但要确认上游是否真能快速响应；慢接口重试反而拖垮集群
- POST/PUT/DELETE 默认不重试，强行加
non_idempotent必须由业务层 100% 保障幂等 - 发现重试后错误率上升、平均延迟翻倍，说明重试正在恶化问题，应立即调低 tries 或关闭特定状态码（如 http_502）
必须搭配健康检查，才能闭环防雪崩
proxy_next_upstream 是被动兜底，health_check 或 max_fails/fail_timeout 才是主动防御。
- 没配健康检查时，坏节点长期留在 upstream，每次请求都先打过去再超时重试，白白浪费资源
- 推荐组合：
max_fails=2 fail_timeout=30s+proxy_next_upstream error timeout http_502 http_503 http_504 - 更稳妥可加 backup 节点，或接入 OpenResty 实现共享字典熔断计数
