要让 proxy_pass 真正复用后端连接，关键不是“设置复用时长”，而是启用并维持空闲长连接池——必须同时配置 upstream keepalive n、proxy_http_version 1.1 和 proxy_set_header connection ''，缺一不可；否则即使写了 keepalive 也无效，nginx 仍以短连接方式转发。
要让 proxy_pass 真正复用后端连接，关键不是“设置复用时长”，而是启用并维持空闲长连接池——Nginx 本身不主动设定单个连接的“存活时长”，其复用能力取决于 upstream keepalive 配置与配套协议头协同生效。
必须配齐的三项核心配置
缺一不可，否则即使写了 keepalive 也无效：
-
upstream 块中声明
keepalive N：例如keepalive 32，表示每个 worker 进程对这台后端最多缓存 32 个空闲 TCP 连接；该值需匹配后端连接池容量（如 Tomcat 的maxConnections），过大易被拒绝 -
location 中启用 HTTP/1.1：
proxy_http_version 1.1—— HTTP/1.0 默认不支持长连接，不设此项，Nginx 仍以短连接方式转发 -
清空 Connection 头：
proxy_set_header Connection ""—— 防止客户端传来的Connection: close被透传，导致后端误判为需断连
超时参数不控制“复用时长”，但影响复用稳定性
Nginx 不通过某个参数直接定义“连接复用多久”，但以下超时设置会间接决定空闲连接能否被持续复用：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
-
proxy_read_timeout：Nginx 等待后端响应的最长时间。若后端处理慢，此值过小会导致连接被提前关闭，无法进入 keepalive 池 -
proxy_send_timeout：发送请求体超时，大文件上传或流式接口需适当调高 - 后端自身的 keep-alive 超时（如 Node.js 的
server.keepAliveTimeout或 Tomcat 的connectionTimeout）才是决定连接实际存活上限的关键——Nginx 的空闲连接只有在后端也接受复用的前提下才能被反复使用
HTTPS 后端需额外开启会话复用
当 proxy_pass https://... 时，仅靠 HTTP 层 keepalive 不够，还需：
- 在 location 或 upstream 块中启用：
proxy_ssl_session_reuse on - 确保后端支持 TLS 会话恢复（Session ID 或 Session Ticket），且其
ssl_session_timeout不宜过短（建议 ≥ 4h） - 保持前后端 TLS 版本、密码套件一致，否则握手失败将强制新建连接
验证是否真正复用成功
不能只看配置，要观察运行态：
- 检查 Nginx error log：避免频繁出现
upstream prematurely closed connection - 用
ss -tn | grep :后端端口观察 ESTABLISHED 连接数是否稳定（非随 QPS 线性飙升） - 监控后端活跃连接数是否趋于平缓，而非持续增长
