真正代表丢包的字段是rx_dropped、rx_over_errors、rx_fifo_errors、rx_missed_errors：rx_dropped表示内核层丢包；rx_over_errors和rx_fifo_errors反映Ring Buffer与FIFO溢出；rx_missed_errors指示vCPU调度丢失。
直接看 ethtool -S 输出里真正代表丢包的字段，别用 grep -i drop ——它会漏掉关键指标，也会把重传、过滤等伪丢包当真问题。
盯住四个核心字段：rx_dropped、rx_over_errors、rx_fifo_errors、rx_missed_errors
这些是分层定位丢包环节的“锚点”，每个对应不同层级的瓶颈：
-
rx_dropped：包已进 Ring Buffer，但被内核丢弃。常见于内存紧张、NAPI 轮询延迟高、软中断（NET_RX）负载过重，或 socket 接收队列满（net.core.netdev_max_backlog不足） -
rx_over_errors：Ring Buffer 溢出，驱动还没来得及取走旧包，新包就被网卡硬件丢弃。这是典型的“收得太快，取得太慢”，优先查ethtool -g eth0当前大小，再考虑调大（如ethtool -G eth0 rx 4096） -
rx_fifo_errors：物理 FIFO 缓冲区溢出，常与rx_over_errors同步上涨，说明网卡芯片 DMA 压力大，多见于小包高吞吐场景，需结合驱动版本和固件状态判断 -
rx_missed_errors：虚拟化环境最敏感的信号。vCPU 调度不及时导致收包中断丢失，值上升基本可锁定宿主机 CPU 过载、vCPU 绑定不合理或超配
注意：rx_errors 是 CRC、frame、length 等链路层错误总和，增长只说明物理链路质量差（线缆/光衰/协商失败），不等于丢包；tx_aborted_errors 是冲突重试失败，也不是发送丢包。
别跳过 /proc/net/dev 的 RX-OVR 和 RX-DRP 列
这是最快速、最稳定的入口级判断依据，比 ethtool -S 更轻量、兼容性更好：
CentOS Linux 7.9.2009
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离线兼容性测试。
下载
- 执行
cat /proc/net/dev，找到目标网卡行，看Rx-DRP和Rx-OVR两列 -
Rx-OVR > 0→ Ring Buffer 溢出，立刻查ethtool -g eth0并观察是否随流量上升而持续增长 -
Rx-DRP > 0且Rx-OVR == 0→ 问题在内核协议栈或应用层，下一步该看netstat -s | grep "packet receive errors"或cat /proc/net/softnet_stat第 2 列（dropped） - 虚拟网卡（如
virtio_net）可能不暴露Rx-OVR，此时Rx-DRP上涨 +dmesg | grep -i "missed"出现提示，就是 vCPU 调度瓶颈的强信号
tc 规则造成的丢包完全不会出现在网卡统计里
这是生产环境最常被误判的“幽灵丢包”——网卡清白，但流量就是少了一截：
- 运行
tc qdisc show dev eth0，重点找含netem、loss、policer、fq_codel的规则 - 确认丢包行为：加
-s参数（tc -s qdisc show dev eth0），看输出中是否有dropped计数在涨 - 典型误配：
tc qdisc add dev eth0 root netem loss 5%，它会让所有出向包无差别丢 5%，且/proc/net/dev和ethtool -S全部为零 - 清除命令是
tc qdisc del dev eth0 root，但务必先确认无业务依赖（如容器 CNI 插件可能在 host interface 上挂了规则）
排查时最容易忽略的其实是物理层连通性
很多“严重丢包”根本没进协议栈，tcpdump 抓不到、ethtool -S 也看不出异常，但 ethtool eth0 一眼就能揭穿：
- 必须确认三项：
Link detected: yes、Speed:与对端匹配、Duplex: Full - 若显示
Auto-negotiation: off或failed，手动协商（如ethtool -s eth0 speed 1000 duplex full autoneg off）或换线缆 - 查驱动异常：
dmesg | grep -i "eth\|nic\|firmware"，重点关注DMA timeout、reset failed、firmware crash - 物理网卡和虚拟网卡的字段差异极大：Intel
i40e有rx_no_buffer_count，virtio_net则压根不暴露rx_fifo_errors，硬套文档会踩坑
真正难的不是查哪个字段，而是理解数据包从网卡 DMA 写入 Ring Buffer，到被 NAPI 取走、进入 softnet 队列、再到 socket 缓冲区的整条路径——每一步都可能卡住，而每个卡点对应的指标和调优手段完全不同。
