MTR综合诊断关键在于路由路径、丢包率与延迟变化三者联动判断：一、正确使用-r -c 20 -n -4参数避免DNS/IPv6干扰；二、关注Loss%突增、持续升高或Avg/Best差值大等信号；三、TCP模式验证ICMP限速；四、结合dig、traceroute、ping区分路径异常与目标屏蔽。

Linux 中用 mtr 做综合诊断，关键不是“看哪一跳红了”，而是通过路由路径 + 丢包率 + 延迟变化三者联动判断问题本质。它不是 traceroute 和 ping 的简单相加，而是一套有逻辑的链路体检流程。

一、必须用对参数，否则结果不可信

默认直接运行 mtr example.com 容易误判：卡在 DNS 解析、进交互界面无法保存、IPv6 干扰、发包太少……这些都会让诊断失真。

• -r（report 模式）：不进界面，一次性输出，适合截图、存日志、写脚本
• -c 20：每跳发 20 个包，兼顾统计置信度和避免触发中间设备限速
• -n（no-dns）：跳过反向解析，杜绝因 PTR 查询失败导致的“假高延迟”或“???”
• -4：强制 IPv4，绕开本地 IPv6 配置异常或运营商 IPv6 路由缺失干扰

正确命令示例：sudo mtr -r -c 20 -n -4 google.com（普通用户需 sudo，因 ICMP 探测需 cap_net_raw 权限）

二、看懂输出里的关键信号

重点关注三列：Loss%（丢包率）、Avg（平均延迟）、Best/Avg 差值（反映抖动）。

Linux Security Scanner

Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...

下载

• 某跳 Loss% 突增（如从 0% → 85%），但下一跳回落到 0%，且最终目标可达 → 该跳大概率是“隐身”（禁 ICMP 回复），不是故障
• 从第 N 跳起，Loss% 持续升高（如 20% → 45% → 70%），且 Avg 同步拉高 → 故障点就在第 N 跳设备或其出向链路
• Avg 很高但 Loss% 为 0，且 Best 很低（如 Best 12ms / Avg 180ms）→ 中间节点可能开启深度包检测、QoS 限速或队列积压

三、ICMP 不通？换 TCP 模式验证真实路径

很多云厂商、骨干网设备、防火墙会策略性丢弃 ICMP 包，导致 mtr 显示全跳高丢包，但业务完全正常。这时不能直接下结论“链路坏了”。

• 先验证业务端口是否通：curl -I https://example.com 或 telnet example.com 443
• 若 TCP 可通，改用 TCP 模式探测：sudo mtr --tcp -P 443 -r -c 20 -n -4 example.com
• 对比 ICMP 与 TCP 结果：若某跳在 ICMP 下丢包严重，TCP 下恢复为 0% → 确认为 ICMP 限速，非真实故障

四、区分“路径异常”和“目标屏蔽”

全程都是 ??? 或 100% Loss%，不代表网络一定断了，可能是目标服务器或中间策略全面屏蔽 ICMP。

• 先用 dig +short example.com A 确认解析 IP 是否准确，排除 DNS 劫持或负载均衡干扰
• 对解析出的每个 IP 单独跑 mtr，看是否一致异常
• 若仍无响应，尝试 traceroute -n example.com 看是否能走到某跳就中断；再配合 ping -c 30 example.com 看整体连通性