使用MTR查找数据包丢失，并正确读取结果

安装

apt install -y mtr-tiny     # Debian
dnf install -y mtr          # AlmaLinux

正确运行

mtr -rwbc 200 <destination>

• -r 报告模式，这样退出时输出内容可以直接粘贴
• -w 宽输出，长主机名不会被截断
• -b 显示每一跳的名称和地址
• -c 200 两百个周期，大约三分半钟，这就是证据与轶事的区别

十个数据包证明不了任何事。如果十次周期运行显示丢包，在得出任何结论之前先跑两百次。

先看最后一跳

路由器会降低发给自己的数据包的优先级。承载数百吉比特流量的中转路由器在有空闲周期时会回应你过期的TTL探测，没有时会丢弃，这会在报告的中间部分造成丢包假象，而你真正关心的每个数据包都完好到达。

两条规则适用大多数报告：

1. 第7跳有丢包而第8跳及之后没有，是限速。忽略它。
2. 丢包从第7跳开始一直持续到目的地，是真实的，起始的那一跳是重点。

延迟同理。某一跳增加80毫秒，然后交给下一跳时恢复正常，那是响应慢，不是转发慢。

ICMP不是你的流量

如果服务运行在TCP上，就用TCP测试：

mtr -rwbc 200 --tcp --port 443 <destination>

严格限制ICMP的网络通常不碰TCP。反之亦然，值得事先发现：防火墙回应ping很积极，但丢弃用户实际访问的端口。

双向测试，每次都要

路由往往不对称。从你到我们的路径不是从我们到你的路径，单端报告只描述其中一条。从实例向客户端跑MTR，再从客户端向实例跑MTR，然后附带两份。我们这半的路径也可以不用登录服务器，通过looking glass探测。

用TCP计数器佐证

MTR描述路径。套接字统计描述结果：

ss -ti state established
nstat -az TcpRetransSegs TcpExtTCPLostRetransmit

重传率超过百分之一左右，在应有的干净连接上，支持该报告。零重传伴随满是丢包的MTR，意味着你在看限速，仅此而已。

发送给我们什么

• 两份MTR报告，两百个周期，用文本而不是截图
• 目的地、传输层协议和端口
• 带时区的时间戳，以及丢包是持续还是突发
• 实例ID

大约一半的情况归结为限速的中间跳，我们在第一封回复中说明。其余的我们通常能在小时内修改路由：我们网络内的丢包是我们的问题，一条传输路径上的丢包只需将你的流量移到另一条。