真正要查的是端口耗尽与连接失败，排查分四步：一查端口余量（ip_local_port_range与ss统计），二查内核丢包日志（dmesg或kern.log），三验业务错误与TIME_WAIT峰值是否同步，四排除conntrack和文件描述符干扰。
大量 TIME_WAIT 本身不是问题，真正要查的是它是否已导致端口耗尽、连接失败。排查必须从现象出发，三步快速定位：看连接分布、查端口余量、验错误同步性。
一、确认是否真压垮了端口池
别只数数量。先查本地可用端口范围：
- cat /proc/sys/net/ipv4/ip_local_port_range —— 默认是 32768 60999（约 28232 个端口）
- ss -ant state time-wait | wc -l —— 如果持续 ≥ 25000，端口就快见底了
- ss -s —— 关注输出中 timewait 占 total 连接数是否超 70%，且数值长期高于 25000
二、检查内核是否已开始丢弃连接
端口真正耗尽时，内核会静默丢包，并留下关键日志：
- dmesg | grep "time wait bucket\|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 峰值同步
打开两个终端并行观察：
- 终端1：watch -n 1 'ss -ant state time-wait | wc -l'
- 终端2：查最近报错时间点，例如 grep "cannot assign" /var/log/app.log | tail -5
如果错误集中爆发的时间段，和 TIME_WAIT 数飙升到 2.5 万以上完全重合，基本可锁定根因。
四、顺手排除 conntrack 和文件描述符干扰
有些“连不上”看着像 TIME_WAIT，其实是别的资源卡住了：
- cat /proc/sys/net/netfilter/nf_conntrack_count 和 cat /proc/sys/net/netfilter/nf_conntrack_max —— 若前者 ÷ 后者 > 0.9，conntrack 已打满
- lsof -p <PID> | wc -l 对比该进程的 ulimit -n —— 超限会报 too many open files
只有排除这两类，才能把问题干净地归到 TCP 短连接模型和端口复用机制上。
