proxy_next_upstream_tries设为3表示最多尝试3次（含首次），重试目标是当前upstream中未被标记为不可用的节点，非固定轮转；需配合健康检查、合理错误触发条件及超时控制，否则易陷入无效循环。

proxy_next_upstream_tries 的计数包含首次请求，设为 3 表示最多尝试 3 次（1 次原发 + 最多 2 次重试），但这个数字本身不能防止无效循环——关键在于它和 upstream 节点状态、健康检查、重试触发条件三者配合是否合理。

重试次数不是“轮转次数”，而是“总尝试上限”

nginx 不会按顺序遍历所有 upstream 节点；它在每次失败后，从当前 upstream 块中**随机选一个未被标记为不可用的节点**重试。所以：

• tries = 3 并不意味着“打给 A → 失败 → 打给 B → 失败 → 打给 C”，而可能是“打给 A → 失败 → 再打给 A（若未被踢出）→ 再打给 A”，尤其当健康检查缺失或失效时
• 如果 upstream 中只有 1 个节点在线，即使 tries 设为 10，所有重试都只会打向这一个节点，形成无效循环
• 默认情况下，单次请求只要没向客户端发送任何字节（即响应头未发出），就满足重试前提；一旦开始发包，该指令立即失效

必须搭配健康检查，否则重试毫无意义

proxy_next_upstream 是被动容错：等出错了才换人；而健康检查是主动探测：提前把坏节点摘掉。没有后者，重试大概率反复打向同一故障节点。

WebChat Voice Proxy

⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**

下载

• 在 upstream 块中启用 http 健康检查：health_check interval=3 fails=2 passes=2;（需 http_upstream_module 支持）
• 确保 check_http_send 和 check_http_expect_alive 配置合理，例如返回 2xx/3xx 才认为存活
• 避免 health_check 间隔过长（如 >10s）或失败阈值过高（如 fails=5），否则节点宕机后仍会长时间参与重试

严格控制哪些错误触发重试，避免误判

盲目加入 http_404、http_500 等状态码，容易让 nginx 把业务错误当成可重试故障，导致重复提交或循环打向同一台已返回明确错误的服务器。

• 推荐最小化配置：proxy_next_upstream error timeout;（默认值），只对网络层问题重试
• 仅当确认上游服务幂等且稳定时，再谨慎添加 http_502/http_503/http_504；不要加 http_404 或 http_403，它们通常代表资源不存在或权限不足，重试无意义
• 非幂等请求（如 POST）默认不重试；显式加 non_idempotent 前，必须确保后端完全幂等，否则可能引发资金扣减、订单重复等严重后果

配合超时与连接控制，切断长尾请求

仅靠 tries 无法阻止慢节点拖垮整体响应。必须用 proxy_next_upstream_timeout 限制整个重试过程的耗时起点——从第一次请求发起开始计时。

• 例如设为 proxy_next_upstream_timeout 6s;，即使 tries=3，只要三次尝试累计耗时超 6 秒，立刻终止并返回错误
• 同时调低 proxy_connect_timeout（如 1s）和 proxy_read_timeout（如 3s），加快单次失败判定速度，减少无效等待
• 避免 proxy_next_upstream_tries 和 proxy_next_upstream_timeout 设置矛盾，比如 tries=10 但 timeout=1s，实际可能连一次重试都完不成