应精准配置Nginx重试策略：仅对502/503/504及timeout重试，禁用4xx和500；设tries=2、timeout=1.5s；配合健康检查主动规避故障节点；非幂等操作（如登录、Token刷新）严禁Nginx层重试。
要防止后端安全路径（如登录、鉴权、Token刷新等）偶发超时导致请求大面积挂起，关键不是盲目开启重试，而是让 proxy_next_upstream 在“该重试时精准重试、不该重试时快速失败”，同时避开非幂等操作的风险。安全路径通常依赖数据库查用户、调用密钥服务或触发风控逻辑，一旦慢，往往是资源争抢或依赖阻塞，重试不当极易引发雪崩。
只对真正可恢复的错误启用重试
安全接口返回 502/503/504 多因瞬时过载（如 Tomcat 线程池满、Redis 连接池耗尽），这类故障换节点大概率成功；但 401/403/429 或业务层 500（如 JWT 解析失败、签名验签异常）是确定性结果，重试只会放大无效流量：
- 显式配置：
proxy_next_upstream error timeout http_502 http_503 http_504;—— 不加http_401、http_403、http_500 - 禁用所有 4xx 触发：它们代表客户端状态或权限决策，非后端临时不可用
- 若上游偶发因 GC 暂停导致响应延迟，
timeout条件必须开启，否则 Nginx 根本不会切节点
严格限制重试范围：tries + timeout 必须配对生效
安全路径通常要求低延迟（如登录接口 P95 ≤ 800ms），重试不能拉长整体等待。设 tries 为节点数上限，timeout 为总耗时硬闸：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
-
proxy_next_upstream_tries 2;—— 主节点失败后仅尝试一次 backup，避免打遍全部节点 -
proxy_next_upstream_timeout 1.5s;—— 总窗口略大于单次proxy_read_timeout 1s，确保首次超时后还有余量切走 - 若
proxy_read_timeout设为 1s，而proxy_next_upstream_timeout小于 1s，首次请求就会被截断，失去重试意义
配合健康检查，把“被动重试”变成“主动规避”
单纯靠出错再重试，等于每次请求都先撞一次墙。对安全路径这类高敏感链路，应提前筛掉风险节点：
- 在
upstream块中为每个 server 添加：max_fails=2 fail_timeout=15s; - 搭配主动健康检查（需 Nginx Plus 或编译
upstream_check_module）：health_check interval=2 fails=2 passes=2; - 检查路径建议用轻量接口，如
/health?check=auth，返回 200 即认为鉴权模块就绪，不依赖数据库
非幂等操作必须零重试，哪怕返回 502
安全路径中的 POST /login、POST /token/refresh 等操作天然非幂等。Nginx 默认不对其重试，这是保护机制，切勿用 non_idempotent 强行打开：
- 保持默认行为：
proxy_next_upstream error timeout http_502 http_503 http_504;不加non_idempotent - 这样即使返回 502，Nginx 也只发一次，避免重复登录、重复发 Token、重复触发风控规则
- 若业务侧确需容错，应在应用层实现幂等（如基于
X-Request-ID缓存处理状态），而非依赖 Nginx 转发层
