网络层排查：从 ping 到 mtr，把路径摸清楚
网络层出问题，说白了就是包没送到。你想想看，应用层报超时，传输层握手失败，根子很可能就在网络层——路由不可达、丢包、延迟抖动，这些才是真凶。
我个人习惯，排查网络层从来不用花哨工具。ping、traceroute、mtr，再加一个网卡状态检查，这四板斧够用。今天我就把这几个工具怎么用、怎么看结果、怎么避坑，一次性讲清楚。
核心思路：先测连通性 → 再追路径 → 最后看网卡。别一上来就跑 mtr，那是浪费生命。
1. ping：最基础的连通性测试
ping 用的是 ICMP Echo 请求和响应。你发一个包，对方回一个包，就这么简单。但很多人只会 ping 一下看通不通，其实能挖的信息不少。
基本用法
# 持续 ping，按 Ctrl+C 停止
ping 8.8.8.8
# 指定次数，适合脚本
ping -c 5 8.8.8.8
# 指定间隔（秒），默认 1 秒
ping -i 0.5 8.8.8.8
# 指定包大小（字节），用于 MTU 探测
ping -M do -s 1472 8.8.8.8我的习惯：排查时先 ping 3 次，每次间隔 0.5 秒。如果第一次丢包，后面正常，那可能是网络波动。如果连续丢，那基本是链路断了。
怎么看结果
| 指标 | 正常范围 | 异常信号 |
|---|---|---|
| 延迟（RTT） | 同城 < 5ms，跨省 < 50ms | 突然飙到 200ms+，说明路径有问题 |
| 丢包率 | 0% | 超过 1% 就要查了 |
| TTL | Linux 默认 64，Windows 128 | TTL 变化说明路径变了 |
注意：有些防火墙会丢弃 ICMP 包。你 ping 不通，不代表服务端口不通。这时候要用 tcping 或直接测应用端口。
MTU 探测实战
我在项目中遇到过一个问题：网页能打开，但大文件上传总是卡死。查了半天，发现是中间链路的 MTU 比两端小，大包被分片后丢了。
探测方法很简单：
# 从 1472 开始，逐步减小包大小
ping -M do -s 1472 8.8.8.8
ping -M do -s 1400 8.8.8.8
ping -M do -s 1300 8.8.8.8-M do 表示禁止分片。如果某个包大小能通，说明 MTU 至少是这个值 + 28（IP 头 + ICMP 头）。
2. traceroute：把路径摸清楚
ping 只能告诉你通不通，traceroute 能告诉你在哪一段出了问题。它利用 TTL 逐跳递增的原理，让每一跳路由器都给你回一个 ICMP 超时消息。
基本用法
# Linux 默认用 UDP
traceroute 8.8.8.8
# 用 ICMP 模式，穿透性更好
traceroute -I 8.8.8.8
# 用 TCP 模式，端口 80
traceroute -T -p 80 8.8.8.8
# Windows 用 tracert
tracert 8.8.8.8我的建议：Linux 下优先用 traceroute -I。UDP 模式容易被中间设备拦截，ICMP 模式成功率更高。
怎么看输出
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 1.234 ms 1.123 ms 1.098 ms
2 10.0.0.1 (10.0.0.1) 3.456 ms 3.321 ms 3.210 ms
3 * * *
4 203.0.113.1 (203.0.113.1) 45.678 ms 50.123 ms 48.901 ms
5 8.8.8.8 (8.8.8.8) 12.345 ms 12.210 ms 12.098 ms看到第 3 跳全是 * 了吗？这不一定代表故障。很多运营商路由器不响应 ICMP 超时消息，直接跳过就行。但如果连续 5 跳都是 *，那基本是断了。
延迟突增的排查
你看第 4 跳，延迟从 3ms 飙到 45ms。这说明问题出在第 3 跳到第 4 跳之间。可能是链路拥塞，也可能是跨运营商了。
我记得有一次排查跨机房延迟问题，traceroute 一看，发现流量绕了半个中国。后来跟网络团队一聊，是 BGP 路由策略配错了。
3. mtr：持续追踪，不放过抖动
traceroute 只能看一瞬间的路径。如果网络抖动，你跑一次 traceroute 可能刚好没抓到。mtr 就不一样了，它会持续发包，实时统计每一跳的丢包率和延迟。
基本用法
# 默认持续运行，按 q 退出
mtr 8.8.8.8
# 只跑 10 次，适合脚本
mtr -r -c 10 8.8.8.8
# 报告模式，输出到文件
mtr -r -c 100 8.8.8.8 > mtr_report.txt
# 不解析主机名，更快
mtr -n 8.8.8.8怎么看输出
| 列名 | 含义 | 重点关注 |
|---|---|---|
| Loss% | 丢包率 | 超过 1% 就要警惕 |
| Snt | 已发送包数 | 至少 10 个才有统计意义 |
| Last | 最近一次延迟 | 看是否突然飙升 |
| Avg | 平均延迟 | 跟基线对比 |
| Best/Worst | 最好/最差延迟 | 差值大说明抖动严重 |
| StDev | 标准差 | 超过 10ms 说明不稳定 |
关键判断：如果某一跳丢包率很高，但后续跳丢包率很低，那这一跳的丢包可能是假的——它只是优先处理数据包，没空回 ICMP。真正的丢包是：从某一跳开始，后面所有跳都丢。
实战案例
我曾经帮一个客户排查视频会议卡顿问题。ping 网关延迟正常，但 mtr 一跑，发现第 3 跳的 StDev 高达 30ms。这就是典型的抖动问题——平均延迟不高，但忽快忽慢，视频流就受不了。
解决方案？跟运营商沟通，把路由切到另一条链路上，问题解决。
4. 网卡与链路状态检查
有时候问题不在网络，就在你眼前——网卡坏了、网线松了、协商速率不对。这些基础检查，我建议放在排查的第一步。
查看网卡状态
# 查看所有网卡
ip link show
# 查看 IP 地址
ip addr show
# 查看统计信息（丢包、错误）
ip -s link show eth0
# 老命令，但依然好用
ifconfig eth0用 ethtool 查看物理链路
# 查看协商速率和双工模式
ethtool eth0
# 查看网卡驱动信息
ethtool -i eth0
# 查看网卡统计（硬件丢包）
ethtool -S eth0我曾经踩过的坑：有一次服务器网卡显示 1000Mbps，但实际只有 100Mbps。查了半天，发现是网线只接了 4 根线（百兆模式）。ethtool 一看，Speed: 100Mb/s，真相大白。
关键指标解读
| 指标 | 正常值 | 异常值 |
|---|---|---|
| Speed | 1000Mb/s 或更高 | 100Mb/s 或 10Mb/s |
| Duplex | Full | Half（半双工会导致大量冲突） |
| Link detected | yes | no（网线没插好或对端关机） |
| RX errors | 0 | 持续增长说明物理层有问题 |
| TX errors | 0 | 持续增长说明网卡或驱动有问题 |
检查链路聚合和 VLAN
# 查看 bond 状态
cat /proc/net/bonding/bond0
# 查看 VLAN 配置
cat /proc/net/vlan/config
# 查看路由表
ip route show我的排查顺序：先看 ip link 确认网卡 up/down，再看 ethtool 确认速率和双工，最后看 ip -s link 检查丢包。这三步走完，物理层基本就摸透了。
总结：网络层排查三板斧
好了，我把网络层排查的核心工具都讲了一遍。你记住这个顺序：
- 先 ping —— 确认连通性和基础延迟
- 再 traceroute 或 mtr —— 定位问题在哪一跳
- 最后检查网卡 —— 排除物理层问题
这三个工具配合使用，90% 的网络层问题都能定位。剩下的 10%，要么是防火墙策略太奇葩，要么是光模块坏了——那又是另一套排查思路了。