Linux 网络故障排查终极教程：ping/traceroute/mtr + tcpdump/wireshark 实战

刚哥的进化路
237 阅读9分钟

网络故障排查的核心逻辑是 “先定位范围，再深挖根因”—— 从 “通不通” 到 “哪里断”，再到 “数据包哪里异常”，逐步缩小排查维度。本文结合 5 个高频故障场景，详解 ping、traceroute、mtr、tcpdump、wireshark 的核心用法，所有案例均来自企业级运维实战，可直接复刻操作。

一、基础连通性检测：ping 命令（快速判断 “网络可达性”）

ping 基于 ICMP 协议，是排查网络故障的 “第一步”，核心解决 “目标主机是否能访问” 的问题。

1. 核心用法与参数（实战高频）

\# 基础用法：无限发送ICMP包，Ctrl+C终止

ping www.baidu.com

ping 192.168.1.100

\# 实用参数组合（避免无限循环+精准测试）

ping -c 5 -i 1 -w 3 www.baidu.com  # -c：发5个包；-i：间隔1秒；-w：超时3秒

ping -s 1024 -n 192.168.1.1        # -s：包大小1024字节；-n：只显IP不解析主机名（提速）

ping -f 192.168.1.100              # -f：洪水ping（测试链路承载能力，谨慎使用）

2. 输出结果解读（3 个关键指标）

\# 正常输出示例

PING www.baidu.com (14.215.177.38) 56(84) bytes of data.

64 bytes from 14.215.177.38: icmp\_seq=1 ttl=55 time=11.2 ms

64 bytes from 14.215.177.38: icmp\_seq=2 ttl=55 time=10.8 ms

64 bytes from 14.215.177.38: icmp\_seq=3 ttl=55 time=11.5 ms

\--- www.baidu.com ping statistics ---

3 packets transmitted, 3 received, 0% packet loss, time 2002ms

rtt min/avg/max/mdev = 10.823/11.189/11.541/0.301 ms

  • 丢包率：0% packet loss为正常，>0% 说明链路不稳定（如 10% 丢包可能是带宽拥堵）；

  • 延迟（rtt）：avg<50ms 优秀，50-100ms 正常，>300ms 可能是跨地域 / 路由跳转过多；

  • TTL 值：Linux 默认 64，Windows 默认 128，TTL 骤降（如从 64→10）可能是路由环路。

3. 实战案例：ping 不通目标主机

场景

服务器 A（192.168.1.20）ping 服务器 B（192.168.1.30）显示100% packet loss，但同网段其他服务器可 ping 通 B。

排查步骤

\# 1. 确认目标主机是否在线（登录同网段服务器测试）

ping -c 3 192.168.1.30  # 若能通，说明问题在服务器A

\# 2. 检查服务器A的网卡配置

ip addr  # 确认IP是否在192.168.1.0/24网段，网卡是否UP

\# 3. 检查服务器A的防火墙（是否拦截ICMP）

firewall-cmd --list-all | grep icmp  # CentOS

iptables -L -n | grep ICMP          # Ubuntu

\# 4. 若防火墙拦截，临时放行ICMP

firewall-cmd --add-icmp-block-inversion  # 放行所有ICMP

根因与解决

服务器 A 的 firewalld 默认禁用了 ICMP 协议，放行后 ping 恢复正常。

二、路由跟踪：traceroute + mtr（定位 “故障节点”）

ping 只能判断 “通不通”，但无法知道 “哪里断了”。traceroute 跟踪数据包转发路径，mtr 持续监控路由质量，两者结合可精准定位故障节点。

（一）traceroute：跟踪路由跳转

1. 核心用法与参数

\# 安装（CentOS默认未安装）

yum install -y traceroute

\# 基础用法：跟踪目标域名/IP

traceroute www.baidu.com

traceroute 192.168.3.50

\# 解决UDP被拦截的问题（用TCP模式）

traceroute -T -p 80 www.baidu.com  # -T：TCP模式；-p：指定端口80

traceroute -n -w 2 192.168.3.50    # -n：显IP不解析；-w：每跳超时2秒

2. 输出结果解读

traceroute to www.baidu.com (14.215.177.38), 30 hops max, 60 byte packets

&#x20;1  192.168.1.1 (192.168.1.1)  0.45 ms  0.42 ms  0.39 ms  # 本地路由器

&#x20;2  10.0.0.1 (10.0.0.1)  2.13 ms  2.09 ms  2.05 ms        # 运营商网关

&#x20;3  \* \* \*                                                # 该节点禁用ICMP响应（正常）

&#x20;4  223.5.5.5 (223.5.5.5)  10.2 ms  10.1 ms  9.8 ms      # 阿里云节点

&#x20;5  14.215.177.38 (14.215.177.38)  12.3 ms  12.1 ms  11.9 ms  # 目标主机

  • 每一行代表 “一跳路由”，显示 IP 和 3 次延迟；

  • * * *：节点不响应 ICMP/UDP，但不一定是故障；

  • 故障定位：若前 3 跳正常，第 4 跳开始超时，说明故障在第 4 跳对应的设备。

（二）mtr：持续监控路由质量（ping+traceroute 结合体）

1. 核心用法与参数

\# 安装

yum install -y mtr

\# 基础用法：持续监控，Ctrl+C终止

mtr www.baidu.com

mtr 192.168.3.50

\# 生成统计报告（发送100个包后退出）

mtr -c 100 -w 192.168.3.50 > /tmp/mtr\_report.txt  # -w：简洁报告；-c：包数量

2. 输出结果解读（重点看丢包率）

HOST: localhost  Loss%   Snt   Last   Avg  Best  Wrst StDev

&#x20; 1.|-- 192.168.1.1          0.0%   100    0.5    0.6    0.4    1.2    0.1

&#x20; 2.|-- 10.0.0.1             5.0%   100    2.1    2.3    2.0    3.8    0.3  # 5%丢包

&#x20; 3.|-- 223.5.5.5            0.0%   100   10.2   10.5    9.8   15.3    0.8

  • Loss%：每跳丢包率（第 2 跳 5% 丢包，说明该链路拥堵）；

  • 若某一跳丢包率 > 5% 且后续跳均丢包，故障就在该节点。

3. 实战案例：跨网段访问超时

场景

服务器 A（192.168.1.20）访问服务器 C（192.168.3.50）超时，ping 和 traceroute 结果如下：

traceroute 192.168.3.50

&#x20;1  192.168.1.1 (192.168.1.1)  0.5 ms  0.4 ms  0.4 ms

&#x20;2  \* \* \*

&#x20;3  \* \* \*

排查步骤

\# 1. 用mtr持续监控，确认故障节点

mtr -T -p 80 192.168.3.50  # TCP模式避免被拦截

\# 2. 检查服务器A的路由配置

ip route show  # 确认是否有192.168.3.0/24的静态路由

\# 3. 若路由缺失，添加静态路由

ip route add 192.168.3.0/24 via 192.168.1.1 dev eth0

\# 4. 验证路由是否生效

ip route show | grep 192.168.3.0/24

根因与解决

服务器 A 缺少 192.168.3.0/24 的静态路由，添加后跨网段访问恢复正常。

三、抓包分析：tcpdump + wireshark（深挖 “协议层问题”）

当 ping/traceroute 确认网络连通，但应用服务（如 Web、数据库）无法访问时，需通过抓包分析 “数据包是否正常传输、协议是否异常”。

（一）tcpdump：Linux 命令行抓包（服务器端必备）

1. 核心用法与过滤规则

\# 基础用法：捕获所有网卡数据包（Ctrl+C终止）

tcpdump

\# 精准抓包（常用组合）

tcpdump -i eth0 host 192.168.1.20 and port 3306  # 捕获eth0网卡、目标IP+端口3306（MySQL）

tcpdump -i eth0 tcp and src 192.168.1.20 -w /tmp/mysql.pcap  # 保存抓包文件

tcpdump -r /tmp/mysql.pcap  # 读取保存的抓包文件

\# 过滤规则进阶

tcpdump -i eth0 not arp and not icmp  # 排除ARP和ICMP包

tcpdump -i eth0 tcp flags syn  # 只捕获TCP SYN包（发起连接）

tcpdump -i eth0 tcp port 80 and host 14.215.177.38  # 捕获HTTP流量

2. 输出结果解读（TCP 三次握手示例）

tcpdump -i eth0 tcp and host 192.168.1.20 and port 80

10:30:45.123456 IP 192.168.1.20.54321 > 14.215.177.38.80: Flags \[S], seq 12345, win 65535  # SYN（发起连接）

10:30:45.124567 IP 14.215.177.38.80 > 192.168.1.20.54321: Flags \[S.], seq 67890, ack 12346  # SYN+ACK（响应）

10:30:45.124678 IP 192.168.1.20.54321 > 14.215.177.38.80: Flags \[.], ack 67891  # ACK（确认连接）

  • Flags [S]：SYN 包（连接请求）；

  • Flags [S.]：SYN+ACK 包（连接响应）；

  • Flags [.]：ACK 包（确认）；

  • Flags [R]：RST 包（连接拒绝）。

（二）wireshark：图形化分析（可视化更直观）

tcpdump 适合服务器端抓包，wireshark 适合图形化分析，支持协议解析、过滤、统计，是排查复杂问题的 “终极工具”。

1. 基础操作流程

  1. 安装：官网下载（www.wireshark.org/），支持 Windows/Linux/Mac；

  2. 选择网卡：打开后选择抓包网卡（如 eth0），点击 “开始”；

  3. 设置过滤规则：过滤栏输入规则（与 tcpdump 互通，如ip.addr == ``192.168.1.20`` and tcp.port == 3306）；

  4. 触发业务：如执行mysql -h ``192.168.1.30`` -u root -p，让 wireshark 捕获数据包；

  5. 停止抓包：点击 “停止”，分析数据包。

2. 核心过滤规则（实战高频）

过滤规则作用
ip.addr == 192.168.1.20只显示与该 IP 相关的包
tcp.port == 3306只显示 MySQL 端口的包
tcp.flags.syn == 1只显示 TCP 连接请求包
tcp.flags.reset == 1只显示连接拒绝包
http.request只显示 HTTP 请求包
ssl.handshake只显示 HTTPS 握手包

3. 实战案例：MySQL 连接失败（协议层问题）

场景

服务器 A（192.168.1.20）连接服务器 B（192.168.1.30）的 MySQL（3306 端口）失败，报错 “Connection refused”，ping 和 telnet 192.168.1.30 3306 显示端口开放。

排查步骤

\# 1. 在服务器A上用tcpdump抓包

tcpdump -i eth0 host 192.168.1.30 and port 3306 -w /tmp/mysql\_fail.pcap

\# 2. 下载pcap文件到本地，用wireshark打开

\# 3. 过滤规则：ip.addr == 192.168.1.30 and tcp.port == 3306

分析结果

wireshark 显示服务器 A 发送 SYN 包后，服务器 B 回复 RST 包（Flags [R]），说明 MySQL 服务拒绝连接。

根因与解决

登录服务器 B 查看 MySQL 配置，发现my.cnf中设置了bind-address = ``127.0.0.1（仅允许本地连接），修改为bind-address = ``0.0.0.0后重启 MySQL，连接恢复正常。

四、5 个高频故障排查流程（直接套用）

故障 1：服务器无法访问外网

  1. ping 8.8.8.8 → 若不通，检查默认网关（ip route show default）；

  2. 若网关正确，用 traceroute 8.8.8.8 → 定位路由中断节点；

  3. 若网关错误，修改网卡配置文件（/etc/sysconfig/network-scripts/ifcfg-eth0）中的 GATEWAY；

  4. 重启网络：systemctl restart network。

故障 2：Web 服务访问超时（80 端口）

  1. telnet 目标 IP 80 → 确认端口是否开放；

  2. 若端口开放，用 tcpdump 抓包：tcpdump -i eth0 host 目标IP and port 80 -w /tmp/web.pcap；

  3. wireshark 分析：查看是否有三次握手、HTTP 请求是否有响应；

  4. 若只有 SYN 包无响应，检查目标服务器防火墙是否拦截 80 端口。

故障 3：HTTPS 访问报错 “证书无效”

  1. 用 wireshark 抓包：过滤规则ssl.handshake；

  2. 查看 SSL 握手过程，确认证书是否过期、域名是否匹配；

  3. 若证书不匹配，更换目标服务器的 HTTPS 证书。

故障 4：网络间歇性丢包（卡顿）

  1. 用 mtr 持续监控：mtr -c 200 -w 目标IP > /tmp/mtr.log；

  2. 查看 mtr 报告，找到丢包率 > 5% 的路由节点；

  3. 若为本地路由器，重启路由器；若为运营商节点，联系运营商处理。

故障 5：DNS 解析失败（域名无法访问）

  1. nslookup 目标域名 → 确认 DNS 解析是否正常；

  2. 若解析失败，用 tcpdump 抓 DNS 包：tcpdump -i eth0 port 53 -w /tmp/dns.pcap；

  3. wireshark 分析：查看 DNS 请求是否有响应，是否返回正确 IP；

  4. 若 DNS 服务器无响应，修改 /etc/resolv.conf，更换 DNS（如 223.5.5.5）。

五、避坑指南（新手必看）

  1. ping 不通≠网络故障：很多服务器禁用 ICMP（如阿里云 ECS），此时用 telnet/nc 测试端口；

  2. traceroute 的* * *不是故障：路由设备可能禁用 ICMP 响应，需结合 mtr 丢包率判断；

  3. 抓包时过滤无关数据：先明确故障场景（如 MySQL 连接），精准过滤 IP 和端口，避免数据包过多；

  4. HTTPS 抓包需解密：需导出服务器 SSL 密钥，在 wireshark 中配置（编辑→首选项→Protocols→SSL）；

  5. 跨网段故障先查路由：确认本地是否有目标网段的静态路由，路由器是否配置转发规则。

（注：文档部分内容可能由 AI 生成）

avatar
文章
阅读
粉丝