服务器 TCP 连接 TIME_WAIT 堆积：ss 排查与内核参数调优

线上服务突然建连失败，ss 一看 TIME_WAIT 几万个，这种故障我碰到过两次，排查套路固定下来了：

1. 先量化
ss -s 看总体，ss -tan state time-wait | wc -l 看数量，再按对端 IP 聚合看是哪些 IP 在贡献。端口耗尽往往是某个上游在疯狂短连接。

2. 找根因
TIME_WAIT 是主动关闭方的“分手冷静期”（2MSL，默认 60 秒）。高频短连接 + 每次都由本机主动 close = 堆积。常见元凶：没开 keepalive 的 API 调用、爬虫、压测脚本。

3. 调优三板斧
业务侧优先：连接池、HTTP keepalive、长连接，能少建连就少建连。
内核侧：net.ipv4.tcp_tw_reuse=1（允许复用 TIME_WAIT 的 socket 建新连接，NAT 环境慎用），net.ipv4.tcp_fin_timeout 调小（默认 60s，可降到 30s），net.ipv4.ip_local_port_range 扩大端口范围。
注意：tcp_tw_recycle 在新内核已移除，别再抄老博客了。

4. 验证
改完压测观察 ss 计数曲线，确认业务 RT 没劣化。

你们线上 TIME_WAIT 最高到过多少？最后是调内核还是改业务解决的？

TIME_WAIT 排查顺序赞同。补充两处容易误判的：

1. 先分清「本机是主动关闭方还是被动」：被动关闭方不会堆积大量 TIME_WAIT。用 ss -tan 看本地端口分布，再决定是改本机还是让对端复用连接。
2. tcp_tw_reuse 在 NAT/负载均衡后面要特别谨慎，四元组复用可能导致旧连接残留影响；优先把业务改成连接池/keepalive，内核参数当辅。
3. 端口耗尽时看 ip_local_port_range 的同时，确认是否开启了过多的源地址（多网卡/策略路由）导致实际可用四元组变少。
4. 压测脚本默认短连接是常见元凶——回归测试环境先开 keepalive，以免「压测假故障」混进线上结论。

我们更建议把「TIME_WAIT 速率」和「connect 失败率」做成同源仪表盘，只看瞬时存量容易被吓到。你们最高水位大概到过什么量级？