Linux 上排查端口占用与 TIME_WAIT 堆积的完整思路

端口被占用这类问题看似简单，但实际排查时经常卡在「知道端口在用，不知道怎么找出来」这一步。这篇整理一套我常用的顺序。

一、先确认是监听还是连接占用

很多人直接 lsof -i:8080，但这个命令在容器 / 无 lsof 的精简镜像里往往不可用。更可靠的是 ss：

ss -lntp | grep :8080        # 只看 LISTEN
ss -antp | grep :8080        # 所有状态
ss -antp state time-wait | wc -l   # TIME_WAIT 数量

关键区别：LISTEN 是被进程占着，TIME_WAIT 是连接关闭后的正常残留。前者要杀进程，后者只能等（或调内核参数）。

二、进程找不到时看 cgroup 与 netns

如果 ss -lntp 显示端口在监听但进程信息为空，说明那个进程不在当前网络命名空间里——典型是容器。这时要进容器的 netns 看：

ls -l /proc/<pid>/ns/net
nsenter -t <pid> -n ss -lntp

三、TIME_WAIT 堆积怎么处理

短连接高并发场景下 TIME_WAIT 上千是正常的，几万才需要处理。三个参数按需调：

sysctl -w net.ipv4.tcp_tw_reuse=1          # 允许复用 TIME_WAIT 的连接（仅出向）
sysctl -w net.ipv4.tcp_fin_timeout=30      # 缩短 FIN_WAIT2
sysctl -w net.ipv4.ip_local_port_range="10000 65000"   # 扩大可用端口范围

注意 tcp_tw_recycle 在 4.12 之后已被移除，网上老文章还在教这个参数的直接忽略，开了会破坏 NAT 后面的客户端连接。

四、根治还是靠连接复用

参数调优只是缓解。如果发现 TIME_WAIT 持续增长，真正的解法是改用长连接或连接池：HTTP 侧开 keep-alive，数据库侧用连接池，RPC 侧复用 channel。这些改动的收益远大于调内核参数。

五、一个容易忽略的点

/proc/sys/net/ipv4/tcp_max_tw_buckets 是 TIME_WAIT 的硬上限，超过会直接丢弃并打日志。如果看到 TCP: time wait bucket table overflow，说明已经撞上限了，这时候连接失败会比慢更让人困惑。