查询MTR测试结果，很多人一看到中间某个节点出现“100%丢包”，心就凉了半截，第一反应是“完了，服务器网络挂了”或者“这服务商线路也太垃圾了”。但实际情况往往没那么糟。中间节点丢包100%，但最终目标节点却正常响应，这种情况在MTR测试中非常普遍，通常不表示服务器或网络链路有问题。 恰恰相反，它可能恰恰说明链路是通畅的。

　　为了把这个问题彻底讲透，我们得先从MTR的原理说起。

　　MTR的工作原理

　　MTR可以看作是把traceroute和ping结合在一起的工具。它通过发送一系列TTL(生存时间)递增的数据包，强迫路径上的每一跳路由器在数据包过期时，回传一个ICMP超时消息。通过计算这些回传消息的耗时，MTR就能描绘出数据包从你的电脑到目标服务器所经过的每一站，以及每一站的响应时间。

　　但这里面有一个极其关键的细节：MTR的丢包统计，是针对“每一跳对ICMP请求的响应”而言的，而不是针对“数据包最终是否到达目标”而言的。

　　为什么中间节点会显示100%丢包?

　　原因主要有以下三个，其中第一个最为常见：

　　1. 路由器策略：ICMP限速或优先级最低

　　这是最核心的原因。互联网上的路由器(尤其是骨干网上的核心路由器)首要任务是转发数据包，而不是响应调试工具发来的ICMP探针。

　　对于核心路由器来说，处理数据包转发(三层转发)使用的是硬件芯片(ASIC)，速度极快，几乎没有性能损耗。但响应ICMP请求(比如回送超时消息)则是一个CPU处理的软中断操作。如果每一个路过此处的traceroute包都要响应，CPU负载会急剧升高，直接威胁到路由器的核心转发性能。

　　因此，绝大多数运营商(尤其是骨干网级别的运营商)会在网络设备上做策略配置：

• 将ICMP请求的响应优先级调至最低。
• 对ICMP响应进行严格的速率限制。

　　当你的MTR发送的探测包速率超过该路由器设定的阈值时，路由器会选择直接丢弃这些ICMP请求，而不是回复超时消息。于是，在MTR的输出中，这一跳就显示为“丢包100%”。

　　但关键点在于：这些被丢弃的仅仅是路由器主动回复给你的“回信”，而数据包本身(你的业务流量)早就在硬件层面被正常转发到了下一跳。 你的业务数据流压根就不需要路由器回复什么ICMP消息，它只需要被“转发”即可。

　　2. 中间节点并非数据包的真实路径

　　这个原因稍微技术化一些。现代网络大量使用了MPLS(多协议标签交换)技术。在这种网络下，数据包的路径并非每一跳都暴露给traceroute。为了安全或策略考虑，某些中间路由器根本不会出现在traceroute的路径列表里，或者即使出现了，也不参与ICMP的响应过程。

　　当你看到第5跳100%丢包，但第6跳和第7跳都正常时，很可能第5跳就是这样一个MPLS边界节点。数据包绕过了它的ICMP处理流程，直接通过标签交换被转发到了下一跳。

　　3. 运营商针对不同IP段的策略差异

　　还有一种常见情况：你对服务器做MTR，发现去程某个中间节点丢包严重，但回程却没有。或者反过来。这往往是因为运营商在去程和回程使用了不同的链路，或者对不同方向的ICMP包采用了不同的限速策略。这属于网络调度的常规操作，并不代表链路出现了拥塞或故障。

　　正确的验证思路：看最终一跳，不看中间节点

　　既然中间节点的丢包经常是“假摔”，那么正确的判断标准是什么?

　　唯一的黄金标准是：查看MTR结果中最后一跳(也就是你的目标服务器IP)的丢包率(Loss%)和延迟(Avg)数值。

　　如果最后一跳的丢包率接近0%(比如0%-0.5%)，那么无论中间出现多少个100%丢包的节点，都说明从你本地到服务器的整条链路是基本稳定和通畅的。业务流量正常传输，无需担心。

　　如果最后一跳的丢包率也达到了3%、5%甚至10%以上，那才是真正需要警惕的信号。这意味着数据包在到达服务器之前就已经大量丢失了，此时再回头去看是中间哪一跳开始出现持续丢包，才能定位到拥堵或故障点。

　　实战案例对比

　　我们可以看两个典型的MTR输出片段：

　　案例一：正常现象(假丢包)

Host                                    Loss%   Snt   Last   Avg  Best  Wrst StDev
1. 192.168.1.1                          0.0%    100   0.5    0.6  0.4   1.2  0.2
2. 10.2.1.254                           0.0%    100   2.1    2.3  1.8   4.1  0.5
3. 202.97.50.1                          0.0%    100   5.2    6.1  4.8   12.3 1.2
4. 202.97.27.78                         100.0%  100   ---    0.0  0.0   0.0  0.0
5. 59.43.80.137                         0.0%    100   25.3   26.1 24.8  31.2 1.1
6. 59.43.187.226                        0.0%    100   28.1   29.0 27.5  34.5 1.3
7. 你的服务器IP                         0.0%    100   30.2   31.3 29.8  38.2 1.5

　　分析：第4跳虽然100%丢包，但第5、6、7跳全部正常，且最终目标服务器丢包为0.0%。这是一个非常典型的“路由器拒响应ICMP”场景。链路质量很好。

　　案例二：异常现象(真故障)

Host                                    Loss%   Snt   Last   Avg  Best  Wrst StDev
1. 192.168.1.1                          0.0%    100   0.5    0.6  0.4   1.2  0.2
2. 10.2.1.254                           0.0%    100   2.1    2.3  1.8   4.1  0.5
3. 202.97.50.1                          0.0%    100   5.2    6.1  4.8   12.3 1.2
4. 202.97.27.78                         15.0%   100   18.5   35.2 16.4  120.3 18.5
5. 59.43.80.137                         18.0%   100   45.3   78.1 30.5  200.4 35.6
6. 59.43.187.226                        20.0%   100   68.2   112.3 40.1  300.1 55.2
7. 你的服务器IP                         22.0%   100   95.6   150.2 55.3  380.4 68.1

　　分析：从第4跳开始，丢包率一路累积，最终目标服务器的丢包率也高达22%。这才是真正的网络拥塞或链路故障。这种情况就需要联系服务商检查路由或更换线路了。

　　给技术小白的操作建议

　　如果你在MTR测试中遇到了中间节点100%丢包，最稳妥的做法是：别慌，先看最后一行。

　　如果最后一行的丢包率低于1%，你可以直接忽略中间所有红色的100%丢包，大概率是路由器的策略屏蔽。

　　如果最后一行的丢包率很高(比如超过2%-3%)，那你就需要关注这个丢包是从哪一跳开始的。通常从第一次出现丢包的那一跳起，后续每一跳都会有类似的丢包率，这时候就可以把这个路由节点和截图一起提交给服务器服务商的技术支持，让他们去排查上游运营商的问题了。

　　Q1：MTR测试中，除了丢包，延迟突然变得很大算不算问题?

　　A1：如果延迟在某一跳突然飙升(比如从30ms跳到200ms)，但后续又降回来了，这通常不是问题。因为不同的路由器处理ICMP包的优先级不同，有些路由器CPU负载高，响应慢，但数据转发能力依然是正常的。只有延迟在后续每一跳都持续居高不下，并且最终目标延迟也偏高时，才需要考虑是不是链路绕路了。

　　Q2：我该用多少个数据包来做MTR测试，结果才可靠?

　　A2：建议至少发送100个包(-c 100)。因为丢包是一个概率事件，发10个包丢1个就是10%，但这可能是偶然抖动。发100个包能有5%的丢包，才说明是持续性的网络问题。发1000个包虽然更准确，但测试时间太长，实操中100个包是比较好的平衡点。

　　Q3：我在本地MTR看到丢包，但服务商说他们后台监控一切正常，谁说的对?

　　A3：很可能都对。因为服务商的监控通常是从机房内部向外探测，或者监控的是机房核心交换机的端口流量，他们看不到“你家运营商到机房入口”这段中间链路的情况。如果你的MTR最终目标丢包率高，那就把MTR截图甩给服务商，告诉他们“问题出现在公网路由段”，让他们配合你排查或联系上游运营商。如果最终目标丢包率为0%，那就踏实睡觉，网络没问题。