mtr测试怎么看丢包和延迟，先分清哪一跳出问题
mtr 把 ping 和 traceroute 合在一起，持续探测到目标经过的每一跳，并统计每跳的丢包率和延迟。
看懂 mtr 的关键不是找“红字最多”的那一行，而是判断丢包是否延续到最后一跳：中间某跳丢包、后面各跳正常，多半是该节点对探测包限速；
只有从某一跳开始直到目标都持续丢包，才说明这段链路真的有问题。
先跑出可对比的 mtr 结果
在 Linux 上通常直接用 mtr 目标地址，交互界面会实时刷新。
想保存结果发给别人或事后对比，用报告模式：
mtr -r -c 20 -n 目标IP-r输出报告，跑完自动退出-c 20发 20 轮探测，样本太少容易误判-n不解析域名，避免 DNS 干扰和等待
Windows 用户如果没有 mtr，可以用 tracert 或安装 WinMTR，字段含义相同。
测之前想清楚方向：在本机执行测的是去程，在服务器上执行 mtr 你的公网IP 测的是回程，排查访问慢时两边都要看。
四个字段决定你怎么读
报告里每行是一跳，重点看这几列：
- Loss%：该跳丢包比例。0 最好，但中间跳非 0 不一定有事，见下一节。
- Avg：平均延迟，判断是否绕路或拥塞的主要依据。
- Best / Wrst：最好和最差延迟，差距大说明抖动明显。
- StDev：延迟标准差，数值越大越不稳定，比单看 Avg 更能暴露质量问题。
一个实用顺序：先看最后一跳的 Loss% 和 Avg，再往上找从哪一跳开始变差，最后看 StDev 是否突然拉高。
中间跳丢包到底要不要管
这是新手最容易误判的地方。
路由中的很多节点会对 ICMP 探测包做限速或降优先级，表现为该跳 Loss% 很高，但下一跳又恢复正常。
判断规则很简单：
- 如果第 5 跳 Loss 30%，第 6 跳到目标都是 0%，那是第 5 跳自身限速，不用处理。
- 如果从第 5 跳开始，到目标每一跳都保持 20% 以上丢包，说明问题从第 5 跳之后出现，需要重点查这段。
- 如果只有最后一跳丢包，而倒数第二跳正常，通常是目标服务器或本机防火墙对探测做了限制，可换 TCP 模式验证：
mtr -T -P 443 -c 20 目标IP。
延迟同理：某一跳延迟突然从 20ms 跳到 200ms，但后续又回落，可能是该节点处理探测慢；
如果后续一直维持高延迟，才是真实绕路。
拿到结果后怎么定位和验证
看到异常先别急着找服务商，按这个顺序缩小范围：
- 确认是单向还是双向。本机去程正常、服务器回程丢包，问题更可能出在回程线路。
- 换目标对比。同一台机器测另一个同机房 IP，如果都丢包，偏向线路或机房问题；只有单个 IP 异常，偏向该主机。
- 用
ping -c 50 目标IP交叉验证最后一跳的丢包率，排除 mtr 单次波动。 - 记录时间点。晚高峰丢包、白天正常，通常是链路拥塞，把 mtr 报告和发生时间一起提交给服务商更有说服力。
如果最后一跳 Avg 正常但 StDev 很大，说明延迟忽高忽低，游戏、语音这类实时业务体感会很差；
如果 Avg 本身就高且沿途每跳递增，则是路径绕远。
常见疑问
mtr 显示中间跳 100% 丢包，是不是断网了？
不一定。只要后续跳和目标仍能通，这一跳的 100% 通常只是不响应 ICMP，不影响实际流量。
跑多少轮才够？
建议至少 20 轮，排查间歇性丢包时跑 100 轮以上，并在不同时段各测一次。
为什么服务器上测和本机测结果差很多？
因为去程和回程走的是不同路由，两边都要看，不能只凭一侧下结论。
看懂 mtr 测试的核心就是一句话：丢包和延迟要看到最后一跳是否延续，中间单点异常先当参考。
养成保存报告、标注时间、双向对比的习惯，比反复刷新界面更有用。
