nginx后端连接复用需三者协同：proxy_http_version 1.1启用http/1.1协议，proxy_set_header connection ""清空连接头，upstream中keepalive声明连接池大小；缺一不可，否则连接无法复用。
worker_connections 本身不直接实现连接复用，它只是定义每个 worker 进程能同时处理的连接总数（含客户端、上游、缓存等）。真正让连接“复用起来”的，是一整套协同配置——包括协议支持、头部控制、连接池声明和超时管理。只调大这个值，反而可能因资源耗尽导致连接被静默拒绝。
必须配齐的三项 upstream 复用基础
反向代理场景下，Nginx 与后端之间的连接复用需三者同时生效：
-
启用 HTTP/1.1 协议：在 location 块中加
proxy_http_version 1.1;。HTTP/1.0 默认关闭持久连接，不设此项，每次请求都会新建 TCP 连接。 -
清空 Connection 请求头：加
proxy_set_header Connection "";。否则 Nginx 可能把客户端发来的Connection: close转发给后端，强制断连。 -
声明连接池大小：在 upstream 块中写
keepalive 32;。它表示每个 worker 进程最多缓存 32 个空闲连接到该后端地址，不是全局总数——8 个 worker 就是 256 条上限。
合理控制单连接生命周期
复用不是“一直不关”，而是“该用就用、该放就放”：
-
keepalive_timeout：建议设为 20–45 秒，且必须小于后端的空闲超时（如 Tomcat 的
connectionTimeout），否则 Nginx 想复用，后端已关。 - keepalive_requests：默认 100，高并发可调至 500–1000。限制单连接处理请求数，避免后端因长连接积累状态或内存泄漏。
客户端侧也要配合 keepalive
如果前端（浏览器、App、SDK）本身不复用连接，Nginx 再怎么优化也白搭：
- 确保
http { keepalive_timeout 65; }已开启，让客户端知道可复用连接。 - 短连接密集型业务（如 H5 秒杀页），可设
keepalive_timeout 15;，平衡复用率与槽位释放速度。 - WebSocket 或 HTTP/2 长连接场景，建议设为 300–3600 秒，并确认后端支持对应协议。
验证是否真的复用成功
别只看配置写了没，要用数据说话：
- 压测中执行
ss -tan | grep :后端端口 | grep ESTAB | wc -l，连接数应稳定在worker_processes × keepalive附近，而不是随 QPS 持续上涨。 - 抓包观察连续请求是否复用同一源端口 → 目标端口组合；若每次都是新 SYN，说明根本没复用。
- 后端执行
ss -s | grep "TIME_WAIT"，复用率高时该值应明显下降。
