Nginx通过upstream主备+proxy_next_upstream机制实现502自动重试与故障转移：主服务器设max_fails/fail_timeout，backup节点仅在主全失效时启用，并配置http_502、tries和timeout确保可控重试。
当后端服务不稳定、偶发502错误时，Nginx的location块本身不能“自动切换路径”，但可通过上游（upstream）配合proxy_next_upstream机制实现请求重试与故障转移——这才是真正可靠、符合生产实践的“备用路径”逻辑。
用 upstream 定义主备后端，而非在 location 里硬编码路径
直接在location中写多个proxy_pass或用if判断是错误做法（Nginx不支持，且违反配置原则）。正确方式是：先定义一个含主、备服务器的upstream块，再让location指向它。
示例配置：
upstream backend_pool {
server 192.168.1.10:8080 max_fails=2 fail_timeout=10s;
server 192.168.1.11:8080 backup;
}
其中：
• 第一行是主服务，连续失败2次（默认5秒内）即标记为不可用，10秒后重新探活；
• backup关键字表示该节点仅在所有非backup节点都失效时才启用。
开启 proxy_next_upstream，让502触发重试
仅定义upstream还不够。需在location或server上下文中显式启用重试逻辑：
location /api/ {
proxy_pass http://backend_pool;
proxy_next_upstream error timeout http_502;
proxy_next_upstream_tries 3;
proxy_next_upstream_timeout 10s;
}
关键参数说明：
• http_502：明确将502响应视为可重试条件；
• error覆盖连接拒绝、超时等底层失败；
• tries限制最多尝试3次（含首次），避免无限循环；
• timeout限定整个重试过程不超过10秒。
确保健康检查与连接复用不干扰重试逻辑
若启用了主动健康检查（如health_check），需注意：它可能提前剔除节点，导致backup过早启用。建议保持简单策略：
- 关闭
upstream中的health_check（除非你有强依赖的L7探针）； - 用
max_fails/fail_timeout这种被动探测更稳妥； - 确认
proxy_http_version 1.1和proxy_set_header Connection ""已配置，避免因HTTP/1.0连接复用问题导致重试失败。
验证是否生效的两个实操动作
• 临时停掉主后端（如systemctl stop myapp），用curl -v http://your-domain/api/test观察是否返回备机响应，同时检查Nginx访问日志中是否有两次记录（重试痕迹）；
• 查看Nginx错误日志：tail -f /var/log/nginx/error.log，出现upstream: "http://backend_pool" + no live upstreams说明备机也挂了，配置已起作用。
