proxy_next_upstream_tries 3 配合 timeout 8s 和主动健康检查，是防止雪崩的核心三要素：它限定单次请求最多转发3次（含首次）、总耗时≤8秒、且仅路由至健康节点。
设 proxy_next_upstream_tries 3，配合 proxy_next_upstream_timeout 8s 和 主动健康检查，是防止集群滚雪球瘫痪最有效的三要素。它不是让系统“更努力地重试”，而是给每次请求划一条硬性红线：最多发 3 次（含首次），总耗时不超过 8 秒，且只打健康节点。
tries 是总次数，不是额外重试几次
很多人误以为 tries 3 表示“失败后再试 3 次”，实际含义是：从第一次转发开始算起，整个请求生命周期内最多尝试 3 次 —— 即 1 次原始目标 + 最多再换节点重试 2 次。
- 设为 0（Nginx 默认）= 无限重试，生产环境极度危险，极易触发请求复制、连接堆积、线程耗尽
- 设为 1 = 禁用重试，适合订单提交、支付回调、库存扣减等非幂等操作
- 设为 3 = 平衡容错与安全，能扛住瞬时网络抖动或单点短暂不可用
- 设为 ≥5，尤其 upstream 节点少于 3 台时，大概率反复打同一台已失联或假死的机器，形成无效循环
必须绑定 timeout，否则 tries 形同虚设
proxy_next_upstream_timeout 是从第一次请求发起开始计时的总耗时上限，超时立刻终止全部重试并返回错误。只控次数不管时间，等于纵容长尾请求拖垮整条链路。
WebChat Voice Proxy
下载
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
- 若单次合理响应约 3 秒，tries=3 时建议 timeout 设为 8–10 秒（留出网络调度与后端排队余量）
- 若 proxy_read_timeout 是 5 秒，timeout 不宜超过 12 秒，否则第三次尝试可能只剩不到 1 秒，几乎必然失败
- 单独设 tries=5 但 timeout=30s，前两次各卡 12 秒，第三次根本没机会执行
- 典型安全组合：proxy_next_upstream_tries 3; proxy_next_upstream_timeout 8s;
没有健康检查，重试就是往故障节点上撞
proxy_next_upstream 是被动兜底（出事才换人），健康检查才是主动防御（提前把病人抬走）。没有后者，Nginx 会不断把请求发给已失联或假死的节点，重试次数再小也白搭。
- 在 upstream 块中启用主动探测：health_check interval=3 fails=2 passes=2;
- 确保 check_http_expect_alive 只认 2xx/3xx，避免把返回 200 的假健康接口当真
- 配合被动策略：max_fails=2 fail_timeout=30s;，让偶发失败也能快速下线节点
- health_check 间隔别大于 10 秒，fails 别设 ≥5，否则宕机节点会长期滞留
只对真正可恢复的错误重试，别把业务异常当网络问题
重试不是万能兜底，加错状态码反而放大问题。500、404、403 等多数属于业务层错误，重试无意义，还可能重复扣款、生成重复订单。
- 最小安全集：proxy_next_upstream error timeout;（仅对连接失败、超时重试）
- 确认上游稳定且幂等后，可谨慎加：http_502 http_503 http_504;
- 绝对不要加：http_404 http_403 http_500;
- POST/PUT/DELETE 默认不重试；强行开启 non_idempotent 必须由业务层 100% 保障幂等（如唯一 request_id + Redis 状态记录）
