ss与netstat实战指南：一分钟快速诊断TCP连接问题

时间：2026-05-16 19:00

线上服务响应突然变慢，不报错，日志也干净，CPU和内存都正常。这种“隐形”的网络问题最让人头疼。记得有一次排查，折腾了半天，最后是一条命令直接锁定了病灶： ss -antp | grep CLOSE_WAIT | wc -l 输出结果是4096。四千多个CLOSE_WAIT状态连接，典型的连接泄漏

线上服务响应突然变慢，不报错，日志也干净，CPU和内存都正常。这种“隐形”的网络问题最让人头疼。

记得有一次排查，折腾了半天，最后是一条命令直接锁定了病灶：

ss -antp | grep CLOSE_WAIT | wc -l

输出结果是4096。四千多个CLOSE_WAIT状态连接，典型的连接泄漏，文件描述符快被耗尽了。

这就是ss和netstat这类网络工具的核心价值——它们像系统的听诊器，无需加日志、无需重启服务，一条命令就能把当前所有TCP连接的状态全景呈现出来，问题往往一目了然。

这篇文章，我们就从原理到实战，把这两个工具彻底讲清楚，让你下次再遇到网络问题，心里有谱，手里有招。

一、先把 TCP 状态搞清楚

工具用起来简单，但看懂输出，得先理解TCP连接状态机。这就像看心电图，得先知道每个波形代表什么。

上图描绘了常见状态，这里补充几个关键解释：

三次握手（建立连接）：

客户端发送SYN → 进入SYN_SENT状态。
服务端收到，回复SYN+ACK → 进入SYN_RCVD状态。
客户端再回复ACK → 双方都进入ESTABLISHED状态，连接建立完成。

四次挥手（关闭连接）：

主动关闭方发送FIN → 进入FIN_WAIT_1状态。
对方回复ACK → 主动关闭方进入FIN_WAIT_2状态（此时对方仍可发送数据）。
对方数据发完后，发送FIN → 主动关闭方进入TIME_WAIT状态，被动方进入LAST_ACK状态。
主动关闭方回复ACK → 等待2MSL时间后彻底关闭。

对于排查来说，不必记住所有状态，重点关注这几个就足以解决90%的问题：ESTABLISHED（已建立）、CLOSE_WAIT（等待关闭）、TIME_WAIT（时间等待）、LISTEN（监听）。

二、netstat vs ss：用哪个？

很多资料对这两个工具混用，这里明确一下：

netstat：老牌工具，几乎全系统通用，功能全面。但它的缺点是慢，尤其在连接数多的时候，因为它需要读取/proc/net/tcp文件并逐个解析。
ss (socket statistics)：新工具，直接读取内核的netlink接口获取信息，速度极快，即使面对十万级连接也能秒出结果。

结论很明确：优先使用ss。只有在没有ss的环境下，再退而求其次使用netstat。两者的常用参数基本可以一一对应。

三、最常用的几条命令

1. 查看所有 TCP 连接

# ss（推荐）
ss -antp
# netstat（备用）
netstat -antp

参数说明：-a显示所有连接，-n以数字形式显示地址和端口（不解析域名，更快），-t仅显示TCP连接，-p显示关联的进程信息。

典型输出如下：

State    Recv-Q Send-Q Local Address:Port  Peer Address:Port  Process
LISTEN   0      128    0.0.0.0:8080        0.0.0.0:*          users:(("myapp",pid=1234))
ESTAB    0      0      10.0.0.1:8080       10.0.0.2:54321     users:(("myapp",pid=1234))
TIME-WAIT 0     0      10.0.0.1:8080       10.0.0.3:54322

有几个字段需要特别注意：

Recv-Q：接收缓冲区中积压的字节数。在LISTEN状态下，这个值表示等待被accept()的连接数。如果持续不为0，说明应用处理新连接的速度跟不上。
Send-Q：发送缓冲区中积压的字节数。如果持续不为0，通常意味着对端接收数据较慢。

2. 统计各状态连接数（最常用）

ss -ant | awk 'NR>1 {print $1}' | sort | uniq -c | sort -rn

输出类似这样：

4096 CLOSE-WAIT
  256 ESTABLISHED
   12 TIME-WAIT
    1 LISTEN

哪个状态异常，一眼就能看出来。

3. 查看特定端口的连接

# 查看本地 8080 端口的所有连接
ss -antp sport = :8080
# 查看连接到某个远端 IP 的所有连接
ss -antp dst 10.0.0.2

4. 筛选特定状态的连接

# 只看已建立的连接
ss -antp state established
# 只看 CLOSE_WAIT（排查连接泄漏必用）
ss -antp state close-wait
# 只看 TIME_WAIT
ss -antp state time-wait

5. 统计模式：快速查看连接摘要

# 查看连接统计摘要
ss -s

输出：

Total: 1024
TCP:   512 (estab 256, closed 200, orphaned 12, timewait 44)

四、图解：三种最常见的异常场景

这是线上最高频的三种TCP问题，看图就能快速理解其成因和影响。

五、三个真实排查场景，手把手过一遍

1. 场景一：CLOSE_WAIT堆积——连接泄漏

症状：服务运行一段时间后变慢，日志无报错，重启后恢复，但不久后问题重现。

首先用统计命令看状态分布：

ss -ant | awk 'NR>1{print $1}' | sort | uniq -c | sort -rn

输出显示大量CLOSE_WAIT：

3847 CLOSE-WAIT
  128 ESTABLISHED
    1 LISTEN

接着定位具体进程：

ss -antp state close-wait | head -20

找到对应的端口和进程名，去检查代码，很可能会发现：在某个异常处理路径中，连接使用后没有在finally块中正确关闭。

本质：CLOSE_WAIT表示对方（主动关闭方）已经发送了FIN包，告知“我说完了”，但本地的应用程序没有调用close()系统调用来响应。于是这个连接就一直挂在这里，占用着一个文件描述符。当泄漏的连接数达到ulimit -n设置的上限时，新的连接就无法建立了。

解决：确保连接资源被正确释放，使用try-with-resources（Ja va）或确保在finally块中关闭连接，不要依赖垃圾回收。

2. 场景二：TIME_WAIT过多——本地端口耗尽

症状：高并发压测一段时间后，新连接建立失败，报错“Cannot assign requested address”。

使用统计摘要命令：

ss -s

输出显示巨量的TIME_WAIT：

Total: 65280
TCP:   62000 (estab 200, closed 61500, timewait 61200)

六万多个TIME_WAIT！系统默认的临时端口范围通常是32768~60999，只有两万多个可用端口，显然早已耗尽。

本质：TIME_WAIT是TCP四次挥手中，主动关闭连接的一方会进入的正常状态。它会等待2倍的最大报文段生存时间（2MSL，通常为60秒），目的是让网络中可能残留的旧连接数据包彻底消散，防止干扰新连接。

在短连接高并发的场景下（例如使用HTTP/1.0且未启用Keep-Alive），会快速产生大量TIME_WAIT连接。

应对方案：

开启长连接：使用HTTP Keep-Alive，这是最根本的解决方案。
启用tcp_tw_reuse：允许新的连接复用处于TIME_WAIT状态的端口（需谨慎，确保安全）。
```
sysctl -w net.ipv4.tcp_tw_reuse=1
```

扩大本地端口范围：

sysctl -w net.ipv4.ip_local_port_range="1024 65535"

3. 场景三：Recv-Q 不为零——accept 队列积压

症状：服务端CPU不高，但客户端频繁出现连接超时。

查看监听端口的队列情况：

ss -antp | grep LISTEN

输出显示Recv-Q已经达到了backlog的上限（这里是128）：

State   Recv-Q  Send-Q  Local Address:Port
LISTEN  128     128     0.0.0.0:8080

在LISTEN状态下，Recv-Q表示已完成三次握手、等待应用调用accept()取走的连接数。当这个值达到backlog上限时，内核会直接丢弃新的连接请求，客户端看到的就是连接超时。

这通常是因为应用处理连接的线程池太小，或者accept()之后的业务处理太慢，导致队列积压。

可以先调大backlog应急：

sysctl -w net.core.somaxconn=65535

但根本的解决方法是：扩大处理线程或协程池，或者对处理逻辑进行异步化改造，提升消费能力。

六、常用命令速查

# 查看所有 TCP 连接（推荐加 -n，速度快）
ss -antp

# 统计各状态连接数量
ss -ant | awk 'NR>1{print $1}' | sort | uniq -c | sort -rn

# 只看 CLOSE_WAIT（排查连接泄漏）
ss -antp state close-wait

# 只看 TIME_WAIT（排查端口耗尽）
ss -antp state time-wait

# 只看 ESTABLISHED（当前活跃连接）
ss -antp state established

# 查看某个端口的连接情况
ss -antp sport = :8080

# 查看连接到某个目标 IP 的连接
ss -antp dst 10.0.0.2

# 实时监控连接数变化（每秒刷新）
watch -n 1 'ss -s'

# 查看 LISTEN 状态的 Recv-Q（是否积压）
ss -antp | grep LISTEN

# 综合统计（类似 netstat -s）
ss -s

七、ss 和 netstat 常用参数对照

结论依然是：ss更快、更灵活，其state过滤功能是独有的，强烈建议切换到ss。

八、和 strace 配合使用

有时候仅看连接状态还不够。例如，发现大量CLOSE_WAIT，但不确定具体是哪段代码没有关闭连接。这时可以配合strace：

# 先用 ss 找到问题进程的 PID
ss -antp state close-wait | grep myapp

# 再用 strace 追踪这个进程的系统调用，观察 close(fd) 是否被调用
strace -p  -e trace=close,shutdown

ss展示的是连接状态的“结果”，strace展示的是系统调用的“过程”。两者配合，定位问题效率倍增。

九、写在最后

遇到网络问题，先别急着改配置、翻代码。记住这个“万能起手式”：

ss -ant | awk 'NR>1{print $1}' | sort | uniq -c | sort -rn

先跑一下这条命令，看看各个TCP状态的分布情况。80%的问题，到这里就已经有了明确的排查方向：

CLOSE_WAIT多 → 大概率是代码里连接没关，重点检查close()调用。
TIME_WAIT多 → 短连接太频繁，考虑启用长连接或调整内核参数。
LISTEN 状态的 Recv-Q > 0 → accept处理跟不上，需要扩容线程或调整backlog。

工具终究是手段，对TCP状态机原理的理解才是根本。知道每个状态代表什么，工具的输出在你眼里就不再是冰冷的字符串，而是一幅生动的网络连接拓扑图。

来源：https://www.51cto.com/article/842420.html

网络

上一篇适马85mm F1.4 DG DN L卡口大光圈人像镜头售价4599元 下一篇Ping不通但curl能正常访问的原因与解决方法详解

本站内容用于信息整理与展示，如有侵权或内容问题请及时联系处理。