大量 TIME_WAIT 的原因与处理

服务器上冒出几万个 TIME_WAIT，说明本机在大量主动关闭短连接。它不是故障，但持续累积会掏空端口和连接资源，值得弄清来龙去脉。网关和反向代理机上尤其常见，因为它们每天都在替业务新建出站连接。 为什么会有这么多 TIME_WAIT？ TIME_WAIT 是 TCP 主动关闭方在连接关闭后停留约 60 秒（2MSL 时长）的状态，作用是让迟到的旧报文自然失效，它的存在是协议设计的一部分，数量本身不是原罪，失控才是。谁主动断得多，谁身上的 TIME_WAIT 就多：主动关闭的一方进 TIME_WAIT，被动关闭的一方直接释放，所以告警常落在主动断开的一侧。典型来源：每次请求都新建连接的调用方——脚本里裸用 curl 循环调接口、客户端没开连接池、健康检查频率过高。 怎么确认来源？ ss -ant state time-wait | wc -l 看总量；ss -ant 按对端地址聚合，看连接都涌向哪个端口，通常能直接锁定是哪个服务被高频调用；ss -s 给出总体汇总。方向也要看：出站连接多说明是下游被高频调用，入站多说明是调用方没复用连接，处置手法不同。按分钟采样一次，画出趋势，风暴是持续的还是周期性的，一目了然。顺带看一眼 CLOSE_WAIT 的数量，它堆积是另一回事，说明本应用没有及时调用关闭，别混为一谈。 内核参数怎么缓解？ net.ipv4.tcp_tw_reuse=1 允许作为客户端时复用 TIME_WAIT 的端口，配合 net.ipv4.ip_local_port_range="10240 65000" 扩大临时端口范围。先用 sysctl -w 临时改，验证有效再写进 /etc/sysctl.conf 固化。注意老资料里的 tcp_tw_recycle 已在内核 4.12 之后移除，NAT 环境下还会造成诡异丢包，别再往配置里抄。 怎么根治？ 应用侧上连接池或改长连接：HTTP 客户端开启 keepalive，数据库驱动配好连接池，内部调用尽量走长连接。连接池要有上限和回收策略，配得太大只是把堆积从客户端挪到服务端。参数只能续命，改造有周期，两边不冲突：参数先行顶住，代码跟上收尾，复用连接才是解。