最轻量且字段明确的丢包分类查看方式是ip -s link show，它将接收侧丢包分为dropped（内核协议栈丢）、overruns（ring buffer溢出）、errors（物理层错误）三类，需观察两次执行的差值是否增长：overruns增说明硬件层丢包；dropped增而overruns为0表明napi或软中断丢包；errors增则指向网线、光模块等物理问题。
用 ip -s link show 快速看实时丢包分类
这是最轻量、无需额外安装、且字段含义明确的入口。它把丢包拆成三类：接收侧的 dropped（内核协议栈丢）、overruns（Ring Buffer 溢出）、errors（物理层错误），发送侧也有对应项。ip -s link show eth0 输出后，重点盯 RX 下这三列数字——不是看绝对值，而是隔 2 秒执行两次，观察差值是否持续增长。
-
overruns上涨：说明网卡 DMA 写入速度 > 内核取走速度，包在硬件层就被丢了，tcpdump在该接口抓不到这些包 -
dropped上涨但overruns == 0：包进了 Ring Buffer，但在 NAPI 或软中断处理阶段被丢，常见于 CPU 过载、net.core.netdev_max_backlog太小 -
errors上涨：指向物理链路问题，比如网线松动、光衰、双工不匹配，必须结合ethtool -S看具体错误类型
用 ethtool -S 查驱动级真实丢包原因
ip -s link 是聚合统计，ethtool -S 才是驱动寄存器快照，字段更细、更准，但名字因芯片而异。执行 ethtool -S eth0 | grep -i "error\|drop\|miss" 后，重点关注这几个字段：
-
rx_over_errors或rx_fifo_errors：对应ip -s link的overruns，确认 Ring Buffer 是否真溢出 -
rx_missed_errors：虚拟化环境关键指标，vCPU 调度延迟导致中断丢失，值上涨即说明宿主机 CPU 过载或 vCPU 绑定不合理 -
rx_dropped：包已进 Ring Buffer，但被驱动主动丢弃，常见于校验失败、帧长异常，或启用了rp_filter -
rx_crc_errors/rx_frame_errors：纯物理层问题，非零持续增长基本可断定是线缆/光模块/交换机端口故障
注意：ethtool -S 不是所有网卡都支持完整字段，虚拟网卡（如 veth、macvlan）或老旧芯片（如某些 RTL8139）可能只输出基础项甚至报 No data available。
别漏掉 tc qdisc 导致的“静默丢包”
很多丢包根本不在网卡统计里——是人为配置的限流规则在起作用。运行 tc qdisc show dev eth0，检查是否有 netem、loss、policer、fq_codel 等关键字；加 -s 参数看真实丢包数：tc -s qdisc show dev eth0，关注输出中 dropped 列是否持续增长。
- 容器环境要查
cali+或lxc+接口，CNI 插件常在这些虚拟接口上挂 tc 规则，不能只查eth0 -
tc qdisc add dev eth0 root netem loss 5%这类命令会导致 5% 出向包静默消失，删规则前先确认是否为预期行为 -
tc丢包不会反映在ip -s link或ethtool -S中，必须单独查
为什么 /proc/net/dev 和 netstat -i 不推荐用于错包诊断
/proc/net/dev 的 errs 列本质是 ip -s link 中 errors 的镜像，但它不更新实时值——部分驱动（尤其是虚拟网卡）不会动态刷新这一列，可能长期为 0 即使实际有错包。netstat -i 更糟：它的 errs 是 RX + TX 错误总和，无法区分方向，也不显示 dropped、overruns、frame 等细分项。
- 如果你看到
/proc/net/dev中errs为 0，但ip -s link show显示非零，优先信后者 -
netstat -i已被标记废弃，新版系统中ss根本不提供接口统计功能 -
ifconfig的RX dropped实际是 socket buffer 满时的丢弃，和ip -s link的dropped统计口径不同，容易误判
真正要定位丢包，得从 ip -s link 入手，再按需深入 ethtool -S 或 tc -s qdisc ——别一上来就翻 /proc/net/dev 或跑 netstat -i，它们提供的信息既滞后又模糊。
