必须配置 proxy_http_version 1.1 才能启用 http/1.1 持久连接，否则 nginx 默认使用 http/1.0 导致每次请求新建 tcp 连接；还需配合 proxy_set_header connection "" 和 upstream keepalive n 才能真正复用连接。
要让 Nginx 在反向代理路径下真正复用 TCP 连接、降低后端建连开销、提升吞吐，必须显式配置 proxy_http_version 1.1——这不是可选项，而是激活长连接复用的硬性前提。Nginx 默认向上游发 HTTP/1.0 请求，哪怕客户端用的是 1.1，不加这行，后端永远收不到 Keep-Alive 语义，upstream 的 keepalive 配置也完全失效。
为什么 proxy_http_version 1.1 是不可绕过的开关
HTTP/1.0 默认每次请求都关闭连接；HTTP/1.1 才默认支持持久连接（Keep-Alive）。但 Nginx 不会自动升级协议版本——它严格按配置说话。没写这一行，Nginx 就按 1.0 构造请求头：不带 Connection: keep-alive，忽略客户端传来的 Upgrade 头，也不识别后端返回的 Keep-Alive: timeout=60, max=100 字段。结果就是：每个请求都新建 TCP 连接，连接池形同虚设。
必须搭配的两项关键配置
单写 proxy_http_version 1.1 还不够，需与以下两项协同生效：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
-
proxy_set_header Connection ""：清空客户端传入的 Connection 头（比如close或keep-alive），避免干扰上游判断；空字符串表示“由协议版本和上下文决定”，Nginx 才会按 HTTP/1.1 规则自动管理连接生命周期 -
upstream 块中启用
keepalive N：例如keepalive 32;表示每个 worker 进程最多缓存 32 个空闲连接到该 upstream；同时建议配keepalive_timeout 60s;和keepalive_requests 100;控制连接复用时长与请求数上限
针对 WebSocket 等协议升级场景的特殊处理
若代理的是 WebSocket、gRPC 等需要 Upgrade 的服务，除 proxy_http_version 1.1 外，还需：
- 用
map动态设置 Connection 头：
http {
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
}
再在 location 中写proxy_set_header Connection $connection_upgrade;，避免普通请求被误标为 upgrade -
proxy_set_header Upgrade $http_upgrade;：透传原始 Upgrade 头（如websocket） - 禁用缓冲与调长超时：
proxy_buffering off;、proxy_read_timeout 86400;、proxy_send_timeout 86400;
验证是否真正生效
配置完不能只看文件，得实测确认：
- 用
tcpdump -i any port 8080抓 Nginx 到后端的包，观察多个请求是否复用同一 TCP 流（SYN 少、FIN 少、中间大量 HTTP 包） - 开启
stub_status模块，访问/nginx_status，关注Waiting连接数是否稳定维持（而非频繁飙升又归零） - 检查后端响应头：应含
Connection: keep-alive及Keep-Alive: timeout=60, max=100（取决于后端框架配置）
