Ping、Traceroute、MTR有什么区别？网络故障排查该用哪个

排查网络故障最忌讳盲目抓包。Ping、Traceroute 和 MTR 这三个工具虽然大家天天都在用，但不少人在遇到访问异常时，依然分不清到底该用哪一个来定位问题。本质上，它们并不是替代关系，而是层层递进。Ping 帮你确认服务死活，Traceroute 帮你拆解数据包走的线路，而 MTR 则用来捕捉那些忽好忽坏的间歇性抖动。

如果你经常处理服务器丢包、线路绕路、跨境网络不稳定或者晚高峰卡顿等问题，这篇文章就是为你写的。接下来，我会深入拆解这三个工具在实际排查中的定位与局限，并通过几个最常见的网络故障场景，告诉你遇到不同问题时该怎么选工具，以及如何按最省时间的顺序快速锁定故障节点。

一、为什么排查网络故障不能只看Ping？

遇到网站打不开或者访问慢，大多数人的第一反应都是打开终端 Ping 一下目标 IP 或域名。

Reply from 203.0.113.10: time=31ms
Reply from 203.0.113.10: time=33ms
Reply from 203.0.113.10: time=30ms
Reply from 203.0.113.10: time=32ms

如果看到这种结果，很多人会觉得网络“没问题”。但实际上，用户从发起请求到收到回应，中间跨越了非常复杂的网络层级：

用户本地电脑 → 家用路由器 → 本地运营商接入网 → 国家骨干网 → 跨境海缆/线路 → 目标机房入口 → 服务器/CDN 节点

Ping 给你的，只是起点到终点拼凑出来的最终结果。

如果延迟飙到 200ms，Ping 只能告诉你“现在很慢”，却无法回答：到底是本地 Wi-Fi 信号不好、本地运营商拥堵、国际出口海缆故障，还是对方机房防火墙卡顿？

所以，Ping 适合做初步的“快速筛查”，但不适合单独用来定位具体的故障位置。

二、Ping 的正确用法与局限

Ping 适合在排障第一步使用，重点关注三个指标：

• 基础连通性：目标机器是否在线、响应。

• RTT（往返时间）：延迟是否在合理区间。

• 连续丢包与抖动：如果在测试过程中频繁出现Request timed out或延迟忽高忽低（比如上一秒 20ms，下一秒 300ms），说明网络存在严重不稳定。

排障中的两个常见误区：

1. Ping 不通 ≠ 服务宕机：很多公有云服务器、机房防火墙或 CDN 节点出于安全考虑，会直接禁掉 ICMP 协议（即拒绝回应 Ping），但 HTTP/HTTPS 或 SSH 服务依然可以正常访问。

2. Ping 很快 ≠ 网页加载快：网页打得慢，可能是 DNS 解析延迟、TCP 握手慢、TLS 证书协商耗时过长，或者后端数据库查询慢，这些 Ping 都无法反映。

当你发现 Ping 的结果确实存在高延迟或丢包时，就需要引入第二个工具：路由追踪。

三、Traceroute：把数据包的传输路线拆开看

如果说 Ping 是用来确认“对方在不在家”，那 Traceroute（路由追踪）的作用就是帮你把从本地到目标服务器之间经过的每一个路由器节点（Hop）全部扒出来。

跑一次 Traceroute，终端里通常会打印出类似这样的结果：

1   192.168.1.1       2 ms
2   10.10.0.1         8 ms
3   203.0.113.1      15 ms
4   198.51.100.5     68 ms
5   198.51.100.20   145 ms
6   203.0.113.50    152 ms

这份结果能直接告诉你不少关键细节：

• 数据包一共跳了多少个节点

• 每一个节点的 IP 地址

• 延迟是在哪个节点开始陡增的

• 路由有没有被绕远路

• 哪个节点丢包超时了

拿上面的数据来说，前四跳的延迟都在 60ms 以内，但到了第 5 跳突然飙到了 145ms。这时候你心里就有底了——排查重点直接锁定在第 4 跳到第 5 跳之间的这段网络。

这也正是 Traceroute 相比 Ping 最接地气的地方：Ping 只能告诉你“终点现在变慢了”，而 Traceroute 能直接指给你看“具体是从哪一段开始拉胯的”。

它最适合搞定哪些场景？

只要涉及到“路径”和“中间节点”的问题，用 Traceroute 排查效率最高：

• 单运营商异常：同一个网站，移动访问很流畅，电信或者联通访问却卡得要死。

• 跨境/海外服务延迟飙升：访问海外服务器时延迟爆表，怀疑流量被绕到了第三方国家。

• CDN 切节点后反变慢：接入 CDN 后以为会变快，结果调度错节点导致延迟反而升了。

• 特定地区连不上：只有某些省份或城市的用户报修说打不开服务器。

特别是做跨境业务或者用海外服务器时，只看 Ping 很容易被蒙蔽。比如同样是连接一台美国服务器，两条线路 Ping 出来的延迟可能都是 180ms。但用 Traceroute 一查，第一条是真正的跨太平洋海缆直连；第二条则是先从中国香港绕去欧洲，再跨大西洋切回美国。虽然平时 Ping 出来的数字差不多，可一旦到了晚高峰，第二条绕路线路的稳定性会瞬间崩掉。

看到* * *就是丢包了吗？

真不一定。 这是绝大多数新手最容易误判的地方。

比如经常能看到这种输出：

1   2 ms
2   8 ms
3   * * *
4   35 ms
5   42 ms

第 3 跳全部显示超时的星号* * *，但第 4 跳和第 5 跳却能秒回，而且延迟完全正常。

这种情况大可不必惊慌。中间那个路由器很可能只是开了安全策略，禁用了对 ICMP / TTL Exceeded 报文的回应，或者对探测请求做了极严的限速。只要数据包能顺畅穿过它传给第 4 跳，就说明真实的业务流量在这里根本没丢。

真正需要关注的故障特征只有一种：从某一跳开始出现超时或高延迟，并且这种异常一路顺延、砸到了后续的所有节点和最终目标。

四、MTR：捕捉动态抖动与持续丢包

如果说 Traceroute 算是一次性的路线抓拍，那 MTR（My TraceRoute）玩的其实是持续监控。

单跑一次 Traceroute，你只能看到当前那一秒数据包踩过了哪几个路由器。可现实里搞网络运维，最怕的从来不是彻底断网，而是那些抽风式的隐蔽故障：

• 白天顺畅得很，一到晚上八九点网页就卡死

• 隔个三五分钟丢几个包，WebSocket 直接断开

• 玩游戏或者语音通话，时不时跳一下高延迟

• 接口平时响应挺快，偶尔就超时一次

碰到这种抓不着规律的毛病，单跑一次 Traceroute 极容易刚好踩在网络正常的那一秒，啥异常也抓不到。

MTR 解决的就是这个问题。它相当于把 Ping 的连续发包和 Traceroute 的逐跳路由合在了一起，一边跑路由，一边盯着每一跳持续发包，最后拉出一份统计表。

拿到 MTR 的结果，盯着这几个核心指标看就行：

1. Loss%（丢包率）：别被单跳的高数字骗了

Loss% 看的是数据包丢了多少。跟 Traceroute 一个道理，中间某个节点丢包率高，不代表那里真出了故障。

假设第 4 跳显示丢包 50%，但后面的第 5 跳和最终目标丢包率全是 0%，这大概率是第 4 跳那个路由器限制了 ICMP 探测报文，业务流量过它的时候根本不受影响。

真正有问题的丢包，是从某一跳开始出现丢包（比如 10%），而且这个丢包率一路顺延到了后面的每一跳和终点。

2. Avg（平均延迟）：看真实传输水平

比起测一次两次的随机延迟，Avg（平均延迟）更能体现这条线路在几分钟内的真实拉胯程度。

3. Best 和 Wrst（最好/最差延迟）：专门抓网络抖动

搞实时业务，这两个指标比平均延迟重要得多：

• 如果 Best 30ms、Avg 35ms、Wrst 42ms，说明线路稳得很。

• 如果 Best 30ms、Avg 80ms，但 Wrst 飙到了 450ms，这就是典型的网络抖动。

像游戏、语音、WebSocket 或者实时 API 这类业务，对时延波动极其敏感。这种忽高忽低的剧烈抖动，往往比单纯的“延迟高”更折磨人。

​

五、三大工具功能对比

为了在日常工作中快速选对工具，可以参考这份汇总对比：

六、遇到不同网络故障，应该怎么选？

实战里大家很少为了测试而测试，基本上都是业务报了异常，再倒推该掏哪个工具。面对不同的故障现象，挑选工具的思路其实大不相同：

场景一：网站彻底打不开

第一时间还是先敲个 Ping。如果能 Ping 通，说明底层的网络链路大体没断，可以直接去排查 80/443 端口服务、Nginx 配置或者应用层是不是卡死了。如果连 Ping 都超时，再接着跑 Traceroute，看看请求到底是在哪一段彻底丢掉的。

不过这里有个小细节：千万别一看到 Ping 不通就断定是服务器宕机，很多机房或云厂商默认会封掉 ICMP 报文，但网页业务依然能正常跑。

场景二：网站能开，但加载明显变慢

这种情况先用 Ping 确认整体的往返延迟（RTT）。比如平峰期只有 35ms，突然飙到了 180ms，这就很适合接着用 Traceroute 来查了。

重点盯着延迟是从哪一跳开始出现剧烈跳升的，同时留意路由节点有没有变多。如果同一个 IP 昨天走的是 8 跳直连，今天突然变成了 15 跳还绕去了海外，那大概率是运营商路由调整或者海缆出问题导致绕路了。

场景三：白天顺畅，一到晚高峰就频繁卡顿

处理这种“时段性”的隐蔽故障，MTR 是唯一的选择。因为单次的 Traceroute 只能截取某一个瞬间，很容易刚好测在网络没卡的那一秒。

你需要的是在高峰期挂着 MTR 跑上几分钟，重点看 Loss%（丢包率）、Avg（平均延迟）和 Wrst（最差延迟）。如果某一个骨干网节点从晚上 8 点开始持续丢包、延迟飙升，到了半夜又自动恢复，这就是非常典型的骨干网带宽拥堵。

场景四：只有部分特定地区的用户反馈打不开

如果你身在北京，收到广东或者新加坡用户的报修，直接在自己电脑上敲命令没有任何意义，你的测试结果只能代表你本地到服务器的路径。

这种场景得靠chahu这种分布式的多节点拨测工具，直接从新加坡、德国、日本等不同地区的节点去发起 Ping 和 Traceroute。对比不同节点的路由图，要是发现北方节点一切正常，但新加坡节点被错误调度到了美国西海岸，那故障点就很清晰了，完全没必要把时间浪费在查服务器 CPU 或数据库上。

场景五：接入 CDN 后速度反而变慢了

这种情况相当常见。先 Ping 一下 CDN 节点返回的 IP，看看基础延迟是否符合预期。接着用 Traceroute 瞅一眼路由，很多时候是因为 CDN 节点的解析调度出了偏差，比如本该分配给香港用户的节点，却被调度到了更远的区域。如果访问只是偶尔卡一下，就再挂个 MTR 观察节点连接的稳定性。

七、最实用的网络故障排查顺序

日常排查网络问题，最忌讳上手就乱抓包或者瞎折腾配置。如果不确定从哪入手，记住这套顺手又省时间的排查流程：

Ping → Traceroute → MTR

1. 第一步用 Ping 敲门：先看目标能不能连通，算算基础延迟和丢包率，快速确认“到底是整体有问题，还是根本没通”。

2. 第二步用 Traceroute 扒路径：如果发现延迟飙升或者连接不上，用它把数据包经过的每一跳拆开看，锁定是从哪个节点开始出异常的。

3. 第三步用 MTR 盯稳定性：遇到那种忽好忽坏、晚高峰卡顿或者偶尔断连的问题，直接挂上 MTR 跑几分钟，盯着 Loss%、Avg 和 Wrst 看看波动规律。

为了方便查阅，不同故障对应的选型可以参考这个速查表：

这三个工具看着都是在测网络，其实分工非常明确：Ping 负责看终点通不通，Traceroute 负责看路线怎么走，MTR 负责看这条路稳不稳。按这个顺序一层层往下排，先定性（有没有问题），再定位（问题在哪），最后定抓手（是不是持续抖动），比一开始就死磕某一个工具要高效得多。