必须同时配置proxy_http_version 1.1、proxy_set_header connection ""和upstream keepalive n三项，缺一不可；否则nginx无法启用后端长连接，将导致大量短连接和time_wait。
upstream keepalive 参数必须配全三个关键项
只写 keepalive 32 是无效的，Nginx 不会自动启用后端长连接。必须同时满足：HTTP/1.1 协议、清空 Connection 头、显式启用 keepalive 池。
-
proxy_http_version 1.1：必须设为 1.1，HTTP/1.0 不支持长连接语义 -
proxy_set_header Connection ""：清空客户端传来的Connection头（如close或keep-alive），否则 Nginx 可能继承并中断复用 -
keepalive N：写在upstream块内，表示「每个 worker 进程对每个 upstream server 最多缓存 N 个空闲连接」，不是全局总数
漏掉任意一项，netstat -an | grep :8080 都会看到大量 TIME_WAIT 或短连接反复建连。
keepalive 数值不是越大越好，要结合后端承载力算
keepalive 32 表示每个 worker 对每台后端服务器最多保留 32 个空闲连接。如果 worker_processes 4、后端有 2 台机器，理论最大空闲连接数是 4 × 2 × 32 = 256。但这个数字得匹配后端服务的连接池上限（如 Tomcat 的 maxConnections、Go 的 http.Server.MaxIdleConnsPerHost）。
- 后端配置太小（如 Go 默认
MaxIdleConnsPerHost=2），Nginx 就算设了 100 也连不上，日志里会出现upstream keepalive connection failed - 后端未限制（如 Node.js http.Server 默认不限），Nginx 过大设置可能耗尽其文件描述符，触发
EMFILE - 典型安全值：16–64，压测时观察后端
ss -s中tcp的established和time-wait分布再调整
keepalive_timeout 和 keepalive_requests 容易被忽略
这两个参数控制的是「upstream 空闲连接池内连接的生命周期」，不是客户端连接。它们从 Nginx 1.15.3+ 开始支持，老版本（如 1.12）只认 keepalive，不支持超时与请求数限制。
-
keepalive_timeout 60s：池中空闲连接最长存活 60 秒，超时即关闭。不设则默认永久（直到被系统 kill 或内存回收） -
keepalive_requests 100：单个空闲连接最多转发 100 次请求后强制关闭，防后端连接泄漏或状态累积（比如某些 gRPC 流未正确结束） - 若后端是 gRPC over HTTP/2，必须加
keepalive_timeout，否则连接长期空闲后，后端可能主动断开导致 Nginx 报upstream prematurely closed connection
reset_timedout_connection 影响长连接复用稳定性
这个指令默认开启，作用是：当上游连接因超时（如 read timeout）关闭时，Nginx 会立即重置 TCP 连接（发送 RST），而不是优雅 FIN 关闭。对长连接池来说，这会导致连接无法回收进池子，直接丢弃。
- 现象：
upstream keepalive cache full日志频繁出现，netstat显示连接数上不去 - 解决：在
upstream块中加reset_timedout_connection off;，让超时连接走 FIN 关闭流程，才可能被复用 - 注意：关掉它会略微增加连接关闭延迟，但对复用率提升明显，尤其在高延迟网络或 gRPC 场景下
真正难调的不是数值本身，而是上下游连接生命周期的错位——Nginx 认为连接还活着，后端已经关了；或者后端允许长连，Nginx 却没配好复用入口。每次改完都该用 ss -tan state established | grep :8080 | wc -l 对比前后连接数变化。
