nginx需显式配置proxy_next_upstream才能在后端故障时自动切节点，必须指定error、timeout及http_502/503/504等触发条件，并配合proxy_next_upstream_tries 3和timeout 10s限流，再通过upstream中max_fails=3 fail_timeout=30s实现健康检查。
要让 Nginx 在后端出问题时自动切到其他节点，关键就是配好 proxy_next_upstream，它不是默认就重试 5xx 的——必须手动告诉 Nginx 哪些错误值得重试、重试几次、最多花多久。
明确哪些错误该触发重试
默认只响应 error（建连失败）和 timeout（超时），对 502/503/504 这类网关错误不会自动重试。你需要显式列出：
-
必加：
error timeout—— 覆盖连接中断、建连卡死、响应挂起等底层异常 -
推荐加：
http_502 http_503 http_504—— 后端崩溃、过载或上游网关超时，换节点大概率恢复 -
可选加：
invalid_header—— 防止后端返回空白页、PHP 错误输出等“假存活”状态 -
避免加：
http_404 http_403 http_500—— 这些多是业务逻辑结果，重试不解决问题，还可能引发重复操作
限制重试次数和总耗时
光定义触发条件不够，还得防雪崩和长尾延迟：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
-
proxy_next_upstream_tries 3：最多尝试 3 个不同 upstream server（含首次），不是“额外重试 3 次” -
proxy_next_upstream_timeout 10s：从第一次请求发出开始计时，整个重试流程不能超过 10 秒 - 这两个值要配合单次超时使用，比如
proxy_read_timeout 5s，确保 timeout ≥ 单次读超时
搭配健康检查，真正避开坏节点
proxy_next_upstream 是失败后兜底，不是提前规避。没有健康检查，Nginx 仍会轮询已宕机但未标记的节点：
- 在
upstream的每个server后加max_fails=3 fail_timeout=30s：连续 3 次失败后，该节点 30 秒内不再参与调度 - 可加
backup节点：仅当所有主节点被标记为 down 时才启用，适合灾备场景 - 更优方案是启用主动健康检查（如 Nginx Plus 的
health_check或 OpenResty 的upstream_check_module）
配置示例（直接可用）
放在 upstream 或 location 块中即可：
upstream backend {
server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.12:8080 backup;
}
location /api/ {
proxy_pass http://backend;
proxy_next_upstream error timeout http_502 http_503 http_504 invalid_header;
proxy_next_upstream_tries 3;
proxy_next_upstream_timeout 10s;
proxy_connect_timeout 3s;
proxy_send_timeout 5s;
proxy_read_timeout 5s;
}
注意：http_502 是 Nginx 内部标识符，不能写成 502 或 http/502。
