nginx keepalive 长连接需协议、头部、连接池、超时四者协同：必须配置 proxy_http_version 1.1、proxy_set_header connection ""、upstream keepalive n；并合理设置 keepalive_timeout（20–45s）和 keepalive_requests（500–2000），同时匹配后端能力并验证生效。
要让 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"）。否则 Nginx 可能将客户端传来的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 会立即释放该连接，无法复用。
验证是否真生效，别只看配置
调完不验证 = 白调：
- 用
ss -tan | grep :backend_port | wc -l对比高峰连接数，应明显低于调优前； - Nginx 日志加
$upstream_connect_time $upstream_header_time，观察建连耗时是否稳定下降； - 抓包或查响应头，确认后端返回含
Connection: keep-alive，且无意外Connection: close。
