Linux网卡丢包需分层定位：先查/proc/net/dev的Rx-OVR（Ring Buffer溢出）和Rx-DRP（内核丢包），再用ethtool -S分析rx_over_errors、rx_fifo_errors、rx_missed_errors、rx_dropped等驱动级指标，同时排查tc/qdisc人为丢包、软中断压力、conntrack耗尽及防火墙规则。
Linux 网卡丢包不是单一现象，而是分布在物理链路、驱动层、内核协议栈、流量控制等多个环节的综合结果。真正要定位原因，不能只看“dropped”字眼，得盯住几个关键字段及其背后含义。
看懂 /proc/net/dev 的 Rx-DRP 和 Rx-OVR
这是最轻量、最稳定的第一入口：
- Rx-OVR > 0：Ring Buffer 溢出，包还没进内存就被网卡硬件丢弃——tcpdump 在 eth0 抓不到这些包。立刻查
ethtool -g eth0，若当前 rx 值为 256 或 512，高吞吐下极易溢出，可尝试ethtool -G eth0 rx 4096 - Rx-DRP > 0 且 Rx-OVR == 0：包已进 Ring Buffer，但在内核处理阶段被丢弃。常见于 socket 接收队列满、内存不足、NAPI 轮询延迟高，下一步应查
netstat -s | grep "packet receive errors"或cat /proc/net/softnet_stat第二列（dropped）是否同步上涨 - 虚拟网卡（如 virtio_net）可能不暴露 Rx-OVR，此时若 Rx-DRP 上涨 +
dmesg | grep -i "missed"出现提示，基本锁定 vCPU 调度不及时
深入 ethtool -S 查驱动级真实丢包
/proc/net/dev 是通用统计，而 ethtool -S 输出的是驱动原生计数器，字段更准、分层更细：
- rx_over_errors：对应 Rx-OVR，确认 Ring Buffer 溢出是否属实
- rx_fifo_errors：物理 FIFO 缓冲区满，多见于小包高吞吐场景，常与 rx_over_errors 同步上升
- rx_missed_errors：虚拟化环境关键指标，vCPU 调度延迟导致中断丢失，值上升即说明宿主机 CPU 过载或 vCPU 绑定不合理
-
rx_dropped：包已入 Ring Buffer，但被内核协议栈丢弃，常见于
net.core.netdev_max_backlog不足或软中断负载过高 - 注意：
rx_crc_errors、rx_frame_errors属链路层错误，反映线缆/光衰/双工不匹配，不等于丢包，但预示物理链路不稳定
别漏掉 tc/qdisc 的“静默丢包”
很多丢包根本不在网卡统计里——是人为配置的限流规则在起作用：
- 运行
tc qdisc show dev eth0，检查是否有netem、loss、policer、fq_codel等关键字 - 加
-s参数看真实丢包数：tc -s qdisc show dev eth0，关注输出中 dropped 列是否持续增长 - 容器环境要扩展排查范围：CNI 插件（如 Calico、Cilium）常在
cali+或lxc+虚拟接口上挂 tc 规则，不能只查 eth0 - 误配
tc qdisc add dev eth0 root netem loss 5%会导致 5% 出向包静默消失，删规则比调内核参数更直接有效：tc qdisc del dev eth0 root
结合协议栈与系统状态交叉验证
单看网卡统计容易误判，需联动其他维度确认：
- 查软中断压力：
watch -n1 'cat /proc/net/softnet_stat | head -1 | awk "{print \$2}"'，第二列非零且持续增长，说明 softnet 队列溢出 - 看中断分布：
cat /proc/interrupts | grep eth0，若所有 MSI 中断都集中在单个 CPU，说明未做 IRQ affinity，可启用 RPS 分散负载 - 检查 conntrack 表是否耗尽：
conntrack -S，insert_failed持续上升意味着新建连接被静默丢弃 - 防火墙干扰：运行
iptables -L -n -v | grep DROP，尤其关注 INPUT 链中无意识的 reject/drop 规则
