先上我最近跑的 MTR 结果截图——这是从我的电脑到微软官网的路由追踪：
说说 MTR 是什么
MTR（My Traceroute）是把ping和traceroute合二为一的工具。比单纯用 traceroute 强不少——traceroute 只给你看一跳的路径，而 MTR 会持续对每一跳发数据包，统计丢包率、延迟、抖动这些关键指标。
表头信息解读
先看最顶部那几行：
xuliat14p (172.30.67.50) -> www.microsoft.com (23.217.78.102)这行很简单：左边是我的机器主机名和IP，右边是目标域名和解析后的IP。注意这里微软的网站走了 Akamai 的 CDN，所以最终地址是a23-217-78-102.deploy.static.akamaitechnologies.com，这很正常。
右上角是测试时间2026-07-10T14:01:24+0800。
再下面一行是快捷键提示：Help、Display mode、Restart statistics、Order of fields、quit。交互式运行时按对应的字母键就能用这些功能。
核心列解释（重点！）
这是核心部分。
| 列名 | 全称 | 含义 |
|---|---|---|
| Host | Host | 每一跳的IP地址或主机名 |
| Loss% | Packet Loss | 丢包率，核心指标 |
| Snt | Sent | 已发送的数据包数量 |
| Last | Last | 最后一个包的延迟 |
| Avg | Average | 平均延迟 |
| Best | Best | 最好（最小）延迟 |
| Wrst | Worst | 最差（最大）延迟 |
| StDev | Standard Deviation | 延迟标准差，反映抖动程度 |
第一列：Host（路由跳数）
左边的数字是跳数（TTL）。从第1跳开始：
- 第1跳 172.30.64.1：这是我的网关，本地局域网出口。延迟只有 0.7ms，很健康。
- 第2跳 10.0.1.1、第3跳 10.0.0.1：这两个都是公司内网IP。
- 第4跳 121.15.204.41：开始进入公网，看IP应该是电信的设备。
- 第5跳 59.37.186.69：继续公网路由。
- 第6跳 (waiting for reply)：这个设备禁了ICMP，所以看不到IP。这种情况很常见，不用慌——只要后面的跳能通，说明这一跳其实是工作的，只是不回包而已。如果后面能显示，说明做了限速，毕竟公共路由器ICMP响应也是很耗CPU的。
- 第7-9跳：开始进入国际链路了，IP变成 202.97 开头（电信骨干网），然后是 twelve99.net（Telia Carrier，国际带宽运营商）。这里要特别注意下，第9跳是电信节点，为什么它的延时突然变大了，因为该节点已经在美国了。有些查询工具显示IP是国内，这是不准确的，多对比几个工具。
- 最后一跳：终于到了 Akamai 的 CDN 节点，就是微软网站实际托管的地方。
第二列：Loss%（丢包率）—— 判断问题的核心
这是最重要的一列。在深入分析之前，先搞懂一个最容易搞错的问题：
Loss% 到底是哪到哪的丢包？
答案：和延迟一样，这个丢包率是你的电脑到这一跳的总丢包率，不是上一跳到这一跳之间的丢包率。
MTR 对每一跳都独立发15个包，每个包设置对应的TTL值：
| 跳数 | 发送方式 | 丢包率含义 |
|---|---|---|
| 第1跳 | 15个TTL=1的包 | 这15个包里多少个没能到达第1跳 |
| 第2跳 | 15个TTL=2的包 | 这15个包里多少个没能到达第2跳 |
| 第7跳 | 15个TTL=7的包 | 这15个包里多少个没能到达第7跳 |
丢包率和延迟一样，都是从你的电脑到这一跳的"累计值"。
怎么定位丢包在哪发生的？
方法就是对比前后跳的丢包率变化。看截图数据：
第14跳：0.0% 丢包 （15个包全到了） 第15跳：7.1% 丢包 （15个包里丢了约1个）这就可以精确判断：这1个包就是在第14跳→第15跳这段路上丢的。
因为前13跳0丢包，说明前面的路完全没问题。到第15跳突然少了1个，问题就出在这一跳之间。
划重点：怎么看丢包是不是真问题？
很多人看到第7跳 78.6% 的丢包就吓坏了，以为网炸了。但仔细看——第9跳又恢复了 0% 丢包！这说明什么？
这不是真的网络丢包，而是第7、8跳的设备做了ICMP速率限制。
路由器对 traceroute 用的 ICMP 包通常优先级很低，忙的时候就直接丢了，这叫"控制平面限速"。判断是不是真丢包的方法很简单：
如果后面的跳丢包率比前面低→ 前面的丢包是假的，是设备限速
如果丢包从某一跳开始一直持续到最后→ 这才是真的有问题
在这个例子里，第7跳虽然 78.6% 丢包，但第9跳就完全正常了，说明这就是设备限速导致的假象，不用管。
第三列：Snt（发送包数）
这里每一跳都发了15个包。MTR默认每秒发一个包，所以这大概跑了15秒。
跑的时间越长，数据越准。排查偶发问题时，我一般会跑5分钟以上（Snt到300+），这样统计才有意义。
延迟相关四列：Last、Avg、Best、Wrst
这四列都是毫秒（ms）为单位。
看第1跳的数据：Last=0.6，Avg=0.7，Best=0.6，Wrst=1.9。
这说明什么？局域网非常稳定，最好和最差延迟只差1.3ms。
再看第9跳：Last=153.8，Avg=191.2，Best=141.7，Wrst=389.0。
这里波动就大了——最好141ms，最差接近390ms，差了两倍多。这是国际链路的正常现象，跨海网络波动在所难免。
经验分享：
- Avg（平均延迟）最有参考价值，反映链路整体质量
- Wrst - Best的差值越大，说明链路越不稳定
- Last只看最后一个包，参考价值有限，但可以看趋势
最后一列：StDev（标准差）—— 被忽略的宝藏指标
这一列很多人直接跳过，但其实非常重要。
标准差反映的是延迟的离散程度，也就是抖动（jitter）。
- StDev越小 → 延迟越稳定
- StDev越大 → 抖动越厉害
看几个例子：
- 第1跳 StDev=0.3 → 极其稳定
- 第3跳 StDev=0.2 → 简直完美
- 第9跳 StDev=79.9 → 抖动非常大，这就是国际链路的特性
- 第15跳 StDev=3.1 → 虽然有7.1%的丢包，但延迟其实很稳定
为什么抖动比延迟本身更重要？
打游戏、开视频会议、用VoIP的时候，你最怕的不是延迟高，而是时快时慢。100ms固定延迟你可能感觉不到，但上百毫秒的抖动，你就能明显感觉到。
StDev就是量化这个"卡"的程度的指标。
重要补充：Avg 到底是谁到谁的延迟？
这是不少人都会搞错的核心问题，必须单独拎出来说。
答案：Avg显示的是你的电脑到这一跳的总往返延迟（累计RTT），不是上一跳到这一跳之间的单跳延迟。
MTR的TTL递增机制
MTR 是靠逐次增大TTL值来实现追踪的：
| 跳数 | TTL设置 | 测量内容 |
|---|---|---|
| 第1跳 | TTL=1 | 你的电脑 ↔ 网关 的RTT |
| 第2跳 | TTL=2 | 你的电脑 ↔ 第2跳 的RTT |
| 第3跳 | TTL=3 | 你的电脑 ↔ 第3跳 的RTT |
| 第4跳 | TTL=4 | 你的电脑 ↔ 第4跳 的RTT |
所以每一行的延迟都是从你的机器开始累计的总时间，越往后越大是正常的。
怎么估算单跳延迟？
用截图数据做真实计算：
第3跳 Avg = 1.3ms （电脑到第3跳总延迟） 第4跳 Avg = 9.7ms （电脑到第4跳总延迟） 第3跳 → 第4跳 单跳延迟 ≈ 9.7 - 1.3 = 8.4ms注意一个常见现象：后面的跳延迟反而更小
看截图里第5跳 Avg=5.4ms，比第4跳的9.7ms还小，算出负数了！这不是MTR坏了，而是：
- 不同跳的数据包走的路径可能有细微差异
- 路由器对ICMP超时包的回复优先级很低，忙的时候就慢
- 网络状况本身就是波动的
所以单跳延迟只能估算，不能精确计算。MTR的真正价值是看整体趋势，而不是纠结某一跳的具体数值。
这个 MTR 结果告诉我们什么？
综合分析下来，这次到微软官网的网络情况：
- 本地网络没问题：前3跳0丢包，延迟个位数
- 国际链路正常：虽然中间几跳显示高丢包，但那是ICMP限速，不是真问题
- 跨国延迟正常：全程平均200ms左右，跨太平洋链路的正常水平
- 轻微抖动：中间几跳抖动较大，但最终节点StDev只有3.1，还算稳定
- 终点有7.1%丢包：这个要注意——如果是最后一跳持续丢包，可能是Akamai节点本身或者回程有问题
用 MTR 的几个实用技巧
最后分享几个我平时用 MTR 的心得：
- 双向都要测：网络是双向的，A到B好不等于B到A也好。排查问题最好两边都跑 MTR
- 跑足够长时间：至少30秒，最好5分钟，数据才靠谱
- 不要迷信中间跳的丢包：记住那个判断方法——后面恢复了就是假丢包
--tcp模式更真实：很多运营商封ICMP，用mtr --tcp测TCP端口，结果更接近真实业务情况--report生成报告：mtr --report www.example.com跑完直接输出统计结果，适合截图发运维
总结
MTR 看起来输出复杂，其实核心就是看几件事：
- 丢包从哪一跳开始？是不是一直持续到最后？
- 平均延迟是多少？有没有突然暴涨？
- 抖动（StDev）大不大？
掌握了这三点，90%的网络问题你都能快速定位。下次再遇到网站卡、游戏掉帧、连接超时，先跑个 MTR 看看。
