必须同时配置三项：proxy_http_version 1.1;、proxy_set_header Connection "";、upstream 中 keepalive N;，缺一则长连接无法生效；还需调优超时参数并确认后端支持Keep-Alive。
把 proxy_http_version 1.1 加进 Nginx 配置，不只是换了个数字，它让 Nginx 和后端之间能复用 TCP 连接，避免每次请求都重新握手、TLS 协商和断连，显著降低延迟、提升吞吐。但单设这一项远远不够，必须配合其他关键动作才能真正生效。
必须配齐的三项基础配置
HTTP/1.1 的持久连接能力不会自动启用，Nginx 默认仍用 HTTP/1.0 转发请求。要真正发挥长连接优势，这三项必须同时存在：
-
显式声明协议版本：在
location块中写proxy_http_version 1.1;，告诉 Nginx 使用 1.1 协议与后端通信 -
清空 Connection 请求头：加
proxy_set_header Connection "";，否则 Nginx 可能将客户端传来的Connection: close直接转发，导致后端主动断开连接 -
启用 upstream 连接池：在
upstream块中配置keepalive N;（如keepalive 32;），表示每个 worker 进程最多缓存 N 个空闲长连接
为什么缺一不可？
这三者构成一个闭环逻辑：
- 没有
proxy_http_version 1.1，Nginx 仍按 1.0 发起请求，后端不认为可复用连接 - 没清空
Connection头，后端收到close就立即关闭连接，keepalive形同虚设 - 没配
upstream keepalive，即使协议支持长连接，Nginx 也不会缓存空闲连接，每次仍新建 TCP 连接
配套调优建议
光打通连接复用还不够，还需适配实际业务节奏：
- 设置合理的超时参数：
proxy_connect_timeout控制建连时间，proxy_send_timeout和proxy_read_timeout应略大于后端典型响应耗时，避免误断活跃连接 - 对 WebSocket 等长生命周期场景，
proxy_read_timeout可设为0或较大值（如86400），防止空闲时被 Nginx 主动断开 - 确认后端服务本身支持 Keep-Alive（如 Tomcat 的
connectionTimeout、Gunicorn 的--keep-alive），否则 Nginx 端再优化也无效
验证是否真正生效
不能只看配置写了没，得观察实际连接行为：
- 用
ss -tnp | grep :upstream_port查看 ESTABLISHED 连接数是否稳定、复用同一 IP:PORT 对 - 抓包检查 Nginx 发往后端的请求中，是否没有
Connection: close，且多个请求共享同一个 TCP 流 - 对比开启前后 QPS 和平均响应时间变化，尤其在高并发短请求场景下提升通常最明显
