丢包必须用 mtr 定位具体跃点，ping 只能显示整条链路总丢包率而无法定位节点；mtr -n -r 是最小可靠组合，可逐跳统计 loss% 和延迟波动，精准识别过载或异常节点。
丢包必须用 mtr 定位到具体跃点，单靠 ping 只能看出“有没有丢”，看不出“在哪丢”
ping -c 能确认丢包率但无法定位节点
Linux 的 ping 默认不自动退出，不加 -c 就会一直发包，容易误判为“卡住”或“没响应”。它只输出每次的 time=xx.x ms 和末尾统计行里的 packet loss 百分比，但这个值是整条链路的总丢包，对排查毫无指向性。
- 用
ping -c 10 -n 223.5.5.5测 DNS 服务器，若显示10 packets transmitted, 8 received, 20% packet loss，你只知道丢了 2 个包，但不知道是本地网关、运营商出口还是远端机房丢的 -
-f（flood ping）在生产环境禁用：它绕过内核限速，可能触发交换机 ACL 或被对端限流，导致结果失真 -
-s设大包（如-s 1472）可暴露 MTU 问题，但若目标主机禁 ICMP，ping直接全无响应，不能反推是丢包还是策略拦截
mtr -n -r 是诊断丢包的最小可靠组合
mtr 的核心价值在于逐跳统计——每经过一个路由器，它都持续发包并记录该节点的丢包率（Loss%）和延迟波动。不加 -n 会卡在 DNS 解析上，尤其在中间节点无反向解析时，界面会停顿甚至假死；不加 -r 进入交互模式后，新手常误按空格或方向键导致视图错乱，反而看不清关键字段。
- 执行
mtr -n -r -c 20 14.215.177.39，输出中某行Loss% = 45%且StDev > 100ms，基本可断定该 IP 对应设备已过载或线路异常 - 若第 3 跳
Loss% = 0%，第 4 跳突增至60%，后续所有跳均100%，说明问题就在第 4 跳设备本身或其上游链路 -
mtr -n --tcp -P 443 example.com可绕过 ICMP 限制，但需注意：TCP 探测会真实建立连接，某些防火墙会对 SYN 包做速率限制，造成假性丢包
丢包和高延迟不是一回事，别混着看
mtr 输出里 Loss% 和 Avg 是两个独立指标。常见误区是看到某跳 Avg = 320ms 就认定“这里丢包”，其实只要 Loss% = 0%，说明包全到了，只是处理慢；反过来，Loss% = 30% 但 Avg = 12ms，说明该节点丢包严重但剩余包转发极快——典型如队列满后随机丢弃。
-
Wrst远大于Avg（比如Avg=15ms，Wrst=850ms）是网络抖动信号，往往伴随StDev > 50ms，此时重传机制更容易触发，TCP 吞吐会断崖下跌 - 对比两次
mtr -r结果时，重点比对同一跳的Loss%是否持续存在，而非只盯Avg数值变化——瞬时延迟波动正常，持续丢包才危险 - 如果所有跳
Loss% = 0%但业务仍超时，问题大概率不在网络层，而是目标服务响应慢、DNS 解析慢或本地 socket 缓冲区溢出
实际排查时最容易忽略的三件事
第一是源地址绑定：mtr 默认从本机默认路由出口发包，若机器有多个公网 IP（比如双线 BGP），不加 -a 可能走错线路，导致测试结果与真实业务路径不一致；第二是 IPv6 干扰：某些网络栈在 DNS 返回 AAAA 记录后会优先走 IPv6，而 IPv6 链路质量可能远差于 IPv4，务必用 -4 强制限定；第三是缓存误导：mtr 的交互模式下按 d 切换延迟视图时，屏幕显示的是历史累积值，新数据要等下一轮刷新才更新，想看实时变化得盯住 Last 列而非 Avg。
