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

要避免请求在集群内无限轮询，关键不是单纯设一个数字，而是让 proxy_next_upstream_tries 在次数、时间、节点状态三者之间形成有效制衡。默认值 0（不限次）等于主动放弃控制，必须显式覆盖。

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

设为 3 表示：首次转发 + 最多再试 2 次，整个请求生命周期最多发 3 次请求。它不保证打到 3 个不同节点——若健康检查没启用，可能反复打同一台故障机。

• 设为 1 = 禁用重试，适合订单提交、支付回调等写操作
• 设为 3 = 平衡容错与安全，覆盖常见瞬时故障
• 避免设为 0 或 ≥5，尤其 upstream 节点少于 3 台时，极易陷入无效循环

必须绑定 proxy_next_upstream_timeout 控制总耗时

只限次数不管时间，等于给慢节点开绿灯。timeout 是从第一次请求发出开始计时的总窗口，超时即终止，不等第三次响应。

FastAPI Flask Proxy

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

下载

• 若后端 P95 耗时约 2–3 秒，建议 timeout 设为 6–10 秒
• 若 proxy_read_timeout 是 5 秒，proxy_next_upstream_timeout 不宜小于 8 秒（否则首次就可能被截断），也不宜大于客户端总超时（如前端设了 30 秒，这里设 25 秒就太激进）
• 典型安全组合：proxy_next_upstream_tries 3; + proxy_next_upstream_timeout 10s;

强制搭配主动健康检查，让重试“有路可换”

proxy_next_upstream 是被动兜底，健康检查才是主动隔离。没有后者，重试大概率还在往宕机节点上撞。

• 在 upstream 块中启用：health_check interval=3 fails=2 passes=2;
• 配合 max_fails=2 fail_timeout=30s，让连续失败的节点被临时摘除
• 确保健康检查路径返回真实可用状态（比如调用 /health 但后端 DB 已挂，就该返回 503 而非 200）

精准筛选可重试的错误类型，避免误判业务异常

不是所有失败都该重试。4xx 和多数 500 是确定性结果，重试只会放大无效流量。

• 推荐最小化触发条件：proxy_next_upstream error timeout http_502 http_503 http_504;
• 慎加 http_500：仅当确认是局部问题（如某节点缓存损坏），而非全局业务异常（如数据库死锁）
• 绝对禁用 http_404、http_403：这是客户端或权限问题，换节点毫无意义
• 非幂等请求（POST/PUT/PATCH）默认不重试；加 non_idempotent 前，必须 100% 确认后端已实现幂等（如基于请求 ID 去重）