要让Nginx代理真正复用TCP连接，必须同时配置客户端→Nginx和Nginx→后端两条链路的长连接：前者需调优keepalive_timeout（65–300秒）和keepalive_requests（建议≥10000），后者需在upstream设keepalive、location中启用HTTP/1.1并清空Connection头，且需与后端超时及连接池参数对齐。
要让 Nginx 代理真正复用 TCP 连接、减少握手开销、提升转发效率，必须同时打通「客户端→Nginx」和「Nginx→后端」两条链路的长连接。只配一边，效果会大打折扣。
客户端到 Nginx 的长连接控制
这部分默认已启用，但需合理调优才能稳定复用：
-
keepalive_timeout：设为 65–300 秒（如
keepalive_timeout 120s;），避免空闲连接过早关闭；设为 0 表示禁用 -
keepalive_requests：建议调高至 10000 或更高（如
keepalive_requests 10000;），防止高频请求下连接频繁重建 - 无需额外加 header —— 只要客户端发的是 HTTP/1.1 请求且未带
Connection: close，Nginx 就自动复用
Nginx 到后端服务的长连接配置
这是最容易出错、也最关键的环节，三要素缺一不可：
- 在
upstream块中设置 keepalive N（如keepalive 32;），表示每个 worker 进程最多缓存 N 个空闲连接 - 在
location中添加 proxy_http_version 1.1，强制使用支持长连接的协议版本 - 同时添加 proxy_set_header Connection ""（注意是空字符串），清掉客户端传来的
Connection: close等干扰头
后端兼容性与参数对齐
即使 Nginx 配全了，后端不配合也会导致连接被主动断开：
- 确认后端服务开启长连接支持（如 Tomcat 的
connectionTimeout、Node.js 的server.keepAliveTimeout） - 确保 Nginx 的
keepalive_timeout不超过后端的空闲超时时间，否则连接会被后端先关闭 - upstream 的
keepalive值需匹配后端连接池容量，公式参考：keepalive × worker_processes ≤ 后端总连接池 × 0.7
验证是否生效的实用方法
光看配置没用，得观察真实连接行为：
- 执行
ss -tnp | grep :，查看是否有稳定存在的ESTABLISHED连接（而非瞬时暴涨后归零） - 检查 Nginx error log，避免出现
upstream prematurely closed connection - 抓包观察：Nginx 发往后端的请求头中不应含
Connection: close，且多个请求应复用同一 TCP 流
