mtr是唯一能同时检测丢包率与逐跳延迟波动的网络诊断工具，它融合ping和traceroute功能，通过持续探测提供比单次测试更准确的链路质量分析。
直接测延迟，优先用 ping 快速确认是否通、基础 RTT 多高；真要定位卡在哪一跳，必须切到 mtr —— 它不是“更高级的 ping”，而是唯一能同时看丢包+逐跳延迟波动的工具。
ping 只适合快速摸底，别拿它查瓶颈
很多人一遇到慢就狂敲 ping -c 10 www.example.com，盯着 avg 值反复刷新。这只能告诉你“整体还活着”，但完全看不出是本地 Wi-Fi 不稳、运营商最后一公里拥塞，还是目标服务器本身响应拖沓。
-
ping默认发的是 64 字节小包，和实际 HTTP 请求、视频流的数据包大小差很远，ping -s 1400才更贴近真实负载 - 不加
-n会卡在 DNS 反解上，尤其第一次运行时明显卡顿，输出里出现???就是这个原因 -
time=后面的毫秒值是单次往返，但 avg 只是算术平均——如果某次突然飙到 800ms，avg 却只有 50ms，你根本意识不到抖动存在
mtr 的 -r 参数才是生产环境排查标配
交互式 mtr 看着炫酷，但终端断开、SSH 超时、想留档比对时，它就毫无用处。真正稳定复现、可存档、能进监控 pipeline 的，永远是 -r（report）模式。
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
-
mtr -r -c 20 -n 1.1.1.1：强制发 20 轮探测、禁 DNS、纯 IP 输出，结果一次性打印完，复制粘贴无干扰 - 输出里
Loss%非零，且集中在某跳（比如第 5 跳），基本可锁定是该节点上游链路问题，不是你本地或目标服务器的事 -
StDev> 30ms 就值得警惕，> 100ms 基本说明该节点存在严重队列抖动，光看Avg会误判
别忽略 -4 和 -6 的协议差异
很多服务同时支持 IPv4/IPv6，但你的网络出口、中间某台路由器、甚至 CDN 节点，可能只对其中一种协议做了优化。同一域名，mtr -4 和 mtr -6 结果可能天壤之别。
- 先跑
mtr -4 -r -c 10 example.com，再跑mtr -6 -r -c 10 example.com，对比两份报告里哪一跳开始分叉、哪边Wrst更离谱 - 如果
mtr -6从第 3 跳起全挂（全是???或???），大概率是本地 ISP 没配好 IPv6 路由，或中间某设备直接丢弃了 v6 包 -
ping6已被废弃，统一用ping -6；mtr则必须显式加-6，否则默认走 v4
交互模式下按 d 和 l 键比盯着数字更有用
刚进 mtr 交互界面时满屏数字容易懵。其实两个快捷键就能快速聚焦问题：
- 按
d切换到「延迟差分视图」：每跳显示Last - Avg，正数越大说明刚那一下越异常，比单纯看Last更敏感 - 按
l开启丢包率图表：横轴是时间，纵轴是 Loss%，一眼看出是持续丢包还是偶发尖峰 - 别信第一跳（通常是你的网关）的
Loss%，家用路由器常把 ICMP 优先级设得极低，Loss%10% 未必代表真断，但第 4 跳之后出现 5% 就要当真
真正难的从来不是命令怎么敲，而是看到 mtr 报告里第 7 跳 Wrst 突然跳到 1200ms、StDev 达到 420ms 时，你得立刻判断这是运营商骨干网调度异常，还是对方 CDN 节点过载——前者只能等，后者可以换域名或回源直连。
