TIME_WaiT只出现在主动发送FIN的一方，由TCP协议规定而非配置错误；其持续60秒不可修改，高并发短连接会导致端口耗尽，应优先通过长连接和合理超时设置优化，而非盲目启用tcp_tw_reuse或已废弃的tcp_tw_recycle。
TIME_WAIT 为什么总在客户端（主动关闭方）出现
因为只有发起 FIN 的那一端才会进入 TIME_WAIT 状态——这是 TCP 协议设计决定的，不是配置错误或 bug。比如 nginx 作为服务端被客户端（curl、浏览器）断开时，TIME_WAIT 出现在客户端机器上；但若 Nginx 主动关闭后端连接（如 upstream 超时），那 TIME_WAIT 就出现在 Nginx 所在服务器上。
常见误解是“服务端 TIME_WAIT 多 = 配置差”，其实关键看谁发了第一个 FIN。可通过 ss -tan state time-wait | head 观察本地端口和对端 IP，确认主动关闭方身份。
高并发短连接场景下 TIME_WAIT 暴增的直接原因
每条主动关闭的连接都会卡住一个本地端口 + 4KB 内存 + 1 个 fd，持续 TCP_TIMEWAIT_LEN（linux 固定为 60 秒）。如果每秒新建 1000 个连接并立即关闭，理论上最多积压 60 × 1000 = 6 万个 TIME_WAIT socket。
- 典型场景：http/1.0 客户端未复用连接、微服务间频繁调用且未启用 keep-alive
- 现象：
ss -s显示time_wait数超 3~5 万，dmesg可能刷出TCP: time wait bucket table overflow - 后果：新连接可能因端口耗尽而失败（
Cannot assign requested address），尤其当net.ipv4.ip_local_port_range范围较窄（如默认32768 60999，仅约 28K 可用端口）时
别乱开 tcp_tw_reuse 和 tcp_tw_recycle
tcp_tw_reuse 在客户端（即 connect() 侧）可安全启用，它允许内核将处于 TIME_WAIT 的端口用于新连接，前提是新连接的时间戳严格大于旧连接的最后时间戳（依赖 PAWS 机制）。但 tcp_tw_recycle 已在 Linux 4.12+ 彻底移除，且早年开启它在 NAT 环境下必然导致连接失败——多个客户端共用一个公网 IP 时，服务端看到的时间戳乱序，直接丢包。
正确做法：
- 客户端（如爬虫、调用方）可设：
echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse - 服务端（如 Web API）**不要开
tcp_tw_recycle**，也**不建议开tcp_tw_reuse**（它只对客户端 connect 有效，服务端 accept 不走这条路） - 真正治本：让客户端用长连接（HTTP Keep-Alive）、服务端合理设置
keepalive_timeout和fin_timeout
你以为改 MSL 就能缩短 TIME_WAIT？Linux 不认账
RFC 建议 MSL=2 分钟，Linux 却硬编码 TCP_TIMEWAIT_LEN 为 60 秒（60*HZ），且**不可通过 sysctl 修改**。网上流传的 net.ipv4.tcp_fin_timeout 只影响 CLOSE_WAIT 等状态的超时，并不改变 TIME_WAIT 时长。
所以试图用以下命令“加速释放”是无效的：
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout # 对 TIME_WAIT 无影响真正可控的只有两点：端口复用（tcp_tw_reuse）、扩大可用端口范围（ip_local_port_range），以及——从应用层减少主动关闭频次。
TIME_WAIT 不是 bug，是 TCP 可靠性的代价。压测时看到几万个 TIME_WAIT 别慌，先确认是否真影响业务；盲目调参反而可能引入 NAT 下丢包、时间戳校验失败等更隐蔽的问题。