linux无丢包记录，仅有累加计数器；/proc/net/dev的rx-drp/rx-ovr、ethtool -s的missed/fifo/crc错误、tc qdisc的dropped值共同构成分层丢包诊断体系。
Linux没有“丢包记录”，只有丢包统计
Linux内核不保存每个被丢弃数据包的原始内容、时间戳或上下文（比如源IP、端口），所以不存在类似日志文件那样的“丢包记录”。你看到的所有输出，都是计数器——rx_dropped、rx_over_errors、rx_crc_errors 等，全是累加值，不是事件日志。
强行用 tcpdump -i eth0 或 Wireshark 捕获“没收到的包”，是无效思路：丢掉的包根本没进抓包点。真正能告诉你“为什么丢”的，只有分层统计 + 关联线索。
查 /proc/net/dev 看最稳的入口级丢包趋势
这是轻量、通用、无需 root 权限就能读取的入口，比 ip -s link 更早暴露问题：
-
Rx-DRP：包已进 Ring Buffer，但被内核协议栈丢弃（如 socket buffer 满、无监听端口、内存分配失败） -
Rx-OVR：Ring Buffer 溢出，网卡 DMA 写入时直接覆盖旧包——硬件级丢包，ifconfig不报这个
执行：
watch -n1 'cat /proc/net/dev | grep eth0'观察这两列是否持续上涨。单次数值无意义，重点看单位时间内的增量。
用 ethtool -S 定位丢包发生的具体层级
ethtool -S eth0 输出的是驱动原生计数器，字段名因芯片而异（Intel igb 和 Broadcom bnxt 不同），但核心字段含义稳定：
-
rx_missed_errors：vCPU 调度不及时或软中断处理慢，Ring Buffer 没来得及收，新包被覆盖（虚拟机常见） -
rx_fifo_errors：网卡内部 FIFO 溢出，多见于小包高吞吐场景，常与rx_over_errors同步涨 -
rx_crc_errors、rx_frame_errors：物理链路异常（线缆松动、光模块衰减、双工不匹配）的铁证 -
rx_dropped：驱动主动丢弃，可能含 checksum fail、rp_filter 触发等
别用 grep -i drop ——会漏掉 missed、fifo 这类关键词。正确命令：
ethtool -S eth0 | grep -E "(missed|fifo|crc|frame)"
确认有没有 tc 在静默丢包
这是生产环境最常被忽略的“幽灵丢包”：网卡统计清白，但流量就是少了。所有 tc 规则导致的丢包，完全不体现在 /proc/net/dev 或 ethtool -S 里。
- 检查规则：
tc qdisc show dev eth0
，盯netem、loss、policer关键字 - 看真实丢包数：
tc -s qdisc show dev eth0
，关注输出中dropped列是否在增长 - 容器环境要查虚拟接口：
calixxx、lxcxxx、vethxxx都可能挂了 tc 规则
误配的 tc qdisc add dev eth0 root netem loss 5% 会让 5% 出向包无声消失——删规则比调内核参数快得多：
tc qdisc del dev eth0 root
真正难的不是找哪个字段非零，而是判断“非零是否合理”：比如 rx_crc_errors 偶尔跳一下可能是瞬时干扰，但每秒稳定+1 就必须换线缆；rx_dropped 在 UDP 高峰期涨几百个，可能只是 net.core.rmem_max 设置偏小，而非故障。统计本身不会说话，得靠你把数字放进具体场景里读。
