mtr不是ping和traceroute的简单叠加，必须用-r -c 20 -n -4组合参数才能获得可靠结果：-r退出即输出、-c 20保障统计置信度、-n禁dns防卡顿、-4强制ipv4避双栈干扰；否则易将dns超时误判为真实丢包，或因交互模式、ipv6异常导致诊断失真。
mtr 不是 ping + traceroute 的简单叠加，参数错一个，结果就可能完全失真——尤其在云环境、多出口或 ICMP 受限场景下。
为什么直接 mtr example.com 会误判
默认交互式运行会卡在 ncurses 界面，没法重定向、没法进脚本；更危险的是它默认做反向 DNS 解析，遇到中间节点不响应 PTR 就卡住几秒，导致前几跳显示 ??? 或延迟虚高。你看到的“第 3 跳丢包 100%”，很可能只是 DNS 查询超时，不是真实丢包。
- 必须加
-r（report 模式）才能一次性输出统计结果，否则无法存档或对比 - 必须配
-c N（如-c 20），否则发包太少，抖动干扰判断 - 必须加
-n（no-dns），跳过所有反向解析，让结果快且稳 - 生产环境强烈建议加
-4，避免双栈环境下 IPv6 路由异常拖累诊断
mtr -r -c 20 -n -4 这组参数的实际效果
这是排查链路问题最可靠的基础组合，20 秒内完成、结果可复现、适合写入运维脚本：
-
-r：退出后直接打印汇总表格，不进交互界面 -
-c 20：每跳发 20 个包，足够覆盖常见波动，又不会因发包过多触发中间设备限速 -
-n：所有节点只显示 IP，不查 PTR，杜绝卡顿和解析失败干扰 -
-4：强制走 IPv4，绕过本地 IPv6 配置错误或运营商 IPv6 路由缺失的问题
执行示例：sudo mtr -r -c 20 -n -4 google.com。注意：普通用户需 sudo，因为原始 ICMP 探测需要 cap_net_raw 权限。
某跳 Loss% 突增，怎么区分是“隐身”还是真故障
华为/H3C 路由器、云厂商 SLB、骨干网设备普遍禁 ICMP echo reply，这不是异常，而是常态。关键看后续跳数是否同步恶化：
- 如果第 5 跳
Loss%是 100%，但第 6 跳回落到 0%、Avg正常、最终目标可达 → 第 5 跳只是“隐身”，跳过它继续看 - 如果从第 N 跳开始，
Loss%持续 ≥20%，且第 N+1、N+2 跳同步上升（比如 25%→40%→60%）→ 故障点就在第 N 跳设备或其出向链路 - 延迟突增但
Loss%为 0？重点看Best/Avg差值（如Best 8ms / Avg 120ms），大概率是中间节点开启深度包检测、QoS 限速或缓存队列积压
目标服务器屏蔽 ICMP 时怎么办
如果 mtr 全程无响应（所有跳都是 ??? 或 100% 丢包），先别急着怀疑链路，优先验证 TCP 层是否通：
- 用
telnet example.com 443或curl -I https://example.com测试业务端口 - 若 TCP 可通，说明中间节点策略性丢弃 ICMP，此时改用
mtr --tcp -P 443 -r -c 20 -n -4 example.com，用 TCP SYN 探测绕过限制 - 若 TCP 也不通，再结合
mtr -4 -r -c 20 -n 192.168.1.1（测网关）、mtr -4 -r -c 20 -n 同区域另一云主机IP做分段定位，缩小故障边界
真正容易被忽略的点：多网卡服务器必须加 -a IP 指定源地址，否则可能走错出口路由，测的根本不是业务真实路径。
