移动到系统路径并重命名

sudo mv mtr-amd64 /usr/local/bin/mtr

sudo mv mtr-packet-amd64 /usr/local/bin/mtr-packet

赋予执行权限

sudo chmod 700 /usr/local/bin/mtr /usr/local/bin/mtr-packet

（4）执行mtr命令

（5）分析结果

例子：

HOST: example.com Loss% Snt Last Avg Best Wrst StDev

1.|-- gateway.lan 0.0% 10 0.4 0.5 0.3 1.1 0.2

2.|-- isp-pe.example.net 0.0% 10 9.2 10.1 8.4 15.2 1.8

3.|-- core1.backbone.example 50.0% 10 18.0 18.4 17.1 22.0 1.1

4.|-- core2.backbone.example 0.0% 10 88.5 90.2 85.1 120.4 10.3

5.|-- target.example.com 0.0% 10 91.0 92.0 89.0 125.0 11.0

各列的含义

HOST

该跳的 IP 地址或域名。前面的 1.|--、2.|-- 表示这是路径上的第几跳（Hop）。

Loss%

该跳的丢包率 。表示发送的探测包中，有多少百分比没有收到回应。0.0% 表示全部有回应。

Snt

已发送的探测包数量 。你用了 -c 100，所以这里通常显示 100。如果中途有丢包，Snt 仍表示"已发送"，不是"已收到"。

Last

最近一次探测的延迟，单位毫秒（ms）。反映的是最新一次的结果，参考价值有限。

Avg

平均延迟，单位毫秒。这是该跳所有探测结果的平均值，比 Last 更有代表性。

Best

最小延迟，即所有探测中最快的一次。反映该跳的理想延迟水平。

Wrst

最大延迟，即所有探测中最慢的一次。如果这个值远高于 Avg，说明该跳存在明显抖动。

StDev

延迟的标准差。数值越大，说明延迟越不稳定、抖动越严重。例如 StDev 为 0.2 表示很稳定，10.3 表示波动较大。

解读 MTR 报告的核心是寻找持续性的异常。

警惕"中间跳丢包"的假象 ：某一跳显示高丢包率，但后续所有跳（包括目标）的丢包率都很低或为 0 ，这通常是因为该路由器限制了 ICMP 响应速率 ，并非真的丢包。真正的丢包问题，会从某一跳开始，并持续到路径末端。
关注延迟的"跃升"并持续 ：如果在某一跳延迟突然大幅增加（例如从 20ms 跳到 90ms），并且这个高延迟一直保持到目的地，那么问题很可能就出在这个跃升的节点或其之后的网段

mtr 的 Host 列显示 ???，核心原因是：该跳的路由器没有返回 ICMP 超时消息，导致 MTR 拿不到它的 IP 地址或域名。

MTR 依靠 TTL 递减机制来"发现"路径上的每一跳。当数据包的 TTL 减到 0 时，路由器应该丢弃该包，并回送一个 ICMP Time Exceeded 消息。MTR 收到这个消息，就能知道这一跳的 IP 和延迟。

如果路由器禁用了 ICMP 响应 （比如企业防火墙、云服务商的边缘网关），或者主动丢弃了 ICMP 控制报文 ，MTR 就收不到任何回音。这时它无法确定这一跳是谁，只能显示 ???

想看到被隐藏的 IP，可以试试这两个方法
（1）换 TCP 协议探测：ICMP 被屏蔽时，TCP 包往往能穿透。用 sudo mtr --tcp -P 443 -r -c 20 目标IP，用 TCP SYN 包代替 ICMP 来探测，可能看到部分 ??? 背后的真实 IP。

（2）加 -n 参数：有时 ??? 也和反向 DNS 解析卡顿有关。加 -n 跳过域名解析，能避免因解析超时导致的显示异常。

traceroute 目标ip或域名查看出网从哪儿出的，每一跳的ip