close_wait大量出现说明后端未及时关闭nginx发起的fin连接。需检查ss统计、nginx日志及upstream keepalive配置是否完整（keepalive数、proxy_http_version 1.1、connection ""），并验证后端http/1.1支持与资源释放逻辑。
排查 Nginx upstream keepalive 配置是否引发后端应用大量 CLOSE_WAIT，关键在于确认连接关闭责任方——CLOSE_WAIT 出现在**后端应用侧**，说明是 Nginx 主动发 FIN 关闭了连接，而后端未及时调用 close() 响应，导致连接卡在被动关闭方的半关闭状态。
确认 CLOSE_WAIT 是否集中在后端应用进程
先定位现象是否真实存在且与 Nginx 有关：
- 在后端服务器上执行：
ss -tn state close-wait | grep ':<em>后端监听端口></em>' | wc -l（如:8080），确认数量是否异常增长 - 检查这些连接的对端地址：
ss -tn state close-wait | awk '{print $5}' | sort | uniq -c | sort -rn，若大量来自 Nginx 所在 IP，说明是 Nginx 发起的断连行为触发了问题 - 对比 Nginx 日志中是否频繁出现
upstream prematurely closed connection，该错误通常伴随后端提前关闭连接，但反向也可能是 Nginx 强制断连导致后端来不及清理
检查 Nginx upstream 和 proxy 配置是否矛盾
CLOSE_WAIT 暴增常源于 Nginx 声称启用 keepalive，却因配置缺失或冲突，实际仍以短连接方式频繁建连断连：
- 确保
upstream块中明确声明keepalive N（如keepalive 32），且该 upstream 被对应proxy_pass正确引用 - 确认
location中同时设置了：proxy_http_version 1.1;proxy_set_header Connection "";
缺一不可。若漏掉Connection ""，Nginx 可能透传客户端带的Connection: close，导致后端误判并主动断连；若漏掉proxy_http_version 1.1，Nginx 默认用 HTTP/1.0 请求后端，强制短连接 - 避免在
location或upstream中混用proxy_buffering off或proxy_cache等影响连接生命周期的指令，它们可能干扰 keepalive 复用逻辑
验证后端服务是否兼容 HTTP/1.1 长连接
Nginx 启用 keepalive 的前提是后端（如 Tomcat、Spring Boot、PHP-FPM）真正支持并保持长连接：
- Tomcat：检查
server.xml中Connector的keepAliveTimeout和maxKeepAliveRequests，确保未设为1（即禁用长连接） - Spring Boot：确认未显式关闭 HTTP/1.1，如
server.http2.enabled=false不影响，但需确保嵌入式容器（如 Tomcat）本身未降级协议 - 抓包验证：用
tcpdump -i any port <em>后端端口></em> -nn -w nginx_to_backend.pcap抓取 Nginx 到后端的流量，观察是否存在大量“FIN-ACK-FIN-ACK”四次挥手，且 FIN 由 Nginx IP 发起
检查后端应用自身资源释放逻辑
即使 Nginx 配置正确，若后端代码未正确释放 HTTP 连接（尤其使用 RestTemplate、OkHttp、HttpClient 等客户端调用第三方服务时），也会表现为 CLOSE_WAIT 持续堆积：
- Java 应用中，检查是否所有
HttpResponse、InputStream、CloseableHttpClient都被try-with-resources或显式close()释放 - 排查是否有线程池耗尽、GC 停顿过长等情况，导致处理完响应后无法及时执行 socket 关闭逻辑
- 在后端开启连接跟踪日志（如 Tomcat 的
access_log+ 自定义 filter 记录连接建立/关闭时间），比对请求完成与连接进入 CLOSE_WAIT 的时间差
