Nginx处理长连接的核心是复用TCP连接承载多个HTTP请求，通过HTTP/1.1默认机制、proxy_http_version 1.1配置、清除Connection头、两级连接池（客户端侧keepalive_timeout/requests与后端侧upstream keepalive N）及空闲连接队列管理实现高效复用。
Nginx 处理长连接的核心，是让一次 TCP 连接承载多个 HTTP 请求，而不是“用完即断”。它不靠猜测或被动等待，而是通过明确的协议支持、主动的状态维护和精细的超时控制来实现高效复用。
HTTP/1.1 默认启用，但需显式配合
HTTP/1.1 协议本身规定连接默认保持打开（即 Connection: keep-alive 是隐式行为），但 Nginx 作为反向代理，必须主动适配这一机制：
- 客户端发来的请求若含
Connection: keep-alive（HTTP/1.0 必须显式带，HTTP/1.1 可省略），Nginx 会识别并准备复用连接； - 转发给后端时，必须设置
proxy_http_version 1.1，否则后端可能按 HTTP/1.0 处理，直接关闭连接； - 需清除或重置
Connection头：用proxy_set_header Connection ""，避免把客户端的头原样传给后端造成歧义。
两级连接池：客户端侧与后端侧独立管理
Nginx 实际上维护两套长连接逻辑，彼此解耦：
-
客户端到 Nginx（前端连接）：由
keepalive_timeout（默认 75s）和keepalive_requests（默认 100 次）控制。空闲超时或请求数达上限，Nginx 主动关闭该连接； -
Nginx 到后端服务器（upstream 连接）：通过
upstream块中的keepalive N指令（如keepalive 32）定义每个 worker 进程最多缓存多少个空闲连接。这些连接被复用于后续请求，不随单个客户端连接生命周期变化。
连接复用不是“一直挂着”，而是有状态的队列管理
Nginx 内部维护一个“空闲连接队列”——不是简单地把 socket 句柄放着不管，而是：
- 当客户端完成一次请求后，Nginx 把对应 socket 标记为 idle，并加入队列；
- 下一个来自同一客户端的请求到达时，Nginx 优先从该队列中取出可用连接，跳过三次握手；
- 若队列为空或超时，才新建连接；若队列已满，则淘汰最久未用的连接。
与 TCP keepalive 机制无关，但可共存
注意区分两个概念：
- HTTP Keep-Alive：应用层行为，由 HTTP 头和 Nginx 配置驱动，目标是复用连接提升吞吐；
- TCP keepalive：传输层内核机制，用于探测连接是否“活着”，默认检测周期长达 2 小时，对 Web 性能无直接影响。
Nginx 不依赖 TCP keepalive 来维持 HTTP 长连接；它靠自己的超时逻辑主动管理。但操作系统级的 TCP keepalive 可作为兜底，防止 NAT 或防火墙因长期无数据而误删连接。
