要让后端节点故障时请求自动换节点重试，需协同配置四方面：1. 明确仅对timeout、http_502/503/504、invalid_header等可恢复错误重试；2. 用proxy_next_upstream_tries和timeout限制重试次数与总时长；3. 配合健康检查（max_fails/fail_timeout或主动探活）避免打坏节点；4. 仅对幂等请求（如GET/HEAD）开启重试，POST/PUT/DELETE需业务层严格保障幂等性才可谨慎启用。
要让后端节点故障时请求自动换节点重试，关键不是加一条指令，而是配置一组协同工作的参数：明确哪些错误值得重试、限制重试次数与时长、确保有健康节点可选、并守住幂等底线。
只对真正可恢复的错误触发重试
默认情况下，Nginx 仅在连接失败（error）时重试。生产中必须显式补充以下三类典型瞬时故障：
-
timeout：配合
proxy_read_timeout使用，响应头迟迟不返回即切换 - http_502 / http_503 / http_504：网关层错误，大概率是后端临时不可用，适合换节点
- invalid_header：后端返回空页、非法响应头（如无 Status 行），说明服务已假死
避免加入 http_404 或 http_403 —— 这些是业务逻辑结果，重试不会改变响应，反而增加无效负载。慎加 http_500，除非确认是偶发异常（如 GC 暂停），否则应先排查日志。
用 tries 和 timeout 控制重试边界
不设限制的重试会拖慢响应、放大延迟，甚至引发雪崩。这两个参数必须成对使用：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
-
proxy_next_upstream_tries 3：最多尝试 3 个不同节点（含首次），不是“重试 3 次” -
proxy_next_upstream_timeout 10s：从第一次请求发出开始计时，超时即终止并返回错误
例如单次 P95 耗时约 4 秒，设为 10 秒既能覆盖一次有效重试，又防止长尾请求堆积。
靠健康检查避免反复打坏节点
proxy_next_upstream 是被动兜底，不主动探测节点状态。若不配合健康检查，每次请求仍可能先打到已宕机的节点，白白失败再重试：
- 在 upstream 的每个 server 后加
max_fails=3 fail_timeout=30s：连续 3 次失败（包括重试触发的失败）后，该节点 30 秒内不再参与调度 - 可选加
backup节点：仅当所有主节点被标记为不可用时才启用，作为最后一道防线 - 若用 Nginx Plus 或编译了
upstream_check_module，建议启用主动健康检查：health_check interval=3 fails=2 passes=2
只对幂等请求开启重试
重复执行不能带来副作用，这是重试安全的前提：
- GET / HEAD 请求可放心重试：天然幂等，Nginx 默认支持
- POST / PUT / DELETE 默认不重试：Nginx 有内置保护机制，防止重复提交订单、扣款等
- 若业务层已严格保障幂等（如通过
X-Request-ID+ Redis 记录处理状态），且日志可追溯，才考虑谨慎开启；否则宁可返回明确错误或交由客户端重试
