如何在Linux系统中查看网络连接状态？使用netstat和ss命令的详细教程

使用ss和netstat命令可查看linux网络连接状态，其中ss因性能更优成为首选。通过ss -tulnp或netstat -tulnp可查看协议、本地/远程地址、端口、状态及进程信息；ss直接读取内核数据，效率更高，适合高并发场景。常用筛选技巧包括：ss -tulnp | grep ":80"查看特定端口，grep “nginx”定位进程连接，ss -t state established筛选已建立连接。关键状态包括：LISTEN（服务监听）、ESTABLISHED（连接正常）、CLOSE_WaiT（本地未关闭，可能程序缺陷）、TIME_WAIT（主动关闭方等待，防止旧包干扰）。这些状态帮助诊断服务不可达、资源耗尽等问题，是网络排查的核心依据。

在linux系统中，要查看当前的网络连接状态，我们主要依赖两个核心命令：

netstat

和

ss

。它们能帮你快速洞察哪些端口正在监听、哪些连接已经建立、哪些进程正在使用网络资源，是网络故障排查和系统监控的利器。

解决方案

要查看Linux系统的网络连接状态，最直接且常用的方法是结合使用

netstat

和

ss

命令。这两个工具都能提供丰富的网络连接信息，但

ss

在现代Linux系统中通常被认为是更高效、功能更强大的选择。

使用

netstat

命令：

netstat

是一个历史悠久且功能强大的网络工具，它可以显示各种网络相关信息，包括网络连接、路由表、接口统计等。

要查看所有TCP和udp的监听端口和已建立连接，并显示对应的进程ID和程序名称，我通常会这样用：

netstat -tulnp

• -t

  : 显示TCP连接。

• -u

  : 显示UDP连接。

• -l

  : 仅显示监听（Listening）状态的套接字。

• -n

  : 以数字形式显示地址和端口号，而不是尝试解析主机名和服务名，这能加快显示速度。

• -p

  : 显示拥有该套接字的进程ID和程序名称（需要root权限）。

使用

ss

命令：

ss

（socket statistics）是

netstat

的替代品，它属于

iproute2

工具集，在处理大量连接时比

netstat

更快、更高效，因为它直接从内核获取套接字统计信息。

与

netstat

类似，查看所有TCP和UDP的监听端口和已建立连接，并显示对应的进程ID和程序名称，我会用：

ss -tulnp

这些选项的含义与

netstat

基本相同。

通过这两个命令，你可以看到诸如

Proto

（协议）、

Recv-Q

（接收队列）、

Send-Q

（发送队列）、

Local Address:Port

（本地地址和端口）、

Foreign Address:Port

（远程地址和端口）、

State

（连接状态）以及

PID/Program name

（进程ID和程序名称）等关键信息。

netstat

vs.

ss

：为何现代Linux更偏爱

ss

命令？

说实话，在我刚接触Linux运维的时候，

netstat

几乎是查看网络状态的唯一选择，它就像一位老兵，经验丰富，功能全面。但随着网络环境日益复杂，特别是服务器上的并发连接数动辄成千上万时，

netstat

的性能瓶颈就显现出来了。它在处理大量连接时会变得非常慢，甚至会卡住终端，因为它需要遍历

/proc/net

目录下的大量文件来收集信息。

而

ss

命令的出现，就像给网络诊断工具带来了一场革命。它不是简单地读取文件，而是直接与内核进行交互，从内核的套接字数据结构中获取信息，这使得它在性能上有着压倒性的优势。尤其是在那些高负载、高并发的生产环境中，

ss

的响应速度和效率明显高出一截。我个人在日常排查问题时，已经习惯性地优先使用

ss

了，那种即时反馈的感觉，真的让人效率倍增。

除了速度，

ss

在功能上也更胜一筹。它提供了更丰富的过滤选项和更详细的套接字信息，比如可以查看TCP拥塞控制算法、内存使用情况等，这些是

netstat

无法直接提供的。所以，虽然

netstat

依然活跃在很多老旧脚本和习惯性操作中，但如果你追求效率和更深层次的洞察，

ss

无疑是更现代、更强大的选择。

如何筛选特定端口或进程的网络连接？实用技巧解析

在实际工作中，我们往往不需要查看所有的网络连接，而是希望聚焦于某个特定的服务、端口或进程。这时候，简单的

grep

配合

ss

或

netstat

就能发挥巨大作用，让信息筛选变得精准而高效。

筛选特定端口：

假设我想看看服务器上80端口（通常是http服务）的连接情况。

使用

ss

：

ss -tulnp | grep ":80"

或者更精确地指定本地端口：

ss -tulnp sport = :80

sport

代表源端口（Source Port），

dport

代表目标端口（Destination Port）。如果你想看连接到远程80端口的连接，可以用

dport = :80

。

筛选特定进程：

如果你知道某个应用的进程名称，比如

nginx

，想查看它相关的网络连接：

ss -tulnp | grep "nginx"

如果只知道进程ID（PID），比如PID是12345：

ss -tulnp | grep "pid=12345"

筛选连接状态：

有时候，我们可能只想看处于特定状态的连接，比如所有已建立（ESTABLISHED）的TCP连接：

ss -t state established

或者所有监听（LISTEN）状态的UDP连接：

ss -u state listening

这些组合拳用起来非常灵活，能帮助你快速定位问题，比如某个服务是不是真的在监听，或者某个进程是不是建立了不该有的外部连接等等。这比漫无目的地滚动屏幕查看所有连接要高效得多。

理解网络连接状态：ESTABLISHED、LISTEN、TIME_WAIT等状态的含义与排查

理解TCP连接的各种状态对于网络问题的诊断至关重要，它们就像是连接的生命周期阶段，每个状态都承载着特定的意义。我们最常看到的就是

LISTEN

、

ESTABLISHED

、

CLOSE_WAIT

和

TIME_WAIT

。

• LISTEN (监听)：这表示一个套接字正在等待传入的连接请求。通常是服务器进程绑定了一个端口，准备接收客户端的连接。如果你发现某个服务无法访问，首先要检查它对应的端口是否处于

  LISTEN

  状态。如果不是，那服务可能没启动或配置有误。

• ESTABLISHED (已建立)：这是TCP连接的正常工作状态，表示客户端和服务器之间已经成功完成了三次握手，数据可以正常传输。大多数活跃的连接都应该处于这个状态。

• CLOSE_WAIT (等待关闭)：这个状态有点棘手，它表示远程主机（通常是客户端）已经关闭了连接，但本地主机（通常是服务器）还没有完全关闭它的套接字。这意味着本地应用程序没有及时调用

  close()

  来释放连接。大量的

  CLOSE_WAIT

  连接通常是应用程序编程缺陷的信号，表明服务器端没有正确处理连接关闭，这可能导致资源耗尽。

• TIME_WAIT (时间等待)：这是TCP连接关闭序列中的最后一个状态，由主动关闭连接的一方进入。它会持续一段时间（通常是2MSL，Maximum Segment Lifetime），目的是确保所有迟到的数据包都已在网络中消失，避免新连接收到旧数据包，并允许可靠地关闭连接。大量的

  TIME_WAIT

  连接在某些高并发短连接服务中很常见，虽然通常无害，但极端情况下也可能占用过多资源，导致端口耗尽。不过，现代Linux内核对

  TIME_WAIT

  的处理已经优化了很多，通常不会成为大问题。

• SYN_SENT (同步已发送)：客户端发送了SYN包，正在等待服务器的SYN+ACK响应。如果长时间处于此状态，可能表示网络延迟高或服务器没有响应。

• SYN_RECV (同步已接收)：服务器收到了客户端的SYN包，并发送了SYN+ACK，正在等待客户端的ACK响应。如果大量连接卡在这个状态，可能是遭受了SYN洪泛攻击。

当你在排查问题时，例如发现服务器响应变慢，查看连接状态就非常有帮助。如果看到大量的

CLOSE_WAIT

，你可能需要检查应用程序的代码逻辑；如果看到大量

TIME_WAIT

，并且端口耗尽，可能需要调整系统参数或优化应用程序的连接管理；如果

LISTEN

端口不翼而飞，那服务肯定没跑起来。这些状态，就像是网络连接的“健康报告”，能帮你迅速定位问题的症结所在。