Linux 服务器 TCP 连接 TIME_WAIT 过多时，优先检查应用程序连接池配置，其次再通过内核参数 net.ipv4.tcp_tw_reuse 允许重用 TIME_WAIT socket。修改内核参数前需确认服务器是否处于 NAT 环境，避免启用已废弃的 net.ipv4.tcp_tw_recycle 导致连接故障。
先说结论：TIME_WAIT 过多通常表明主动关闭连接的一方端口耗尽风险，优化核心在于减少主动关闭频率或加快端口复用。
- 先定位：使用 ss 命令确认 TIME_WAIT 数量及所属进程，区分是服务器主动关闭还是客户端主动关闭。
- 先做：优先调整应用程序保持长连接，其次开启 net.ipv4.tcp_tw_reuse，严禁开启 net.ipv4.tcp_tw_recycle。
- 再验证：观察 TIME_WAIT 数量是否下降，同时监控新连接建立是否有报错。
命令速用版
以下命令用于快速查看 TIME_WAIT 数量及当前内核参数配置：
ss -ant | grep TIME_WAIT | wc -l
sysctl net.ipv4.tcp_tw_reuse
sysctl net.ipv4.ip_local_port_range为什么会这样
TIME_WAIT 状态出现在主动关闭 TCP 连接的一方，目的是确保网络中残留的旧数据包消失。
Linux 默认保留时间为 2MSL（Maximum Segment Lifetime），通常为 60 秒。高并发场景下，如果服务器频繁主动关闭连接，临时端口会被 TIME_WAIT 状态占用，导致无法建立新连接。公开资料中没有看到可靠的量化数据说明具体多少数量算过多，通常取决于端口范围大小和并发请求频率。
分步处理
按照以下顺序操作，每一步操作后需观察系统反应：
- 检查当前状态：执行
ss -ant | grep TIME_WAIT | wc -l。如果数量持续接近可用端口上限，需要干预。 - 开启端口复用：执行
sysctl -w net.ipv4.tcp_tw_reuse=1。该参数允许将 TIME_WAIT sockets 重新用于新的 TCP 连接，前提是新的时间戳符合规则。 - 扩大本地端口范围：执行
sysctl -w net.ipv4.ip_local_port_range="1024 65535"。增加可用端口数量可延缓耗尽时间。 - 应用程序优化：检查代码是否频繁短连接，改为 HTTP Keep-Alive 或数据库连接池。
怎么验证是否生效
执行ss -ant | grep TIME_WAIT | wc -l观察数量是否稳定或下降。同时监控应用日志，确认没有出现"Cannot assign requested address"错误。
常见坑
- net.ipv4.tcp_tw_recycle 已废弃：Linux 4.12 内核后移除该参数。在 NAT 环境下开启会导致连接失败，严禁使用。
- tcp_tw_reuse 依赖时间戳：如果客户端不支持 TCP 时间戳选项，reuse 可能不生效。
- 持久化配置：命令行修改重启失效，需写入
/etc/sysctl.conf文件。
常见问题
TIME_WAIT 过多一定会影响性能吗？
不一定。只要可用端口未耗尽且无连接报错，TIME_WAIT 本身是 TCP 协议正常机制，无需优化。
可以减少 2MSL 等待时间吗？
不建议。修改 MSL 值违反 TCP 协议规范，可能导致旧数据包干扰新连接，标准做法是复用端口而非缩短等待。
负载均衡后端服务器需要优化吗？
需要。如果负载均衡器配置为短连接，后端服务器会处于被动关闭状态，产生大量 TIME_WAIT，需在负载均衡层开启长连接。