TIME_WAIT 是 TCP 四次挥手的必要状态，持续 2MSL（通常 60 秒），用于防止旧报文干扰新连接，并非故障；其本身不消耗性能，真正瓶颈是端口耗尽，尤其在客户端高频短连场景下。
TIME_WAIT 是内核主动设计的保护机制，不是故障
很多人看到 netstat 或 ss -ant | grep TIME_WAIT 显示几千个连接就紧张，以为是泄漏或攻击。其实 TIME_WAIT 是 TCP 四次挥手中客户端（或主动关闭方）必须经历的状态，持续 2×MSS（通常 60 秒），目的是防止旧连接的延迟报文干扰新连接——这是 RFC 793 的强制要求。
关键点在于：TIME_WAIT 本身不消耗内存或 CPU，只占一个 socket 结构体（约 1KB），真正影响性能的是端口耗尽（尤其是作为客户端频繁短连时）。
- 服务器端监听端口固定，
TIME_WAIT多一般不影响服务 - 客户端（如负载均衡、微服务调用方）每秒建连超几百，又没复用连接，才容易触发端口不足（
Cannot assign requested address） -
net.ipv4.ip_local_port_range默认是 32768–65535（约 32K 端口），60 秒内最多支撑约 533 QPS 的短连接
哪些配置能缓解但不能“消除” TIME_WAIT
Linux 提供了几个内核参数，但它们各有前提和副作用，不能无脑调大：
-
net.ipv4.tcp_tw_reuse = 1：允许将处于TIME_WAIT的 socket 重用于**新的 outbound 连接**（仅客户端有效），前提是时间戳（tcp_timestamps=1）开启且新 SYN 的时间戳严格大于旧连接最后的时间戳。对服务端无效 -
net.ipv4.tcp_fin_timeout不影响TIME_WAIT持续时间（那是 2MSL 固定值），它只控制 FIN_WAIT_2 状态超时，别被名字误导 -
net.ipv4.tcp_tw_recycle已在 Linux 4.12+ 彻底移除，且早年启用后在 NAT 环境下会导致连接失败，绝对不要配
真正有效的解法是避开短连接模式
调整内核参数是补救，重构连接模型才是根治。尤其在高并发 HTTP 场景下：
- HTTP/1.1 默认启用
Connection: keep-alive，客户端应复用连接，而不是每个请求都connect()+close() - 使用连接池（如 Go 的
http.Transport.MaxIdleConns、Java 的 Apache HttpClient Pool）控制长连接生命周期 - 服务端避免过早
close()，让客户端决定何时断连；若必须短连，考虑改用 UDP 或 QUIC（如 HTTP/3）绕过 TCP 状态机 - 检查是否误将本该长连的服务（如 Redis、MySQL）配置成每次请求新建连接
排查时优先确认是不是真有问题
运行 ss -s 看汇总统计比数 TIME_WAIT 个数更有意义：total: 12345 (kernel 12345) 中括号里是内核实际管理的 socket 总数，如果远小于 /proc/sys/net/core/somaxconn 和内存容量，基本无需干预。
真正要盯的是错误日志里的：Cannot assign requested address（端口耗尽）、Connection refused（服务未监听）、Connection reset by peer（对方异常断连）——这些才是需要响应的问题。
很多团队花几小时调 tcp_tw_reuse，结果发现只是上游 SDK 默认禁用了连接复用，改一行配置就解决。
