nginx需配置upstream主备节点+proxy_next_upstream error timeout http_502，配合max_fails/fail_timeout被动健康检查及proxy_next_upstream_tries/timeout限制，才能在后端瞬时故障时自动重试并切换至备用节点。
502 错误本身不是后端主动返回的，而是 Nginx（或其他网关）在无法从后端拿到有效响应时自己生成的。所谓“后端返回 502”是误解——真实情况是：Nginx 尝试连接或等待后端时失败（如连接被拒、超时、收到空响应或非法响应），于是它向客户端返回 502。因此，“自动切换到备用路径”的关键不在 location 块里写逻辑，而在于 upstream + proxy_next_upstream 的协同配置。
用 upstream 定义主备，别在 location 里硬编码路径
直接在 location 中写多个 proxy_pass、用 if 判断或 try_files 模拟切换，都是无效甚至报错的做法。Nginx 不支持运行时动态改 proxy_pass，且违背配置可维护性原则。
- 定义一个含主、备节点的 upstream 块，backup 节点仅在所有非 backup 节点都被标记为不可用时才启用；
- 主节点配置 max_fails 和 fail_timeout，例如 server 192.168.1.10:8080 max_fails=2 fail_timeout=10s；
- 备用节点加 backup 标识，例如 server 192.168.1.11:8080 backup；
- location 块只需简单指向该 upstream：proxy_pass http://backend_pool;
开启 proxy_next_upstream，明确把 502 当作重试条件
仅定义 upstream 不足以触发故障转移。必须显式告诉 Nginx：遇到哪些情况可以尝试下一个上游节点。
- proxy_next_upstream error timeout http_502：覆盖连接失败、超时、以及上游返回 502 这三类典型失败；
- proxy_next_upstream_tries 3：最多尝试 3 次（含首次请求），防止雪崩；
- proxy_next_upstream_timeout 10s：整个重试过程总耗时不超过 10 秒；
- 注意：http_502 是必要项——没有它，即使后端返回 502，Nginx 也不会重试。
避免健康检查干扰，用被动探测更稳妥
主动 health_check 可能因探针路径不稳定或响应延迟，过早剔除健康节点，导致 backup 提前启用，反而降低可用性。
- 建议关闭 upstream 内的 active health_check，依赖 Nginx 默认的被动探测机制；
- 确保 proxy_http_version 1.1 和 proxy_set_header Connection "" 已设置，避免 HTTP/1.0 连接复用引发重试异常；
- 若使用 keepalive，需配 keepalive_requests 和 keepalive_timeout，防止长连接僵死影响判断。
验证是否生效的两个关键动作
配置完不能只靠猜测，要实操验证：
- 临时停掉主后端服务（如 systemctl stop myapp），用 curl -v http://your-domain/api/test 观察响应是否来自备机，并检查 Nginx access.log 是否出现两次记录（首次失败 + 重试成功）；
- 实时查看 tail -f /var/log/nginx/error.log：若看到 no live upstreams，说明主备都不可用，需检查备机状态；若只有少量 upstream timed out 或 Connection refused，说明重试机制正在工作。
