Nginx默认不因502重试，因其视完整HTTP响应为通信完成；需显式配置proxy_next_upstream error timeout http_502，并确保upstream含多节点且配置位于location块内。

默认情况下，Nginx 遇到后端返回 502 Bad Gateway 并不会自动切换节点重试——它只把 502 当作一个合法的 HTTP 响应原样返回给客户端。要让它在收到 502 时尝试下一个 upstream server，必须显式启用并精准配置 proxy_next_upstream。

为什么 502 默认不触发重试？

Nginx 的设计逻辑是：只要成功建立了 TCP 连接、收到了完整的 HTTP 响应（哪怕状态码是 502），就认为“通信完成”，不再视为可重试的失败。而 proxy_next_upstream 默认仅响应两类底层异常：

• error：连接被拒、连接重置、DNS 失败等网络级错误
• timeout：建连超时、发送请求超时、读取响应头超时

502 属于应用层响应，不在默认列表中，所以必须手动加上 http_502 才能激活重试行为。

基础配置：让 502 触发切换

关键配置需放在 location 或 server 块中（不能只写在 http 顶层），且依赖 upstream 定义：

• 定义至少两个后端节点：upstream backend { server 10.0.1.10:8080; server 10.0.1.11:8080; }
• 在 location 中启用重试：proxy_next_upstream error timeout http_502;
• 确保 proxy_pass 指向该 upstream：proxy_pass http://backend;

这样当第一个节点返回 502，Nginx 就会立即发起第二次请求，打到第二个节点。

WebChat Voice Proxy

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

下载

避免重试失效的常见坑

即使写了 http_502，仍可能不切换，原因通常有：

• upstream 里只有一个 server → 没有“下一个”可切，重试无意义
• 配置写在 http 块但没被具体 location 继承（Nginx 不自动继承该指令）
• 后端虽返回 502，但已开始传输响应体 → Nginx 认为响应已发出，拒绝重试（此时需靠 invalid_header 或更早的 timeout 拦截）
• 未配 proxy_read_timeout，导致慢响应未被识别为 timeout，错过重试时机

推荐增强配置（生产可用）

单加 http_502 不够稳健，建议组合以下参数：

• proxy_next_upstream error timeout http_502 http_503 http_504; —— 覆盖常见网关类瞬时故障
• proxy_next_upstream_tries 3; —— 最多尝试 3 次（首次 + 2 次重试）
• proxy_next_upstream_timeout 10s; —— 整个重试过程总耗时不超 10 秒
• proxy_read_timeout 5s; —— 让卡在响应头阶段的“假死”节点更快暴露为 timeout

配合 upstream 中的 max_fails=2 fail_timeout=30s，还能实现被动健康检查，让连续出错的节点暂时剔除。