Linux TIME_WAIT 连接过多的解决思路

大量TIME_WaiT会耗尽端口并占用内存，导致“Cannot assign requested address”等错误；根本解法是应用层复用连接（如http Keep-Alive、连接池），而非仅依赖内核参数调优。

为什么大量 TIME_WAIT 会成为问题

TIME_WAIT 是 TCP 连接关闭时主动关闭方进入的最终状态，持续 2×MSL（通常为 60 秒）。它保证旧连接的延迟报文不会干扰新连接。但当短连接高频发起（如 HTTP 短连接服务、爬虫、负载均衡后端），netstat -ant | grep TIME_WAIT | wc -l 可能轻易突破几万，导致：

• 占用大量本地端口（默认 32768–65535），引发 Cannot assign requested address
• 内核 socket 结构体消耗内存上升，影响性能
• 并非“连接泄漏”，但会掩盖真实连接管理缺陷

调整内核参数能否直接解决

可以缓解，但不能根治；盲目调小可能引发数据错乱。关键参数有：

• net.ipv4.tcp_tw_reuse：设为 1 允许将 TIME_WAIT socket 用于新连接（仅当时间戳启用且新 SYN 时间戳更大时安全）
• net.ipv4.tcp_tw_recycle：已从 linux 4.12+ 移除，禁用——在 NAT 环境下会导致连接失败
• net.ipv4.ip_local_port_range：可扩为 1024 65535 增加可用端口数
• net.ipv4.tcp_fin_timeout：不控制 TIME_WAIT 时长，无效

生效方式：

sysctl -w net.ipv4.tcp_tw_reuse=1

，并写入 /etc/sysctl.conf

应用层更有效的应对方式

根本解法是减少短连接频次，而非硬扛 TIME_WAIT：

• 使用 HTTP Keep-Alive（客户端和服务端均开启），复用连接
• 客户端启用连接池（如 python 的 requests.session()、go 的 http.DefaultClient 复用 Transport）
• 服务端避免频繁 close()，尤其在反向代理（nginx）场景中，检查 proxy_http_version 1.1 和 proxy_set_header Connection ''
• 若必须短连接，考虑让客户端（而非服务端）主动关闭，把 TIME_WAIT 压到客户端侧

如何确认是不是真有问题

别只看 TIME_WAIT 数量。先查：

• ss -s 查总 socket 统计，关注 inuse 和 orphan 是否异常高
• cat /proc/net/sockstat 看 sockets: used 和 TCP: 行
• 应用是否真的报错？比如 connect() failed: Cannot assign requested address 或日志里大量 Connection refused（端口耗尽典型表现）
• 检查 netstat -ant | awk '$6 == "TIME_WAIT" {print $4}' | cut -d: -f2 | sort | uniq -c | sort -n，看是否集中在少数本地端口段——可能是某进程未复用连接

TIME_WAIT 本身是协议设计的必要状态，真正要警惕的是“没做连接复用却幻想靠调参扛住百万请求”这种思路。