proxy_next_upstream_tries设为3表示最多尝试3次（含首次），非额外重试2次；它不防雪崩，但配错必引发雪崩，须与proxy_next_upstream_timeout绑定使用并配合健康检查。
设 proxy_next_upstream_tries 为 3，不是为了“多试几次更稳”，而是给重试划一条不可逾越的红线：最多发 3 次请求（含第一次），超了立刻放弃。它本身不防雪崩，但配错就一定引发雪崩。
tries 是总次数，不是额外重试次数
很多人误以为 tries 3 表示“失败后再重试 3 次”，实际含义是：从第一次转发开始算起，整个请求生命周期内最多尝试 3 次。即：1 次原始目标 + 最多再换节点重试 2 次。
- 设为 0（Nginx 默认值）＝无限重试，生产环境极度危险
- 设为 1＝禁用重试，适合订单提交、支付回调等非幂等操作
- 设为 3＝兼顾容错与安全，覆盖网络抖动、瞬时超时等常见故障
- 设为 ≥5，尤其 upstream 节点少于 3 台时，极易反复打同一台已失联或假死的机器
必须和 timeout 绑定使用，否则形同虚设
proxy_next_upstream_timeout 是从第一次请求发起开始计时的总耗时上限，超时立即终止全部重试并返回错误。只控次数不管时间，等于纵容长尾请求。
- 若单次合理响应耗时约 3 秒，
tries 3时建议timeout设为 8–10 秒（留出余量） - 若
proxy_read_timeout是 5 秒，timeout不宜超过 12 秒，否则第三次尝试可能只剩不到 1 秒，大概率直接失败 - 单独设
tries 5却不设timeout，前两次各耗 6 秒，第三次根本没机会执行
重试不是负载均衡，而是风险放大器
一次重请求（如报表导出、全表扫描）失败后立刻转给另一台机器，等于把压力复制 2–3 倍。尤其在数据库、模型推理等场景，重试会加速集群崩溃。
- GET 请求可重试，但前提是上游真能快速响应；慢接口重试反而拖垮整体
-
POST/PUT/DELETE 默认不重试，这是 HTTP 协议层的安全保护；强行加
non_idempotent必须由业务 100% 保障幂等（如唯一请求 ID + Redis 状态记录） - 发现重试后错误率上升、平均延迟翻倍，说明重试正在恶化问题，应优先调低
tries或关闭特定状态码（如http_502）
必须搭配健康检查，否则重试只是空转
proxy_next_upstream 是被动兜底，health_check 或 max_fails/fail_timeout 才是主动防御。没有后者，Nginx 会不断把请求发给已失联或假死的节点。
- 在
upstream块中启用主动探测：health_check interval=3 fails=2 passes=2; -
check_http_expect_alive只认2xx/3xx，避免把返回 200 的假健康接口当真 - 配合被动策略：
max_fails=2 fail_timeout=30s，让偶发失败也能快速下线节点
