CLOSE_WAIT大量存在表明服务端已收FIN并回ACK，但未发自身FIN；主因是应用未调用close、I/O阻塞、连接池失效、框架事件未注册或keepalive配置不当。

如果您观察到服务端存在大量CLOSE_WAIT状态的TCP连接，则表明服务端已收到客户端发送的FIN报文并回复了ACK，但自身始终未发起FIN报文完成连接关闭。以下是导致该现象的多种原因及对应排查路径：

一、服务端未主动调用close或shutdown

CLOSE_WAIT状态持续存在的根本原因是服务端应用层未执行socket关闭操作。当内核收到对端FIN后自动回ACK，连接即进入CLOSE_WAIT；若应用代码遗漏close()、shutdown()调用，或因逻辑分支未覆盖、异常提前退出、资源泄漏等原因跳过释放步骤，连接将长期滞留于此状态。

1、检查所有网络I/O处理路径，确认每个成功建立的连接在业务逻辑结束后是否均有明确的close()调用。

2、审查异常处理块（如try-catch、defer、panic recover），验证在错误路径下是否仍能执行连接释放。

3、定位长生命周期连接（如HTTP Keep-Alive、数据库连接池、消息队列消费者连接），确认其空闲超时机制是否触发close。

二、I/O线程阻塞或调度失衡

当服务端I/O线程被高负载计算、锁竞争、死循环或同步阻塞调用（如未设timeout的read/write）长期占用时，无法及时响应已就绪的FIN事件，导致连接无法进入后续关闭流程。此时CLOSE_WAIT数量会随请求并发增长而线性上升，且系统load明显高于CPU使用率。

1、使用top或htop查看进程的%CPU与%WAIT时间，确认是否存在I/O等待显著偏高的线程。

2、通过strace -p {pid} -e trace=recvfrom,sendto,close捕获系统调用，观察是否有recvfrom长时间无返回或close调用缺失。

3、检查日志中是否存在慢查询、远程服务超时、文件句柄满（too many open files）等间接阻塞线索。

三、连接池未适配服务发现变更

当服务端依赖注册中心动态获取下游地址，并使用IP+PORT作为连接池键值时，若下游实例缩容下线，旧IP对应的连接将无法被复用或主动探活，又因缺乏驱逐策略而持续保留在CLOSE_WAIT状态。该问题在压测后自动扩缩容场景中高频复现。

1、执行netstat -anp | grep CLOSE_WAIT | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr查看高频出现的远端IP。

2、比对当前服务注册中心中该下游服务的活跃实例列表，确认CLOSE_WAIT连接指向的IP是否已不在有效列表中。

3、审查连接池实现，确认是否具备基于TTL或心跳的失效连接清理机制，关键点：连接池必须支持按健康状态主动关闭失效连接，而非仅依赖应用层显式归还。

四、Netty等框架事件注册缺失

在基于Reactor模型的网络框架（如Netty）中，若accept新连接后未正确注册EPOLLIN/EPOLLHUP等事件，会导致连接虽已建立，但框架无法感知对端FIN到达，从而跳过关闭流程。此时ss -lnt命令中LISTEN套接字的Recv-Q为0，可排除全连接队列积压，但连接处于“半激活”状态。

1、使用ss -tn state close-wait sport = :{port}输出所有CLOSE_WAIT连接的本地端口，确认是否集中于某几个监听端口。

2、检查服务启动日志，确认EventLoopGroup、ChannelInitializer等核心组件是否完整初始化。

3、验证自定义ChannelHandler中是否在channelInactive()或exceptionCaught()方法中遗漏了ctx.close()调用。

五、Keepalive配置不当或未启用

当TCP keepalive未开启或参数设置过大（如tcp_keepalive_time=7200秒），服务端无法及时探测到对端异常断连，导致连接在物理中断后仍维持CLOSE_WAIT状态。尤其在NAT网关、负载均衡器主动踢除空闲连接的场景下，服务端可能完全不知晓对端已消失。

1、执行sysctl net.ipv4.tcp_keepalive_time net.ipv4.tcp_keepalive_intvl net.ipv4.tcp_keepalive_probes确认当前系统级keepalive参数。

2、在应用层Socket上显式启用keepalive：setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE, &on, sizeof(on))。

3、将tcp_keepalive_time调整为600秒（10分钟）以内，确保在常见NAT超时阈值（通常为5–15分钟）内触发探测。