Linux服务器出现大量TIME_WAIT怎么办？连接状态、端口耗尽与内核参数排查教程

Linux服务器上出现几千甚至几万个 TIME_WAIT，不等于服务器已经发生故障。它是 TCP 正常关闭连接时的一种状态，用来避免旧连接中的延迟报文干扰后续新连接。

需要处理的情况主要有两类：短连接数量异常增加，给应用、负载均衡器或上游服务带来额外开销；本机临时端口接近耗尽，应用开始出现连接失败、超时或 Cannot assign requested address。排查时应先确认业务影响，再找出连接方向和主动关闭连接的一方，最后才考虑调整程序、连接池或内核参数。

一、TIME_WAIT是什么，为什么会出现

TCP连接完成数据传输后，需要经过挥手过程关闭。主动关闭连接的一方通常会进入 TIME_WAIT，并等待一段时间后释放该连接状态。

这段等待有两个主要作用：

• 让网络中可能延迟到达的旧报文失效，避免影响使用相同四元组建立的新连接。
• 如果关闭阶段的最后一个确认报文丢失，仍能处理对端重传的关闭报文。

因此，Web服务器、反向代理、API网关、爬虫、监控程序或调用大量上游接口的应用，都可能出现较多 TIME_WAIT。数量高低本身不能直接说明性能好坏，必须结合连接增长速度、端口范围和业务错误判断。

还要注意一点：TIME_WAIT通常已经不再占用应用进程的文件描述符，但仍由内核保存连接状态，并受本地端口和TCP四元组复用条件限制。把它和“进程打开文件数过多”混为一谈，容易把排查方向带偏。

二、先确认TIME_WAIT是否真的影响业务

1. 查看TCP总体状态

先用 ss -s 查看当前TCP连接概况：

ss -s

再单独统计 TIME_WAIT：

ss -tanH state time-wait | wc -l

如果服务器流量和请求量正在上升，TIME_WAIT同步增加后又能稳定回落，通常属于正常现象。更值得警惕的是数量持续上涨，同时伴随接口超时、上游连接失败、CPU软中断升高或应用错误日志增加。

2. 连续观察变化趋势

单次截图无法说明问题。可以每隔两秒观察一次：

watch -n 2 'ss -tanH state time-wait | wc -l'

重点看三个变化：

• 请求停止后，数量是否能逐步下降。
• 业务高峰期，数量是否持续增加而不回落。
• 报错发生时，TIME_WAIT、已建立连接和新建连接是否同时异常。

3. 检查本地临时端口范围

主动向外建立连接时，系统通常会从本地临时端口范围中选择端口：

cat /proc/sys/net/ipv4/ip_local_port_range

也可以使用：

sysctl net.ipv4.ip_local_port_range

不要只用 TIME_WAIT总数和端口范围做简单减法。TCP连接是否冲突还与源地址、源端口、目标地址和目标端口组成的四元组有关。不过，当单个源IP频繁访问同一个目标IP和端口时，本地端口范围会成为重要限制。

三、判断是谁产生了大量短连接

1. 查看本地端口和对端地址

列出部分 TIME_WAIT连接：

ss -tan state time-wait | head -n 30

不显示表头时，可以使用：

ss -tanH state time-wait | head -n 30

输出中的本地地址和对端地址能帮助判断连接方向。如果本地端口大量集中在 80、443等服务端口，说明这些连接可能来自访问本机网站的客户端；如果本地端口主要是高位临时端口，而对端集中在固定的数据库、缓存、API或代理端口，通常是本机程序在频繁发起外连。

2. 统计最常见的对端

下面的命令适合快速找出连接最集中的对端地址和端口：

ss -tanH state time-wait \
  | awk '{print $5}' \
  | sort \
  | uniq -c \
  | sort -nr \
  | head -n 20

如果系统的 ss输出格式经过定制，先执行一条命令确认列位置，再使用 awk统计，避免把本地地址和对端地址弄反。

3. 按服务端口筛选

检查本机Web服务端口：

ss -tanH state time-wait '( sport = :80 or sport = :443 )' | head

检查连接到上游HTTPS服务的连接：

ss -tanH state time-wait '( dport = :443 )' | head

如果大量连接来自Nginx、应用服务器或任务程序访问同一个上游，应继续检查该程序是否启用了长连接和连接池。直接修改系统参数通常解决不了短连接持续产生的问题。

四、常见原因与处理方法

1. HTTP长连接没有生效

反向代理或应用每处理一次请求就重新建立TCP连接，会迅速产生短连接。常见问题包括：

• 客户端没有复用HTTP连接。
• Nginx到上游服务没有正确使用Keep-Alive。
• 应用HTTP客户端每次请求都新建实例，没有复用连接池。
• 上游主动返回 Connection: close，或连接被中间代理提前关闭。

处理时应查看Nginx配置、应用HTTP客户端设置和上游响应头。连接池的最大连接数、空闲连接数和空闲超时也要与实际并发匹配，不能只把Keep-Alive打开就结束。

2. 数据库或缓存连接池配置不合理

应用频繁创建并关闭MySQL、PostgreSQL、Redis等连接，也会产生明显的连接波动。检查应用日志和连接池指标，确认是否存在以下情况：

• 每个请求单独创建数据库连接。
• 连接池上限过小，连接不断销毁重建。
• 空闲连接回收时间过短。
• 健康检查或定时任务高频建立连接。

数据库连接池参数应根据应用实例数、数据库最大连接数和实际并发统一计算。只增大某一个应用实例的连接池，可能把压力转移到数据库。

3. 健康检查、监控或爬虫频率过高

负载均衡健康检查、容器探针、监控采集和站内爬虫都可能制造稳定的短连接。可以按对端IP、目标端口和时间规律确认来源，再调整检查间隔、复用连接或减少重复探测。

4. NAT或代理出口过于集中

大量应用实例通过同一个源IP访问同一个目标服务时，临时端口压力会集中到出口节点。此时应用服务器上的连接数可能不夸张，但NAT网关、代理服务器或出口负载均衡器已经接近容量上限。

处理思路包括增加出口IP、分散目标节点、启用连接复用，并核对云厂商对NAT并发连接和端口分配的限制。云产品的具体限制会变化，应以当前控制台和官方文档为准。

五、内核参数能不能直接改

1. tcp_tw_reuse

Linux内核提供 net.ipv4.tcp_tw_reuse，用于在协议安全条件满足时复用 TIME_WAIT连接。当前内核文档列出的取值为：0表示关闭，1表示全局启用，2表示只对回环流量启用；文档当前标注的默认值是 2。发行版、内核版本和网络命名空间配置可能不同，仍应以本机结果为准：

uname -r
sysctl net.ipv4.tcp_tw_reuse

Linux内核文档明确提醒，不应在缺少专业评估的情况下修改该参数。尤其不要把“减少TIME_WAIT数量”当成唯一目标。连接建立失败的根因如果是应用没有使用连接池、上游响应慢或NAT出口容量不足，调整该参数只能暂时掩盖问题。

如确需测试，应先记录原值，在隔离或低风险环境中验证连接成功率、异常重传和回滚效果。确认适合当前内核和网络场景后，再决定是否写入专用的 /etc/sysctl.d/*.conf文件。

2. 不要使用tcp_tw_recycle

一些旧文章会建议开启 net.ipv4.tcp_tw_recycle。该参数早已从Linux内核中移除，而且在NAT网络中曾造成严重的连接兼容问题。新系统找不到这个参数是正常的，不应尝试通过其他方式恢复它。

3. 扩大临时端口范围要有边界

如果已经确认是本机主动外连导致临时端口紧张，可以评估调整 ip_local_port_range。修改前要检查现有范围、保留端口和业务监听端口，防止冲突：

sysctl net.ipv4.ip_local_port_range
sysctl net.ipv4.ip_local_reserved_ports

参数修改应配合连接池、长连接、出口IP和上游架构一起评估。单纯扩大范围，会延后端口耗尽，但不会减少短连接的创建成本。

六、推荐的排查顺序

遇到大量 TIME_WAIT时，可以按以下顺序处理：

1. 用 ss -s和 ss -tanH state time-wait确认数量与变化趋势。
2. 对照应用错误日志，确认是否真的出现连接失败、超时或端口分配错误。
3. 查看本地地址、服务端口和对端地址，判断连接方向。
4. 找出产生短连接的应用、上游服务、健康检查或出口节点。
5. 优先修复HTTP长连接、数据库连接池和频繁重连问题。
6. 核对临时端口范围、NAT容量和出口IP分布。
7. 最后才评估 tcp_tw_reuse等内核参数，并准备回滚。

七、排查时容易犯的错误

• 看到数量多就立即清理或重启服务器。重启只能暂时让计数归零，业务恢复后还会再次出现。
• 把 TIME_WAIT当成进程文件描述符泄漏。两者可能同时存在，需要分别检查连接状态和进程打开的文件描述符。
• 只看总数，不看本地端口和对端地址。连接方向决定了应该检查客户端、服务端还是代理出口。
• 复制年代久远的 sysctl优化清单。内核参数的含义、默认值和可用性会变化。
• 为了降低计数缩短所有超时。过度激进的超时设置可能增加重试和断连，反而制造更多连接。

总结

TIME_WAIT是TCP正常关闭机制的一部分。服务器上数量较多时，先确认业务是否出现连接失败，再通过 ss判断连接方向和集中对端。大多数实际问题来自短连接过多、连接池没有复用、健康检查频率过高或NAT出口集中。

内核参数属于最后的调节手段。先减少不必要的连接创建，再评估临时端口和复用策略，通常比直接套用优化参数更稳妥。

参考资料

• • IETF RFC 9293：Transmission Control Protocol (TCP)

https://www.rfc-editor.org/rfc/rfc9293.html

• • Linux Kernel Documentation：IP Sysctl

https://docs.kernel.org/networking/ip-sysctl.html

• • Linux man-pages：ss(8)

https://man7.org/linux/man-pages/man8/ss.8.html

• • Linux man-pages：tcp(7)

https://man7.org/linux/man-pages/man7/tcp.7.html

核验日期：2026年8月27日