Linux如何查看网卡是否丢包 ifconfig详解-LINUX-PHP中文网

ifconfig 的 dropped 和 overruns 仅反映内核收包末端丢弃，无法覆盖网卡硬件层和驱动 ring buffer 丢包；需结合 ethtool -s 和 netstat -s 交叉验证。

linux如何查看网卡是否丢包 ifconfig详解

ifconfig 显示的 dropped 和 overruns 是关键指标，但不能单看它下结论——它只反映内核收包路径末端的丢弃，漏掉了网卡硬件层和驱动环形缓冲区（ring buffer）的丢包。

执行 ifconfig eth0 后，重点关注 RX（接收）段的这几个字段：

dropped：表示已成功进入内核协议栈、但因套接字缓冲区满、无监听进程或内存不足等原因被丢弃的包。常见于 UDP 服务未启动或 net.core.rmem_max 过小
overruns：更关键——它通常意味着网卡 ring buffer 溢出，即数据包到达太快，驱动还没来得及取走，新包就覆盖了旧包。这是典型的“硬件级丢包”信号
errors 和 frame：多由物理链路问题引起（如网线接触不良、光衰过大、双工不匹配），但现代网卡较少见；若持续增长，优先查物理连接和 ethtool -D eth0 的驱动调试日志

注意：ifconfig 在较新系统中已被 ip -s link show eth0 取代，但字段含义一致，ip 输出中的 rx_dropped 和 rx_over_errors 对应原 dropped 和 overruns。

因为 ifconfig 统计的是“内核软中断处理完之后”的丢弃，而真正的大头常发生在更早环节：

网卡 DMA 写入 ring buffer 时，buffer 满了 → 包直接被网卡硬件丢弃，ifconfig 完全不统计（需用 ethtool -S eth0 | grep -i "drop\|fifo\|overflow" 查 rx_fifo_errors 或 rx_missed_errors）
驱动未及时从 ring buffer 取包，导致后续包被覆盖 → overruns 会上升，但若驱动实现绕过了标准路径（如某些 DPDK 或 XDP 应用），overruns 也可能为 0
iptables 或 nftables 规则在 PREROUTING 链显式 DROP → 这类丢包不计入 ifconfig，得看 iptables -t raw -L -v -n 或 nft list ruleset

单靠 ifconfig 容易误判，建议三步交叉确认：

查硬件层丢包：ethtool -S eth0 | grep -E "(rx_|tx_).*[dD]rop|fifo|miss"，重点关注 rx_fifo_errors（ring buffer 溢出）、rx_missed_errors（驱动取包太慢）、rx_bad_count（校验失败）
查协议栈丢包：netstat -s -u 看 Udp: 段下的 packets to unknown port received（端口无监听）、packet receive errors（套接字缓冲区溢出）
查实时变化：用 watch -n1 'cat /proc/net/dev | grep eth0' 观察 rx_dropped 和 rx_over_errors 是否持续上涨，比静态截图更有说服力

如果 ifconfig 的 overruns 为 0，但 ethtool -S 中 rx_fifo_errors 持续增长，说明 ring buffer 太小，该调大了——这时改 ifconfig 没用，得用 ethtool -G eth0 rx 4096。

有些虚拟化环境（如 KVM + virtio_net）或容器网络（如 Cilium 使用 eBPF）会让 ifconfig 统计失效：

ethtool -S eth0 可能返回 no stats available，此时只能依赖 /proc/net/dev 和 netstat -s
使用 SR-IOV 或 DPDK 的网卡，ifconfig 显示的其实是 PF 接口统计，VF 的丢包需单独查 VF 设备名（如 eth0v0）
systemd-networkd 管理的接口可能不更新 ifconfig 的历史计数器，优先用 ip -s link show