必须加-i、-c 100、--no-dns三个参数：-i强制icmp提升穿透性，-c 100确保足够样本覆盖抖动，--no-dns避免dns延迟污染首跳数据。
直接用默认参数跑 mtr example.com 很难抓到间歇性丢包——它默认走 UDP、发包无限、不屏蔽 DNS 延迟，结果容易误判。真正能定位“某跳偶尔掉几个包”的关键，在于控制探测方式、延长观察窗口、避开干扰项。
必须加的三个基础参数
避免常见误判，每次运行都应带上：
- -I：强制使用 ICMP 模式。UDP 在多数运营商设备和云防火墙里会被静默丢弃，导致跳数中断或虚高丢包，ICMP 穿透性更强，行为更接近真实业务（如 ping）
- -c 100：明确指定发包总数为 100 个。默认无限运行，新手常看前几秒波动就下结论；100 包约耗时 100 秒，足够覆盖典型抖动周期
- --no-dns：禁用反向 DNS 解析。首跳若因 DNS 查询卡顿，会污染网关延迟数据，让 Avg 和 StDev 失真
盯住三列，而不是只看 Loss%
输出中真正反映链路健康度的是这三列：
- Loss%：仅表示该跳设备是否响应了探测包（不是整条路径丢包）。若某跳突然从 0% 跳到 30%，先别急着报障——结合下一列看
- Avg：平均延迟。若第 n 跳 Avg 正常，但第 n+1 跳 Avg 飙升 >50ms 且 Loss% 同步上升，说明瓶颈在 n→n+1 这一段链路（比如城域网出口拥塞）
- StDev：标准差。比 Loss% 更早暴露问题。例如第 5 跳 Loss% = 0%，但 StDev = 42ms，大概率是该节点做了 BGP 多线负载分担，路由在两条路径间来回切换，造成延迟剧烈抖动
区分“真丢包”和“假丢包”
很多所谓“丢包”其实是策略限制，不是故障：
- 前三跳（本地网关、光猫、BRAS）Loss% 上升 + StDev >20ms → 检查本机 Wi-Fi 信号、路由器 QoS 是否开启“游戏加速”类功能（这类功能常主动限速 ICMP）
- 从第 3 跳起连续多跳 Loss% = 100%，但后续跳数仍能显示（即没断在中间）→ 典型中间运营商设备禁 ping，不影响实际 TCP 流量，可忽略
- 倒数第二跳 Loss% = 0%，最后一跳 Loss% > 0% 且 Avg > 300ms → 目标服务器过载或防火墙拦截 ICMP，不是网络链路问题，改用
mtr -t -P 443 -c 50 example.com测 HTTPS 端口验证
导出可比报告的正确姿势
用 --report 生成快照时，务必补上 -c：
- 错例：
mtr --report example.com→ 默认只发 10 个包，对间歇性丢包几乎无识别力 - 正例：
mtr -I --no-dns -c 200 --report example.com > mtr-200packets.txt→ 200 包样本，ICMP 模式，无 DNS 干扰，结果可横向对比不同时间段的报告
