防止重试引发雪崩的核心是设硬性边界：次数上限（如tries=3含首次）、总耗时限制（proxy_next_upstream_timeout）、节点状态感知（健康检查）三者必须同时生效，且仅对error、timeout等可恢复错误重试。
要防止重试引发雪崩，核心不是把 proxy_next_upstream_tries 设得更大，而是给重试加硬性边界：次数上限、总耗时限制、节点状态感知三者必须同时生效。
明确 tries 是总尝试次数（含首次）
设为 3 表示最多转发 3 次：第 1 次是原始目标，剩下最多还有 2 次重试机会。不是“额外再试 3 次”。
- 设为
1= 禁用重试，适合订单提交、支付回调等非幂等操作 - 设为
0或过高值（如10）极危险，尤其 upstream 节点少于 3 台时，容易反复打向同一台故障机器 - 默认值为
0（不限制），生产环境必须显式覆盖
必须搭配 proxy\_next\_upstream\_timeout 控制总耗时
proxy_next_upstream_timeout 是从第一次请求发起开始计时的总窗口，超时即刻终止所有重试并返回错误。
- 若单次合理响应耗时约 3 秒，
tries 3时建议设timeout 10s（留出余量） - 若
proxy_read_timeout是 5 秒，timeout不宜超过 12 秒，否则第三次尝试可能只剩不到 1 秒，大概率直接失败 - 单独设
tries 5但timeout 30s，前两次各耗 15 秒，第三次根本没机会执行
重试前先剔除坏节点：健康检查不能缺位
没有健康检查，tries 再小也白搭——Nginx 会不断把请求发给已失联或假死的节点。
- 在 upstream 块中启用主动探测：
health_check interval=3 fails=2 passes=2; - 确保
check_http_expect_alive只认2xx/3xx，避免把 503 当存活 -
max_fails=3 fail_timeout=30s配合使用，让被动失败也能快速下线节点
触发条件要精简，避免误重试
重试不是万能兜底，加错状态码反而放大问题。
- 最小安全集：
proxy_next_upstream error timeout;（只对连接失败、超时重试） - 确认上游幂等且稳定后，可谨慎加
http_502 http_503 http_504 - 绝对不要加
http_404、http_403、http_500—— 它们多属业务错误，重试无意义，还可能重复扣款或生成重复订单 - POST/PUT/DELETE 默认不重试，强行加
non_idempotent必须 100% 确保后端幂等
