Linux网卡丢包分析与故障排查方法

本文深入解析Linux系统中网卡丢包的真实原因与精准排查方法，强调必须聚焦rx_dropped、rx_over_errors、rx_fifo_errors和rx_missed_errors这四个关键指标，区分物理层异常、Ring Buffer溢出、内核协议栈瓶颈及虚拟化调度失衡等不同层级的丢包根源；同时揭示常见误区——如盲目grep“drop”、混淆rx_errors与丢包、忽略tc规则导致的“幽灵丢包”，以及物理链路协商失败等隐藏陷阱，并提供从/proc/net/dev快速初筛、ethtool深度诊断、dmesg日志验证到tc规则审计的一站式实战路径，助运维和开发人员告别凭经验猜错、高效定位真实瓶颈。

直接看 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 更轻量、兼容性更好：

• 执行 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 缓冲区的整条路径——每一步都可能卡住，而每个卡点对应的指标和调优手段完全不同。

到这里，我们也就讲完了《Linux网卡丢包分析与故障排查方法》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！