端口被TIME_WAIT占用本质是临时端口池耗尽；需四步排查：一查ss -s中TIME_WAIT占比及是否逼近ip_local_port_range上限，二用dmesg确认内核是否报“time wait bucket table overflow”，三比对业务错误日志与TIME_WAIT峰值时间同步性，四排除conntrack和FD耗尽干扰。
端口被 TIME_WAIT 占用，本质不是“被占住”，而是本机临时端口池快用光了——因为大量短连接快速关闭后，端口卡在 TIME_WAIT 状态（默认约 60 秒），无法立即分配给新连接。真正要查的，是它是否已导致 connect: cannot assign requested address 这类错误。排查不能只看数量，得从现象出发，分步验证。
一、确认当前 TIME_WAIT 是否逼近端口上限
先别数总数，看比例和余量：
- 执行
ss -s，关注输出中timewait行数值，以及total连接数。若 timewait 占比超 70% 且绝对值持续 >25000，需警惕 - 查本地可用端口范围：
cat /proc/sys/net/ipv4/ip_local_port_range（默认是32768 60999，共约 28232 个） - 统计实际 TIME_WAIT 数：
ss -ant state time-wait | wc -l。如果结果接近或超过上面的上限值，端口池就实质性紧张了
二、检查内核是否已开始丢弃连接
端口真耗尽时，Linux 内核会静默丢包，并留下明确日志信号：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 运行
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：实时监控 TIME_WAIT 变化：
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 和文件描述符干扰
有些“连不上”表象相似，但根源不同：
-
conntrack 打满（常见于 K8s 节点、NAT 网关）：
cat /proc/sys/net/netfilter/nf_conntrack_count÷cat /proc/sys/net/netfilter/nf_conntrack_max> 0.9，就得调大 -
进程 FD 耗尽：
lsof -p <pid> | wc -l</pid>对比ulimit -n，超限会报too many open files - 只有排除这两类，才能把问题干净归到 TCP 短连接模型和端口复用机制上
