要让nginx真正复用tcp连接、跳过三次握手和tls协商，必须同时配置客户端侧（keepalive_timeout 30–65秒、keepalive_requests、tls会话复用）和上游侧（upstream keepalive n、proxy_http_version 1.1、proxy_set_header connection ""、keepalive_timeout与keepalive_requests匹配后端能力），并确保后端服务支持keep-alive，缺一不可。
要让 Nginx 真正复用 TCP 连接、跳过三次握手和 TLS 协商，得同时配置客户端侧和上游侧两套 keepalive，缺一不可。单纯调大 keepalive_timeout 没用，关键在匹配真实请求节奏，并打通整个链路。
客户端连接保持：控制浏览器或 App 复用连接
这是面向用户端的长连接，由 keepalive_timeout 和 keepalive_requests 共同决定：
- keepalive_timeout：设为 30–65 秒较稳妥。常规网页首屏资源（HTML/CSS/JS/图片）基本在前 20 秒内发完，设太短（如 5 秒）会导致频繁重连；设太长（如 300 秒）则空闲连接积压，浪费文件描述符
- keepalive_requests：默认 100 足够，高并发小请求场景可提到 500–1000；若单次请求体大或后端响应慢，建议保持默认或略降，避免一个连接长期被占
- 务必加
keepalive_disable msie6;（兼容旧 IE），现代环境可省略；HTTPS 下记得启用 TLS 会话复用（ssl_session_cache和ssl_session_timeout），否则 TCP 复用了，TLS 还得重协商
上游连接池：减少 Nginx 到后端的建连开销
Nginx 默认对后端用短连接，每请求一次就三次握手一次——这才是性能黑洞。需在 upstream 块中显式启用连接池：
-
keepalive N：每个 worker 进程保留的空闲连接数，建议 32–200。例如后端有 2 台实例，单实例能扛 200 并发，那 upstream 中设
keepalive 64较合理 - keepalive_timeout：上游空闲连接存活时间，建议 15–30 秒。比客户端侧略短，利于及时回收，又足够覆盖多数后端请求间隙
- keepalive_requests：单个上游连接最多转发多少次请求，默认 100，可按需调高至 500 或 1000，防低频长连接长期不释放
代理行为必须同步修正
即使 upstream 配了 keepalive，若 proxy_pass 发送 Connection: close，后端照样断连。以下两行必须加在 location 或全局 server 块中：
- proxy_http_version 1.1;：强制走 HTTP/1.1，它是 keep-alive 的协议基础
-
proxy_set_header Connection "";：清空 Connection 头，否则 Nginx 默认加
close，直接废掉所有努力 - 不用手动加
Keep-Alive响应头，Nginx 会自动处理
后端服务也要支持 keep-alive
上游连接池只是“前端”，后端不配合等于白搭：
- Tomcat：设
keepAliveTimeout="60000"、maxKeepAliveRequests="100" - Node.js（如 Express）：确保没禁用
server.keepAliveTimeout，默认已开启 HTTP/1.1 持久连接 - Go（net/http）：默认支持，但若显式调用
conn.Close()或设置超时过短，也会提前断连 - 验证方式：抓包看后端响应头是否含
Connection: keep-alive，且无Connection: close
