proxy_next_upstream_tries 是单次请求最多转发总次数（含首次），非额外重试次数；设为3表示最多尝试3个节点，需与timeout、健康检查及错误类型协同配置，否则易引发雪崩。

proxy_next_upstream_tries 不是“重试几次”，而是单次请求最多转发多少次（含首次）。设为 3，代表最多发 3 次请求：第 1 次打原始节点，失败后最多再换 2 个节点各试一次。这个数字必须和超时、健康检查、错误类型联动，否则在高并发下极易把压力放大数倍，引发雪崩。

明确 tries 是总次数，不是额外重试数

很多人误以为 tries 3 = “失败后再重试 3 次”，实际是整个请求生命周期内最多尝试 3 个 upstream 节点（或同一节点多次，若它未被踢出）。关键细节：

• 设为 0（Nginx 默认）= 无限重试，生产环境绝对禁止
• 设为 1 = 禁用重试，适合订单提交、支付回调等非幂等操作
• 设为 3 = 最常用安全值，覆盖瞬时抖动，又不显著放大负载
• 设为 ≥5，尤其 upstream 主节点少于 3 台时，大概率反复打同一台故障机

必须绑定 proxy\_next\_upstream\_timeout 控制总耗时

只控次数不管时间，等于给慢节点开绿灯。timeout 是从第一次请求发出开始计时的**整体窗口**，超时即刻终止所有后续尝试并返回错误。

FastAPI Flask Proxy

FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

下载

• 若单次合理响应在 2–4 秒，建议 timeout 设为 6–10 秒（如 proxy_next_upstream_timeout 8s）
• 若 proxy_read_timeout 是 5 秒，timeout 不宜超过 12 秒，否则第三次尝试可能只剩不到 1 秒
• tries=3 但 timeout=30s → 前两次各卡 12 秒，第三次根本没机会执行
• timeout=2s 但 tries=3 → 首次请求刚发就超时退出，重试形同虚设

重试前先剔除坏节点：健康检查不能缺位

proxy_next_upstream 是“出事才换人”，健康检查才是“提前把病人抬走”。没有后者，重试只是空转——Nginx 会不断把请求发给已失联或假死的节点。

• 启用主动健康检查：health_check interval=3 fails=2 passes=2
• 搭配被动摘除：max_fails=2 fail_timeout=30s
• 避免 health_check 间隔 >10s 或 fails ≥5，否则宕机节点会长期滞留
• 不配健康检查时，哪怕 tries=1，流量仍会优先打向已不可用的节点

按请求语义决定是否允许重试

重试本质是风险放大器。高并发下一次失败后立刻转给另一台机器，等于把压力复制 2–3 倍。

• GET 类查询可谨慎开启：proxy_next_upstream error timeout http_502 http_503 http_504
• POST/PUT/DELETE 默认不重试；强行加 non_idempotent 必须由业务层 100% 保障幂等（如带唯一请求 ID + 服务端去重）
• 4xx 错误（如 404、403）代表客户端问题，重试无意义，还可能触发副作用
• 后端因业务异常返回 500，重试大概率还错，不应纳入重试范围