大量TIME_WAIT本身不是问题，真正要查的是它是否挤占完本地端口池导致新连接失败；需三步确认：一查端口范围与TIME_WAIT数量是否逼近（如>25000）；二查dmesg或kern.log中是否有“TCP: time wait bucket table overflow”表明内核已丢包；三比对“cannot assign”错误日志与TIME_WAIT峰值是否时间同步；并排除conntrack打满和FD耗尽干扰。
大量 TIME_WAIT 本身不是问题，真正要查的是它是否已挤占完本地端口池，导致新连接失败。排查核心是三件事：看数量是否逼近端口上限、查内核有没有丢包痕迹、比对错误日志和 TIME_WAIT 峰值是否同步。
一、确认端口是否真的快用完了
别只数 TIME_WAIT 个数。先查系统允许用的临时端口范围：
- 运行 cat /proc/sys/net/ipv4/ip_local_port_range，典型输出是 32768 60999，即约 28232 个可用端口
- 再统计当前 TIME_WAIT 数量：ss -ant state time-wait | wc -l
- 如果后者持续接近或超过前者差值（比如 >25000），说明端口池已吃紧
二、检查内核是否已在静默丢弃连接
端口耗尽时，Linux 内核不会报错，但会在日志里留下线索：
- 运行 dmesg | grep "time wait bucket" 或 dmesg | grep "TCP: time wait bucket table overflow"
- 也查系统日志：grep "time wait bucket" /var/log/kern.log 2>/dev/null
- 只要出现 TCP: time wait bucket table overflow，就表示内核已开始强制回收甚至丢弃新连接请求，不是预警，是故障已发生
三、验证业务错误是否与 TIME_WAIT 高峰同步
把现象和数据拉到同一时间轴上，才能确认因果关系：
- 开一个终端实时监控：watch -n 1 'ss -ant state time-wait | wc -l'
- 另一个终端查最近的连接失败日志，例如：grep "cannot assign" /var/log/app.log | tail -5
- 如果错误集中爆发的时间点，恰好对应 TIME_WAIT 数飙升到 2.5 万以上，基本可锁定根因
四、顺手排除其他资源干扰
有些“连不上”看着像 TIME_WAIT，其实是别的瓶颈在作祟：
- conntrack 打满：执行 cat /proc/sys/net/netfilter/nf_conntrack_count 和 cat /proc/sys/net/netfilter/nf_conntrack_max，若前者 ÷ 后者 > 0.9，说明连接跟踪表已近饱和
-
进程级文件描述符（FD）耗尽：对出问题的进程 PID，运行 lsof -p
| wc -l ，再对比 ulimit -n，超限会报 too many open files
