nginx keepalive连接池失效导致established连接堆积：需同时配置upstream keepalive、proxy_http_version 1.1和proxy_set_header connection ""，并确保keepalive_timeout小于后端空闲超时，否则连接长期滞留压垮后端连接数上限。
问题核心不在“超时”，而在于连接被长期占用却未释放——Nginx 的 keepalive 连接池空闲连接滞留、后端服务未主动断连、或协议头干扰导致复用失效，都会让连接卡在 ESTABLISHED 状态，最终压垮后端的连接数上限（如 Tomcat maxConnections 或 MySQL max_connections）。
看连接状态是否真堆积
先确认现象是否属实：
- 执行 ss -tn state established '( dport = :8080 )' | wc -l（替换为你的后端端口），统计当前到该上游的真实活跃连接数
- 对比 keepalive N 设置值 × worker_processes：若实际连接数远高于该乘积（比如 keepalive 32 + worker 4 = 128，但 ss 查出 800+），说明连接未按预期回收
- 抓包验证：用 tcpdump -i any host 192.168.1.10 and port 8080 -c 20 观察是否有大量连接持续数分钟无数据交互却未断开
查 Nginx 配置是否触发“假长连”
以下配置缺失或冲突会导致 keepalive 形同虚设：
- upstream 块中没写 keepalive 指令：默认不启用长连接，每次请求都新建 TCP，必然堆积 TIME_WAIT 或 ESTABLISHED
- location 中缺 proxy_http_version 1.1：HTTP/1.0 默认不支持 keep-alive，Nginx 会发完就关
- 没加 proxy_set_header Connection ""：若客户端请求带 Connection: close，Nginx 会原样透传给后端，导致后端主动断连，复用失败
- keepalive_timeout 设得过大（如 300s）：空闲连接挂太久，后端资源无法释放；建议设为 15–30s，略大于业务平均响应间隔
对齐后端服务的空闲策略
Nginx 不会主动感知后端是否准备关闭连接，必须靠两端超时参数协同：
- 后端如 Tomcat，需设置 connectionTimeout > Nginx 的 proxy_read_timeout（例如后者设 20s，前者至少 30s），避免后端先断而 Nginx 还在发数据
- Spring Boot 应用要检查 server.tomcat.connection-timeout 和 max-connections，确保不早于 Nginx keepalive_timeout 关闭连接
- Kubernetes 环境下，Pod 退出前必须通过 preStop Hook + terminationGracePeriodSeconds ≥ keepalive_timeout + 几秒缓冲，否则 Nginx 还在复用，Pod 已销毁
用日志和指标交叉验证泄漏点
仅看配置不够，要抓运行时证据：
- 开启 debug 日志（编译含 --with-debug，配置 error_log /path/to/error.log debug），搜索 keepalive free 和 keepalive close 行：若 free 极少、close 频繁，说明连接进不了池；若 free 多但连接数仍涨，说明没被复用或被异常占用
- error.log 中高频出现 upstream connection is busy 或 no live upstreams，往往是连接池被无效连接占满，新请求拿不到连接
- 配合后端日志查 JDBC 获取连接失败、或 MySQL show status like 'Threads_connected' 达到 max_connections，可反向印证是连接未释放而非突发流量
