直接看ping输出末尾的“packet loss”百分比可获整条链路总丢包率，但无法定位故障点；真要查丢在哪，必须配合mtr逐跳分析或网卡底层计数器（如/proc/net/dev、ethtool -s）验证物理层丢包。
直接看末尾统计行的 packet loss 百分比，但这个数字只反映整条链路总丢包率，不能定位故障点；真要查丢在哪，必须配合 mtr 或网卡底层计数器。
怎么看 ping 输出里的丢包率
执行带次数限制的命令，比如 ping -c 50 www.baidu.com，结束后会输出类似这样的统计：
50 packets transmitted, 47 received, 6% packet loss, time 49003ms
其中 6% packet loss 就是本次测试的丢包率。注意几个关键点：
-
-c至少设为 50，太少（如默认 4 次）容易被单次抖动干扰，结果不可信 - 若显示
100% packet loss但目标网站能正常打开，大概率是对方禁 ping（如云厂商默认屏蔽 ICMP），不是你网络有问题 - 如果
packet loss是 0%，但业务仍卡顿，问题不在网络层——可能是 DNS 解析慢、服务响应延迟高、或本地 socket 缓冲区满 - 别只盯百分比：连续超时（
Request timed out）和部分超时（如 50 包里丢 3 个）代表不同严重程度，后者更可能与中间设备队列拥塞有关
为什么用 IP 测试比域名更可靠
域名解析失败会导致“假性丢包”：看起来是 ping 不通，其实是 dig 或 nslookup 卡在 DNS 查询阶段。这时候你看到的 packet loss 实际上是解析失败后的空等超时。
正确做法是分两步验证：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 先查真实 IP：
dig +short www.baidu.com或nslookup www.baidu.com - 再用 IP 直连：
ping -c 20 180.101.49.12（以实际解析出的 IP 为准） - 对比两次结果：如果域名丢包而 IP 正常，问题出在本地
/etc/resolv.conf配置、DNS 缓存（systemd-resolved）、或上游 DNS 服务（如 114.114.114.114 响应慢）
也可以一步到位加 -n 参数跳过解析：ping -c 20 -n www.baidu.com，但某些旧版系统不支持该选项。
哪些参数组合能暴露隐藏问题
单纯看丢包率容易漏掉抖动、间歇性拥塞等典型症状。这几个参数组合更实用：
-
ping -c 100 -q www.baidu.com：静默模式，只输出汇总，重点看mdev（平均偏差）。若mdev > 50ms且max远高于avg（比如 avg=22ms, max=840ms），说明链路存在严重抖动，TCP 重传会加剧 -
ping -c 50 -i 0.2 8.8.8.8：高频探测（需 root 权限才能低于 0.2s），适合抓偶发丢包窗口，比如无线干扰、交换机缓存溢出导致的秒级集中丢包 -
ping -c 30 -s 1472 www.baidu.com：发接近 MTU 上限的包（1472 + 28 = 1500），若小包正常、大包全丢，基本可断定路径中某节点 MTU 不一致或 PMTUD 失败
注意：-f（洪泛模式）虽能压测，但多数云主机和企业防火墙会直接限速或拉黑源 IP，非必要不用。
丢包率不准？先查网卡底层统计
有时候 ping 显示 0% 丢包，但业务 TCP 连接频繁断开或吞吐上不去，这时得绕过 ICMP，看网卡真实收发情况：
- 查接口名：
ip link show，确认主网卡如eth0或ens33 - 看内核统计：
cat /proc/net/dev | grep eth0，关注Recv列下的drop、errs、overrun是否持续增长 - 查驱动级计数：
ethtool -S eth0 | grep -i "drop\|error\|over"，特别留意rx_dropped—— 若它上涨快，常见原因是 ring buffer 太小、中断处理不及时，可尝试调大：sudo ethtool -G eth0 rx 4096
这些数字不受 ICMP 策略影响，是物理层/驱动层丢包的真实证据，也是很多“ping 很好但业务很卡”问题的最终答案。
