Linux查看网络连接状态 netstat与ss命令高级用法

在今天的Linux生产环境中，如果你还在用netstat查看网络连接，那可能已经落后了。一个明确的结论是：ss命令已经全面替代netstat，这不是一个“可选项”，而是一个“必选项”。尤其在排查连接堆积、TIME_WAIT异常或端口冲突时，netstat不仅可能漏掉关键状态、导致输出卡顿，其遍历/proc文件系统的行为甚至可能拖慢系统本身。相比之下，ss直接读取内核的socket信息，速度快，并且原生支持IPv4/IPv6双栈及精细的状态过滤。

为什么 ss -ant | grep ESTABLISHED 统计不准

很多工程师习惯用ss -ant | grep ESTABLISHED | wc -l来统计活跃连接数，但结果常常比实际少。问题出在哪里？

首先，ss默认只显示IPv4的TCP连接。而现代的服务架构，比如Kubernetes Ingress或者gRPC服务，大量使用IPv6或UDP协议（例如DNS查询、QUIC协议）。其次，像SYN-RECV、FIN-WAIT-2这类中间状态，并不会被简单的ESTABLISHED关键词匹配到。

• 正确的统计姿势：要准确统计所有活跃TCP连接（包含IPv4和IPv6），应该分别加上-4和-6参数执行，或者使用更精确的Awk命令：ss -t -a | awk '$1 ~ /^(tcp|tcp6)$/ && $NF ~ /^(ESTABLISHED|SYN-RECV|FIN-WAIT-2)$/{i++} END{print i+0}'。
• netstat的陷阱：用netstat -an | grep ESTABLISHED问题更大。它会将TIME_WAIT状态视为“已关闭”，但实际上在内核中，这些连接依然占用着端口和内存。而ss可以通过ss -tan state time-wait单独抓出这类连接，诊断更清晰。
• 容器环境注意：在容器（如Pod）内部执行ss时，如果不加-n参数禁止DNS解析，命令可能会卡住。务必养成加-n的习惯。

ss -tulnp 报 “Permission denied” 怎么办

执行ss -tulnp查看监听端口和对应进程时，如果遇到“Permission denied”错误，别急着怀疑权限。根本原因在于，-p选项需要读取/proc/[pid]/fd/下的socket文件描述符，而普通用户无权访问其他用户的/proc目录。

• 标准解法：最直接的方法是使用sudo提权，即sudo ss -tulnp。但要注意，像Ubuntu 22.04+等一些发行版，出于安全考虑默认禁用了sudo对ss -p的支持。这时可能需要临时启用cap_net_admin能力，或者换个思路。
• 备选方案：可以先运行ss -tuln（不带-p）定位端口，然后用lsof -i :端口号来查询占用该端口的进程。如果连lsof都没安装，还可以手动解析/proc/net/tcp文件中的十六进制端口号，再与ps aux的输出进行匹配。
• 容器内的限制：在容器内运行时，ss -tulnp只能看到当前容器内的进程。别指望用它来发现宿主机上Nginx或kube-proxy的监听端口。

netstat 已卸载或不存在时的等效替换

新版的CentOS 8+/RHEL 8+、Ubuntu 18.04+等系统，默认已经不安装netstat了。强行通过yum install net-tools或apt install net-tools装回来，其实是种倒退。这不仅引入了过时的依赖，其遍历/proc的方式还可能干扰正常的性能监控。

其实，netstat的大部分功能都有更现代、更高效的替代命令：

• netstat -r（路由表） → 用 ip route show，它更准确，还支持策略路由。
• netstat -i（网络接口） → 用 ip -s link show，它能显示收发包计数和错误统计，并且去掉了过时的“collisions”字段。
• netstat -g（组播） → 用 ip maddr show。
• 唯一稍微特殊的是netstat -s（全协议统计）。这时直接用ss -s就行，它的输出结构更清晰，并且包含了内存使用、TCP重传、SYN Cookies等关键指标。

用 ss 监控高并发连接下的 TIME_WAIT 泛滥

当Web服务每秒处理数百个新建连接时，ss -s输出中tcp小节里的time_wait数量如果持续超过30000，通常意味着端口耗尽的风险正在逼近。这可不是简单调大net.ipv4.ip_local_port_range就能解决的表面问题。

• 定位问题源头：首先得确认这些TIME_WAIT连接是谁发起的。运行ss -tan state time-wait sport = :8080（假设服务端口是8080）。如果源地址（src）是本机IP，说明是本机作为客户端发起的连接没有被复用；如果目标地址（dst）是本机IP，那才是服务端被动关闭连接后产生的残留。
• 检查内核参数：设置net.ipv4.tcp_tw_reuse = 1可以允许TIME_WAIT套接字被新的出向连接复用（仅适用于客户端场景）。但要注意，调低net.ipv4.tcp_fin_timeout并不能减少TIME_WAIT的数量，它只是加速回收，盲目调整反而可能引发连接被RST重置。
• 治本之策：更根本的做法是，用ss -tan state time-wait | head -20抽样查看对端IP。如果发现连接集中在某几个上游IP，那么推动上游服务启用HTTP Keep-Alive或使用连接池，才是解决问题的关键。

说到底，真正的挑战从来不是记住几个命令参数。而是在看到ss -s输出里memory那一行的used值逼近limit时，能立刻反应过来：这未必是连接数太多，更可能是内核的socket内存分配器快要撑不住了——这种时候，再翻手册可就来不及了。