Linux如何测试网络延迟 Linux环境下ping和mtr诊断网络详解

mtr是唯一能同时检测丢包率与逐跳延迟波动的网络诊断工具，它融合ping和traceroute功能，通过持续探测提供比单次测试更准确的链路质量分析。

直接测延迟，优先用 ping 快速确认是否通、基础 RTT 多高；真要定位卡在哪一跳，必须切到 mtr —— 它不是“更高级的 ping”，而是唯一能同时看丢包+逐跳延迟波动的工具。

ping 只适合快速摸底，别拿它查瓶颈

很多人一遇到慢就狂敲 ping -c 10 www.example.com，盯着 avg 值反复刷新。这只能告诉你“整体还活着”，但完全看不出是本地 Wi-Fi 不稳、运营商最后一公里拥塞，还是目标服务器本身响应拖沓。

• ping 默认发的是 64 字节小包，和实际 HTTP 请求、视频流的数据包大小差很远，ping -s 1400 才更贴近真实负载
• 不加 -n 会卡在 DNS 反解上，尤其第一次运行时明显卡顿，输出里出现 ??? 就是这个原因
• time= 后面的毫秒值是单次往返，但 avg 只是算术平均——如果某次突然飙到 800ms，avg 却只有 50ms，你根本意识不到抖动存在

mtr 的 -r 参数才是生产环境排查标配

交互式 mtr 看着炫酷，但终端断开、SSH 超时、想留档比对时，它就毫无用处。真正稳定复现、可存档、能进监控 pipeline 的，永远是 -r（report）模式。

• mtr -r -c 20 -n 1.1.1.1：强制发 20 轮探测、禁 DNS、纯 IP 输出，结果一次性打印完，复制粘贴无干扰
• 输出里 Loss% 非零，且集中在某跳（比如第 5 跳），基本可锁定是该节点上游链路问题，不是你本地或目标服务器的事
• StDev > 30ms 就值得警惕，> 100ms 基本说明该节点存在严重队列抖动，光看 Avg 会误判

别忽略 -4 和 -6 的协议差异

很多服务同时支持 IPv4/IPv6，但你的网络出口、中间某台路由器、甚至 CDN 节点，可能只对其中一种协议做了优化。同一域名，mtr -4 和 mtr -6 结果可能天壤之别。

• 先跑 mtr -4 -r -c 10 example.com，再跑 mtr -6 -r -c 10 example.com，对比两份报告里哪一跳开始分叉、哪边 Wrst 更离谱
• 如果 mtr -6 从第 3 跳起全挂（全是 ??? 或 ???），大概率是本地 ISP 没配好 IPv6 路由，或中间某设备直接丢弃了 v6 包
• ping6 已被废弃，统一用 ping -6；mtr 则必须显式加 -6，否则默认走 v4

交互模式下按 d 和 l 键比盯着数字更有用

刚进 mtr 交互界面时满屏数字容易懵。其实两个快捷键就能快速聚焦问题：

• 按 d 切换到「延迟差分视图」：每跳显示 Last - Avg，正数越大说明刚那一下越异常，比单纯看 Last 更敏感
• 按 l 开启丢包率图表：横轴是时间，纵轴是 Loss%，一眼看出是持续丢包还是偶发尖峰
• 别信第一跳（通常是你的网关）的 Loss%，家用路由器常把 ICMP 优先级设得极低，Loss% 10% 未必代表真断，但第 4 跳之后出现 5% 就要当真

真正难的从来不是命令怎么敲，而是看到 mtr 报告里第 7 跳 Wrst 突然跳到 1200ms、StDev 达到 420ms 时，你得立刻判断这是运营商骨干网调度异常，还是对方 CDN 节点过载——前者只能等，后者可以换域名或回源直连。