nginx负载均衡需协议、头部、连接池三者对齐才能复用连接：必须配置proxy_http_version 1.1、proxy_set_header connection ""、upstream keepalive n；并合理设置keepalive_timeout和keepalive_requests，匹配后端能力，https后端建议终止在nginx侧。
要让 Nginx 负载均衡真正复用连接、提升处理能效，不能只加一行 keepalive，必须协议、头部、连接池三者对齐，缺一不可。否则后端连接数仍随 QPS 线性上涨，优化就落了空。
必须配齐的三项基础配置
这三项不是可选，漏掉任意一个，upstream 的 keepalive 就完全不生效：
-
启用 HTTP/1.1 协议：在
location块中写proxy_http_version 1.1;。HTTP/1.0 默认关闭持久连接，不设此项，Nginx 仍以短连接向上游发请求。 -
清空 Connection 请求头：加
proxy_set_header Connection "";（注意是空字符串，不是"keep-alive"或"close"）。否则可能把客户端传来的Connection: close转发给后端，导致连接被主动中断。 -
声明 upstream keepalive 数值：在
upstream块中写keepalive 32;。它表示每个 worker 进程对每台后端服务器最多缓存 32 个空闲长连接；若你有 4 个 worker，理论最大空闲连接数是 128，不是全局总数。
控制单条连接的生命周期
只管“有多少连接”不够，还要管“每条连多久、干多少活”，否则容易过早释放或长期空闲堆积：
-
keepalive_timeout：建议设为 20–45 秒，且必须小于后端服务的空闲超时（如 Tomcat 的
connectionTimeout）。若 Nginx 想复用，后端已关闭，复用就会失败并退化为短连接。 - keepalive_requests：默认仅 100，高并发 API 场景下极易触发高频建连。建议调至 500–2000；React 类前端一次页面加载可能发起数十个请求，设 2000 可覆盖整条链路。
匹配后端能力与负载策略
keepalive 数值不能拍脑袋定，需结合后端承载力反推：
- 若后端单实例平均并发连接数约 20，
worker_processes为 4，keepalive 设 32 较稳妥；若后端maxConnections=200，可按 0.6～0.8 折算，设 120～160。 - 务必检查后端响应头是否含
Connection: close——常见于错误响应、调试开关开启、WAF 干预等场景，Nginx 会立即释放该连接，无法复用。 - 长连接场景下，建议改用
least_conn负载策略，缓解连接倾斜问题，避免某台后端被“粘住”而其他节点空闲。
HTTPS 后端的特别提醒
若后端本身是 HTTPS，不推荐直接 proxy_pass https://。这会导致 Nginx 无法复用 TLS 连接，每次请求都重建握手，失去连接池意义。
推荐架构是：客户端 ⇄ Nginx（HTTPS 终止）⇄ 后端（HTTP + keepalive）。这样既能统一管理证书、启用会话复用，又能稳定复用 HTTP 长连接。
