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 的映射关系不是一一对应的：
-
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 —— 因为它无声无息，又最常背锅。
