直接看/proc/net/dev的rx-drp和rx-ovr是最贴近收包路径的实时丢包计数入口，rx-drp表示包已进ring buffer但被内核协议栈丢弃，rx-ovr表示ring buffer溢出导致硬件级丢包；两者非零需分别排查内核参数或调大ring buffer。
直接看 /proc/net/dev 里的 Rx-DRP 和 Rx-OVR
这是最贴近收包路径的实时丢包计数入口，不依赖驱动实现，所有主流网卡都支持。它反映两个关键丢包点：Rx-DRP 是包已进 Ring Buffer 但被内核协议栈丢弃（比如 socket buffer 满、无监听端口）；Rx-OVR 是 Ring Buffer 溢出，网卡 DMA 写入时直接覆盖旧包——硬件级丢包。
执行 watch -n1 'cat /proc/net/dev | grep eth0'，盯着这两列数字是否持续上涨。注意：不要用 ifconfig 的 dropped 字段，它统计口径不同，且不包含 OVR。
-
Rx-OVR非零且增长快 → 优先调大 Ring Buffer：ethtool -G eth0 rx 4096 -
Rx-DRP持续涨 → 查netstat -s -u | grep "receive buffer errors"，确认是不是net.core.rmem_max太小或应用读太慢 - 如果两列都是 0，但业务明显丢包 → 往上查
tc qdisc或 iptables，不是网卡问题
ip -s link 显示的 dropped 和 overrun 不是同一层
ip -s link show eth0 输出里，RX: dropped 和 RX: overrun 看似都是“丢包”，但来源完全不同：dropped 是内核网络设备子系统（netdev）在 NAPI 处理阶段主动丢弃，常见于软中断瓶颈或 CPU 负载高；overrun 是 Ring Buffer 溢出，本质和 /proc/net/dev 的 Rx-OVR 同源。
两者都非零且同步增长，说明问题在驱动或中断处理；只有 overrun 高而 dropped 为 0，则更可能是 Ring Buffer 太小，而不是 CPU 不够用。
- 加
-h参数让输出易读：ip -s -h link show dev eth0 -
TX: dropped多由 qdisc 限速触发（如tc netem loss），和发送队列满无关 -
carrier非零 → 物理链路反复断连，查网线、光模块或交换机端口
用 ethtool -S 看驱动原生丢包字段
/proc/net/dev 和 ip -s link 是通用接口，ethtool -S eth0 才是驱动原生统计，字段更细、定位更准。但它不保证所有网卡都支持——老芯片、veth、部分 USB 网卡可能返回 No data available，这不是故障，是驱动没实现。
运行 ethtool -S eth0 | grep -i "drop\|fifo\|miss\|crc"，重点关注：
-
rx_fifo_errors或rx_over_errors→ 对应Rx-OVR，FIFO 溢出 -
rx_missed_errors→ Ring Buffer 满来不及收，常因中断响应慢或 CPU 过载 -
rx_crc_errors、rx_frame_errors→ 物理层错误，指向线缆、光衰、双工不匹配 - 若
rx_fifo_errors远大于/proc/net/dev的Rx-OVR→ 可能启用了 XDP/DPDK，标准路径统计失效
mtr 的 Loss% 是唯一真正“实时”的丢包率
ping 只能算整段平均丢包，mtr 才是每秒向每一跳发包并滚动更新 Loss%。这个值不是总和，而是最近若干次探测的丢包比例，能反映瞬时抖动。
启动命令推荐：mtr -r -c 50 -n 223.5.5.5（-r 报告模式，-c 50 发 50 包，-n 跳过 DNS）。重点看首跳（本地网关）：Loss% > 0 通常意味着本机网卡、驱动或防火墙问题，不是远端的事。
- 某跳
Loss% = 100但下一跳正常 → 大概率该节点禁 ICMP，不是物理断连 -
StDev > 50ms且Loss% > 0→ 该节点存在队列拥塞或设备过载 - 别用
-i 0.1太密发包，容易被中间设备限速，造成假性丢包
Rx-OVR 上涨，背后可能是 CPU 调度延迟、Ring Buffer 大小、中断亲和性、甚至 BIOS 中的节能设置——这些细节不会自动出现在任何一条命令的输出里。
