【网络排查工具】SRE手边这 6 个命令，能搞定 90% 的网络故障

你在排查网络故障时是不是上来就ping一下通了就觉得“没事”然后用户说“还是慢”你又traceroute看一遍发现一堆* * *就懵了老实说我干 SRE 的头两年也这样。后来被线上事故教育了几回才明白每个命令都有它的正确打开方式用错了等于白干。这篇文章不讲大道理。我把手头最常用的 6 个网络排查工具按“先看通不通 → 再看怎么走 → 再看谁在占 → 最后抓包破案”的顺序讲清楚。每个工具只讲高频用法不做“全部参数罗列”——那种事让man手册去做就行。读完这篇你能快速判断是本地问题、运营商问题还是对端服务问题定位带宽被谁吃掉了进程级在 5 分钟内抓出 TCP 重传、丢包、延迟抖动的真凶避免被 ICMP 限速这类“假丢包”误导本文所有命令在Ubuntu 22.04 / RHEL 9上实测通过。如果你用的是 CentOS 7 或更早版本个别参数可能有差异我会注明。你要先确认这几件事开始排查前花 10 秒确认这些前置条件。别跳过去我在这上面吃过亏。条件检查方法踩坑提醒有 root 或 sudo 权限sudo -vtcpdump、iftop、nethogs 都需要。没有的话先找管理员开目标 IP/域名正确nslookup example.com域名解析错误是最隐蔽的问题之一建议先用 IP 测一轮网卡名称正确ip link show或ip a现在的命名是 eth0、ens3、enp0s3 等别想当然写 eth0防火墙没有完全拦死sudo iptables -L -n有些公司的安全组会拦 ICMP这时 ping 不通不代表服务真的挂了准备就绪说干就干。工具 1ping —— 永远的第一道门什么时候用它别笑话 ping——这个 1983 年就有的工具到今天仍然是排查网络的“敲门砖”。它的价值不是“测速”而是回答三个问题目标机器在不在网络层可达大概有多远RTT 粗估丢包严重吗丢包率我推荐的用法普通工程师用ping 8.8.8.8就结束了我习惯这样打# 发 30 个包带时间戳不走域名解析避免 DNS 干扰 ping -c 30 -D -n 8.8.8.8输出示例[1763800433.123456] 64 bytes from 8.8.8.8: icmp_seq1 ttl117 time12.3 ms [1763800434.126789] 64 bytes from 8.8.8.8: icmp_seq2 ttl117 time11.9 ms ... --- 8.8.8.8 ping statistics --- 30 packets transmitted, 30 received, 0% packet loss, time 29034ms rtt min/avg/max/mdev 11.234/12.567/15.432/1.234 ms参数解释-c 30发 30 个包就停别挂在那等 CtrlC-D每行前面打印时间戳事后对日志排查非常有用-n不解析域名快很多什么时候它不靠谱ping 用 ICMP 协议但很多运营商和云平台会限速或直接丢弃 ICMP 包。也就是说ping显示 50% 丢包但你的业务TCP 80/443可能完全正常。我一个客户曾经因为这事半夜被叫起来——监控显示 ping 丢包 60%结果业务丝滑如常。后来发现是运营商对 ICMP 做了限速策略。所以记住ping 不通不一定代表服务挂了。用nc -zv或telnet去测业务端口才是金标准。工具 2mtr —— 比 traceroute 靠谱 10 倍它解决了什么问题traceroute只跑一遍遇到中间某节点不响应就直接显示***然后你就抓瞎了。而mtrMy TraceRoute把ping和traceroute合二为一持续探测每个中间节点给出丢包率和延迟统计。用一句话说traceroute 告诉你“经过了哪些路由器”mtr 告诉你“每台路由器表现怎么样”。安装方法# Ubuntu/Debian sudo apt install mtr -y # CentOS/RHEL sudo yum install mtr -y核心命令这个你得背下来# 日常推荐TCP 模式 443 端口更接近真实业务路径 mtr --tcp -P 443 -n -c 100 目标IP参数说明--tcp改用 TCP 数据包不是 ICMP走业务走的链路-P 443指定探测端口如果是 HTTP 服务就改 80-n不反解域名-c 100发 100 个包后退出怎么看输出Start: 2025-12-13T10:00:000800 HOST: my-server Loss% Snt Last Avg Best Wrst StDev 1. 192.168.1.1 0.0% 100 1.2 1.5 1.0 2.0 0.3 2. 10.0.0.1 0.0% 100 5.1 5.5 4.8 6.2 0.4 3. 36.110.64.1 62.9% 100 3.1 12.8 3.0 15.1 4.2 4. 223.112.0.1 0.5% 100 12.3 13.1 11.2 15.0 0.8 5. 目标服务器IP 0.0% 100 18.2 19.0 17.5 20.5 0.7逐列解读Loss%这一跳的丢包率。跳 3 丢包 62.9%但延迟只有 3-15ms且后续节点丢包恢复正常 →这是典型的 ICMP 限速不是真故障。Avg平均延迟。看趋势——突然从 5ms 跳到 100ms 再降回来说明中间有波动。StDev标准差。数字越大表示抖动越严重。三个关键判断原则只看最后一跳的 Loss%如果最终目标丢包率 0%中间某跳 50% 丢包但后续恢复了大概率是那个节点禁 ICMP 回复不是故障。某一跳延迟突然飙升比如从 10ms 跳到 300ms之后又降不下来 → 问题大概率出在这跳所在的运营商骨干网或跨网互联节点。跳数中出现???但后续节点正常说明该节点不响应探测忽略即可。工具 3ss —— 比 netstat 快一个数量级为什么不用 netstat老工程师习惯netstat -an但在生产环境连接数几万的时候netstat能慢到你怀疑机器卡了。ss直接从内核获取 socket 信息性能和信息量都碾压 netstat。我个人的原则新装的 Linux 一律用ss除非你在连 netstat 都没装的旧机器上临时救火。高频命令速查你要干什么命令备注看所有监听端口TCPUDPss -tuln-t TCP-u UDP-l 监听-n 不解析看 ESTABLISHED 连接ss -tn最常用看某个端口谁在监听ss -tlnp | grep :80-p 显示进程名/PID看 TCP 重传统计ss -ti输出里找retrans看所有 TIME_WAITss -tan state time-wait排查端口耗尽问题示例定位谁在占用 8080 端口$ sudo ss -tlnp | grep :8080 LISTEN 0 128 0.0.0.0:8080 0.0.0.0:* users:((java,pid12345,fd46))告诉我PID 12345 的 Java 进程在监听着。直接kill或查日志。彩蛋ss -i看 TCP 内部状态这个很多人不知道。加上-i能看到每个连接的 RTT、拥塞窗口、重传次数$ ss -ti state established ( dport :443 or sport :443 ) ... cubic wscale:7,7 rto:204 rtt:12.3/1.2 ato:40 mss:1448 pmtu:1500 rcvmss:536 advmss:1448 cwnd:10 bytes_acked:123456 segs_out:123 segs_in:111 retrans:0/0重点关注rtt:12.3/1.2平均 RTT 12.3ms抖动 1.2msretrans:0/0重传次数左当前重传右总重传。如果重传很多说明链路不稳定或丢包严重。工具 4tcpdump —— 抓到真凶为止前面所有工具都是“猜”tcpdump才是“看现场”。它能抓到每一个数据包帮你确认“到底发了没有”“对方回了没有”“是谁在重传”。基础用法# 抓 100 个包写文件不要直接在终端打印 sudo tcpdump -i eth0 -c 100 -w /tmp/capture.pcap # 用 tcpdump 或 Wireshark 读文件 tcpdump -r /tmp/capture.pcap -n | head -20两个关键的参数一定要记住-s 0捕获完整数据包默认可能只抓前 68 字节不够用-i any谨慎使用会从所有接口抓包在 bond/team 环境下会重复抓同一个流量干扰判断实用过滤表达式建议收藏场景命令只抓目标 IP 的包sudo tcpdump -i eth0 host 10.0.0.1 -c 100抓 80 端口的 HTTP 流量sudo tcpdump -i eth0 tcp port 80 -A -c 50-A 以 ASCII 显示内容抓 SYN 包看 TCP 握手sudo tcpdump -i eth0 tcp[tcpflags] tcp-syn ! 0 -c 20抓 RST 包看谁主动断连sudo tcpdump -i eth0 tcp[tcpflags] tcp-rst ! 0组合条件源 IP 且目标端口 443sudo tcpdump -i eth0 src 192.168.1.100 and dst port 443实战抓 TCP 重传sudo tcpdump -i eth0 -e tcp[13] 0x04 ! 0 -c 100这条抓的是设置了 RST 标志的包tcpflags 第 4 位。如果是重传排查更常用的是sudo tcpdump -i eth0 -vv tcp[tcpflags] tcp-syn ! 0 or tcp[tcpflags] tcp-ack ! 0然后在输出里找重复的seq号——那就是重传。顺便提一嘴如果流量很大建议把 snaplen 限制到 256 字节够分析 TCP 头就行否则 tcpdump 自己可能丢包。工具 5iftop / nethogs —— 看看谁在偷带宽场景带宽被跑满了但不知道是谁干的iftop告诉你“哪些连接在消耗带宽”nethogs告诉你“哪个进程在消耗带宽”。iftop按连接看sudo iftop -i eth0 -n界面跑起来后按P显示端口号按T显示累计流量。从上往下是流量最大的连接。nethogs按进程看我的最爱sudo nethogs eth0输出类似PID USER DEVICE SENT RECEIVED COMMAND 1234 root eth0 1.2 MB 3.4 MB /usr/bin/nginx 5678 nobody eth0 8.9 MB 0.1 MB /usr/sbin/mysqld一目了然——如果 MySQL 在疯狂收数据查慢查询如果是 nginx 在狂发看访问日志。什么时候用哪个场景推荐工具想知道“哪个 IP/端口在跑流量”iftop想知道“哪个进程在跑流量”nethogs想看接口级实时速率图形化nload或bmon想看历史趋势昨天/上周的流量vnstat实战组合按步骤定位网络故障好了工具介绍完了。下面我把它们串起来给一个真正的故障排查流程。你下次遇到问题照着这个顺序走就行。场景用户反馈“服务很慢有时候还连不上”第一步快速确认30 秒内完成# 1. 业务端口通不通别用 ping nc -zv 目标IP 8080 # 或 time curl -o /dev/null -s -w %{time_total}\n http://目标IP:8080/health第二步看链路质量mtrmtr --tcp -P 8080 -n -c 50 目标IP重点看最后一跳丢包率 5% → 网络丢包看中间哪一跳开始丢最后一跳延迟 正常值 2 倍 → 某跳延迟突增定位后联系运营商第三步看本机连接状态ssss -tan | grep -c ESTAB # 看有多少活跃连接 ss -tan | grep -c TIME-WAIT # 看 TIME_WAIT 堆积情况 ss -ti | grep -c retrans # 看有没有重传如果TIME-WAIT有几万个且本地端口不够用业务就会报“Cannot assign requested address”。第四步抓包确认tcpdumpsudo tcpdump -i eth0 host 目标IP and port 8080 -w /tmp/debug.pcap -c 500把/tmp/debug.pcap拖到 Wireshark 里用tcp.analysis.retransmission显示过滤器看重传包。几个我踩过的坑值得你花 2 分钟看看这些都是线上真实炸过的每一条都花了不止一个通宵。坑 1ICMP 丢包不等于业务丢包我遇到过 mtr 中间跳丢包 60% 但业务零故障的情况。后来查了一圈才知道运营商骨干网对 ICMP 做了限速不是真丢包。避坑方法用mtr --tcp代替默认的 ICMP 模式或者直接用tcping测业务端口。坑 2netstat 在生产环境卡死有一次半夜被拉起来客户说服务器“网络卡死了”。上去netstat -an跑了 40 秒才出结果。改用ss1 秒出。从那以后我的习惯新机器一律用ss除非不得不用 netstat。坑 3tcpdump -i any 导致数据翻倍一个同事用tcpdump -i any -w test.pcap抓包分析网络重传问题发现 TCP 重传包数量是实际的两倍。排查了两个小时才发现在 bond 模式下-i any会把同一个数据包从物理接口和 bond 虚拟接口各抓一次造成重复。记住不用 -i any明确指定网卡名。坑 4ping 跨洋链路看不出问题用 ping 测新加坡服务器RTT 稳定在 80ms看起来挺正常。但业务就是慢。后来用mtr --tcp -P 443一跑发现第 9 跳延迟从 30ms 突增到 150ms丢包 20%。ping 看不到中间跳细节mtr 才能。最后说两句网络排查的核心不是“会敲命令”而是知道什么时候敲什么命令、看到输出后怎么解读。把这 6 个工具吃透了ping→ 快速敲门mtr→ 看路径质量ss→ 看连接状态tcpdump→ 抓包破案iftop/nethogs→ 抓出带宽杀手你就能搞定 90% 的网络故障。工具这东西多用才能形成肌肉记忆。建议你下次业务正常的时候找个测试环境把每个命令跑一遍看看正常输出长什么样。等出故障时你一眼就能看出哪里不对劲。你还有什么排查网络的好用命令或者踩过的坑评论区见。