ip -s link 输出中代表丢包的字段包括：rx dropped（内核主动丢包）、rx overruns（ring buffer 溢出丢包）、rx errors（物理层错误丢包）和tx dropped（发送队列或qdisc限速丢包）。

ip -s link 输出里哪些字段代表丢包

ip -s link 是查看网卡收发统计最直接的命令，但输出中“丢包”不是单一字段，而是分散在 RX/TX 两组指标里的多个关键项：

• RX: ... dropped：内核接收队列已满或处理不过来时主动丢弃的包（常见于软中断瓶颈、CPU 负载高）
• RX: ... overrun：Ring Buffer 溢出丢包，说明网卡 DMA 写入速度 > 内核取走速度，硬件层就丢了
• RX: ... errors：物理层错误，比如 CRC 校验失败、帧长度异常，指向线缆、光衰、协商失败等
• TX: ... dropped：发送侧因队列满、qdisc 限速/丢包策略触发的丢弃（注意：tc 规则导致的丢包不体现在这里）

执行 ip -s link show eth0 后，重点盯这四列数字——只要非零且持续增长，就是丢包证据。

为什么 ifconfig 的 dropped 和 ip -s link 的 dropped 不一样

旧版 ifconfig 显示的 RX dropped 实际是内核 sk_buff 分配失败或 socket buffer 满时的丢弃，而 ip -s link 的 dropped 更底层，属于网络设备子系统（netdev）统计，包含 NAPI 处理阶段的丢弃。两者统计口径不同，ip -s link 更贴近真实网卡行为。

• 如果你看到 ifconfig 有 dropped 但 ip -s link 的 dropped 为 0，大概率是应用层 socket recv buffer 满了（查 netstat -s -u | grep "receive buffer errors"）
• 如果 ip -s link 的 overrun 高，ifconfig 却没显示对应字段——这是正常现象，ifconfig 不统计 Ring Buffer 溢出

ethtool -S 和 ip -s link 的丢包字段怎么对应

ethtool -S eth0 输出更细粒度，但字段名因驱动而异；它和 ip -s link 的映射关系不是一一对应的：

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• ip -s link 的 overrun ≈ ethtool -S 中的 rx_over_errors 或 rx_fifo_errors（具体看驱动，如 ixgbe 用 rx_fifo_errors，e1000e 用 rx_over_errors）
• ip -s link 的 errors ≈ ethtool -S 中的 rx_crc_errors、rx_frame_errors 等物理层错误总和
• ip -s link 的 dropped ≈ ethtool -S 中的 rx_missed_errors（部分驱动），但更多时候需结合 /proc/net/softnet_stat 第二列验证

别死磕字段名对齐，优先看趋势：同一时间点反复执行 ip -s link，若 overrun 或 dropped 在涨，就说明问题在发生。

tc qdisc 丢包不会出现在 ip -s link 统计里

这是最容易被忽略的一点：tc 配置的丢包策略（比如 netem loss 5% 或 police 限速）完全绕过网卡统计。即使 ip -s link 所有字段都是 0，网络照样可能大量丢包。

• 查是否启用：运行 tc qdisc show dev eth0，留意输出中是否有 loss、limit、rate、burst 等关键词
• 典型误配：测试环境留下的 tc qdisc add dev eth0 root netem loss 10%，上线后忘记清理
• 确认影响：用 hping3 -c 10 -S <target></target> 发包，同时抓包 tcpdump -i eth0 port 80，对比发出数与收到数

真正排查丢包，永远要先跑一遍 tc qdisc show —— 因为它无声无息，又最常背锅。