TIME_WAIT和CLOSE_WAIT非错误但数量异常预示连接释放问题；TIME_WAIT确保ACK送达和防旧包干扰，端口耗尽主因是短连接风暴或NAT会话满；CLOSE_WAIT过多表明应用未调用close()致资源泄漏，需定位进程并检查代码/配置。
Linux网络连接异常中，TIME_WAIT 和 CLOSE_WAIT 是两个高频且易被误解的状态。它们本身不是错误，但数量异常激增往往预示着连接释放不及时、服务端响应延迟、客户端未正确关闭连接等问题。排查关键在于理解状态成因、定位源头进程、评估是否真实影响服务，而非简单“调大内核参数”或“暴力回收”。
理解 TIME_WAIT 的作用与风险点
TIME_WAIT 出现在主动发起关闭（发送 FIN）的一方，持续 2×MSL（通常为 60 秒）。它的核心作用是：确保被动关闭方能收到最后的 ACK；防止旧连接的延迟报文干扰新连接（相同四元组重用时）。常见误判是“TIME_WAIT 占用端口导致无法新建连接”——实际上 Linux 默认允许端口复用（net.ipv4.ip_local_port_range + TIME_WAIT 复用机制），真正瓶颈多是端口耗尽（如短连接风暴）或 NAT 设备会话表满。
- 检查当前数量：
ss -s | grep "timewait"或netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' - 确认是否真端口不足：
ss -ant | awk '{print $4}' | cut -d':' -f2 | sort | uniq -c | sort -nr | head -10查看高频本地端口分布 - 慎用 net.ipv4.tcp_tw_reuse：仅对客户端有效（需 timestamps 开启），服务端启用可能引发 RST；net.ipv4.tcp_tw_recycle 已在 4.12+ 内核移除，切勿配置
定位 CLOSE_WAIT 过多的根本原因
CLOSE_WAIT 出现在被动关闭方（通常是服务端），表示对方已发 FIN，本方收到并回复 ACK，但应用层尚未调用 close()。这意味着**程序没有正确关闭 socket**——这是典型的资源泄漏信号。数量持续增长，往往伴随句柄耗尽、新连接拒绝（too many open files）或请求堆积。
- 快速定位进程：
ss -tanp | grep CLOSE-WAIT（需 root 权限查看进程名） - 查具体连接和 PID：
lsof -iTCP -sTCP:CLOSE_WAIT -n -P，重点关注 PID 和文件描述符数 - 结合进程状态：
ps -p看是否僵死、CPU/IO 是否异常-o pid,ppid,comm,etime,cmd - 典型场景：Java 应用未关闭 InputStream/OutputStream；Nginx 后端超时设置过长，上游迟迟不关连接；Go HTTP server 未设 ReadTimeout/WriteTimeout 导致 goroutine 挂起
实用排查流程：从现象到修复
不建议一上来就改 sysctl。优先走“现象→连接分析→进程追踪→代码/配置验证”路径：
- 监控基线：用
ss -s定期采样，对比正常时段数值（如 TIME_WAIT 稳定在 5k~10k，突增至 50k+ 需警觉） - 抓包辅助判断：
tcpdump -i any port，过滤出 FIN/ACK 交互，确认哪端先断、是否有重传或超时-w closewait.pcap - 检查服务日志：搜索 “broken pipe”、“connection reset”、“I/O timeout”，常暴露下游异常断连
- 验证连接释放逻辑：对自研服务，检查 close() 是否在 finally 块或 defer 中执行；对 Nginx/Apache，确认 proxy_timeout、keepalive_timeout 设置合理（如 upstream 超时应小于 client_header_timeout）
调整建议：只在明确必要时进行
内核参数是兜底手段，非根治方案。以下调整需严格测试：
- 减小 TIME_WAIT 持续时间：不推荐修改 net.ipv4.tcp_fin_timeout（仅影响 FIN_WAIT_2），TIME_WAIT 固定为 2MSL，无法缩短
- 扩大可用端口范围：
echo 'net.ipv4.ip_local_port_range = 1024 65535' >> /etc/sysctl.conf，适用于高并发短连接客户端 - 优化连接复用：
net.ipv4.tcp_tw_reuse = 1（客户端场景）、net.ipv4.tcp_timestamps = 1（必须开启） - 限制最大 TIME_WAIT 数量（应急）：
net.ipv4.tcp_max_tw_buckets = 2000000，超出后内核强制回收，但可能丢包，仅限临时缓解
