mtr不是测跳数的工具，而是以跳数为坐标系定位链路稳定性问题：关键看哪一跳出现Loss%上升、Avg突增或StDev异常，而非跳数本身；跨机房链路中，跳数稳定但StDev>40ms大概率是BGP多出口轮询或ECMP哈希不均，跳数突增且某跳Loss%=100%常因设备禁ping，最后两跳Avg差值>200ms且仅末跳Loss%上升则提示目标机房防火墙限速。
mtr 不是“测跳数”的工具，而是用跳数为坐标系来定位链路稳定性问题——跨机房场景下，关键不是跳数多少，而是哪一跳开始出现 Loss% 上升、Avg 突增或 StDev 异常。
为什么跨机房链路不能只看跳数
跨机房（比如北京IDC → 广州IDC）通常经过 10–20 跳，但跳数本身不反映质量：运营商骨干网内部可能用 MPLS 隧道压缩逻辑跳数，也可能因 BGP 多路径分裂出不同长度的物理路径。真正影响业务的是中间某台核心路由器的队列拥塞、ACL 限速或策略路由切换。
常见误操作是跑 mtr example.com 后盯着“第 12 跳”看——其实该跳 IP 可能属于同一台设备的多个接口（如 AS4837 的 10GE/100GE 口），Loss% 和 StDev 才暴露真实抖动源。
- 跳数稳定但
StDev > 40ms：大概率是 BGP 多出口轮询或 ECMP 哈希不均，不是丢包，但会触发 TCP 重传 - 跳数突然从 15→18 且第 16 跳
Loss% == 100%：不是断连，是该跳设备禁 ping（尤其城域网 SR/BRAS 设备） - 最后两跳 Avg 差值 > 200ms 且 Loss% 仅在最后一跳上升：目标机房入口防火墙 SYN 洪水防护触发临时限速，非链路故障
mtr -c 100 -I --no-dns 是跨机房探测的最小安全参数组合
默认无限运行 + UDP 模式 + 自动 DNS 解析，在跨机房长链路上极易失效：
-
-c 100：必须指定总发包数。报告模式（-r）默认只发 10 次（mtr --report的坑），对间歇性丢包毫无识别力；100 次是平衡精度与耗时的底线 -
-I：强制 ICMP 模式。UDP 在骨干网常被 QoS 策略丢弃（尤其 DSCP=0 的探测包），而 ICMP 更接近真实运维探针行为 -
--no-dns：跨机房首跳延迟本就高，DNS 解析若走公网递归（而非本地缓存），会导致第 1 跳Avg虚高 100–300ms，污染判断基准
正确命令示例：sudo mtr -c 100 -I --no-dns -r cdn.example.com
区分“骨干网丢包”和“IDC 入口拥塞”的关键看三段模式
跨机房链路可粗分为：本地出口 → 运营商骨干网 → 对端机房入口。mtr 输出中这三段的 Loss% 和 Avg 组合决定根因：
-
本地出口段（第 1–3 跳）：若
Loss% > 0且StDev > 25ms，检查本端 BGP Peer 状态或物理光衰，不是远程问题 -
骨干网段（第 4–12 跳）：连续 3 跳以上
Loss% == 100%是正常现象（运营商屏蔽 ICMP），但若其中某跳Avg比前后跳高 >80ms 且StDev同步飙升 → 该 AS 内部存在负载不均 -
IDC 入口段（倒数第 1–3 跳）：若倒数第 2 跳
Loss% == 0、Avg == 12ms，而最后一跳Loss% == 15%、Avg == 210ms→ 目标服务器所在交换机 ACL 限速或网卡中断合并（IRQ）异常
绕过 ICMP 限制必须用 --tcp -P，不能只换协议不指定端口
当骨干网设备对 ICMP 做严格限速（如每秒 1 包），mtr -I 会误报高丢包。此时需切 TCP 模式，但常见错误是只加 --tcp 不指定端口：
-
mtr --tcp example.com默认用端口 80，若目标服务实际走 443 或 8443，则探测包被对端防火墙静默丢弃，结果仍是Loss% == 100% - 必须匹配真实业务端口：
sudo mtr --tcp -P 443 -c 50 --no-dns example.com - 对比 ICMP 与 TCP 模式：若 ICMP 某跳
Loss% == 90%，TCP 同跳Loss% == 0%→ 确认为 ICMP 限速，非链路故障
注意：--tcp 模式下 StDev 失去参考价值（TCP 握手引入额外变量），此时只看 Loss% 和 Avg 即可。
