核心是分两层控制：客户端到Nginx的长连接由keepalive_timeout和keepalive_requests协同管理，Nginx到后端的长连接则需upstream keepalive、proxy_http_version 1.1和proxy_set_header Connection ""三者缺一不可，且后端服务必须配合支持keep-alive。
核心是分两层控制：客户端到 Nginx 的连接复用，以及 Nginx 到后端的连接复用。两者目标一致——减少重复建连，但配置位置、参数和逻辑完全不同，不能混用。
控制客户端到 Nginx 的长连接行为
这是用户侧最直接感知的部分，重点靠 keepalive_timeout 和 keepalive_requests 协同管理：
- keepalive_timeout 30s：设为 15–60 秒较合理。太短（如 5s）起不到复用效果；太长（如 5 分钟）易积压空闲连接，增加内存与 fd 压力
- keepalive_requests 1000：单个连接最多处理请求数，默认值已足够。若业务单次交互数据极小（如大量心跳请求），可适当提高；若单次请求体大或耗时长，建议保持默认或略降，避免连接长期被占用
-
禁用不支持长连接的旧客户端：用
keepalive_disable msie6屏蔽 IE6 等已知异常 UA，防止其发送错误 Connection 头干扰复用
确保 Nginx 主动复用后端连接
仅客户端复用不够，Nginx 仍可能为每个请求新建后端连接。必须在 upstream 块中显式启用连接池：
- upstream 内加 keepalive 32：数字建议设为后端单实例并发处理能力的 1/4～1/2（例如后端能稳撑 128 并发，这里设 32）。不是越大越好，过多空闲连接会占用后端资源
-
proxy_http_version 1.1 和 proxy_set_header Connection "" 必须同时存在：前者启用 HTTP/1.1，后者清空 Connection 头，避免 Nginx 自动加
Connection: close，从而让后端真正收到 keep-alive 请求 -
后端服务需配合：Tomcat 要设
keepAliveTimeout="60000"、maxKeepAliveRequests="100"；Node.js 或 Go 服务也需开启 HTTP/1.1 keep-alive 且不主动断开空闲连接
针对 WebSocket 或长连接协议的特别处理
HTTP 长连接只管请求级复用，而 WebSocket 是全程 TCP 连接，需要额外透传升级头：
-
透传关键 header：
proxy_set_header Upgrade $http_upgrade;与proxy_set_header Connection "upgrade";缺一不可，否则 101 升级失败 -
延长超时时间：WebSocket 连接通常持续数小时，
proxy_read_timeout和proxy_send_timeout建议设为 86400（24 小时）或更高，避免 Nginx 主动中断 -
负载均衡策略要稳定：用
ip_hash或一致性哈希（如hash $remote_addr consistent），防止连接在多个后端间漂移导致状态丢失
验证复用是否生效的关键指标
配完不验证等于没配。重点关注三个维度：
- 查 Nginx 活跃连接：用
nginx -s status（需启用 stub_status）或 Prometheus 的nginx_connections_active，对比峰值并发数与活跃连接数比值 —— 若接近 1，说明复用率极低 - 看后端 established 连接数：执行
ss -s | grep "TCP:"，若远低于客户端并发量（比如客户端 1 万，后端只有 2 千 established），说明 upstream keepalive 已起效 - 抓包确认三次握手频率：用
tcpdump -i any port 80 or port 443 -c 100观察 SYN 包密度，优化后应明显稀疏
