网卡丢包率过高本质是数据“进不来”或“来不及处理”，需沿物理链路→Ring Buffer→驱动→NAPI→netdev_max_backlog→应用层路径分层排查：先用/proc/net/dev区分Rx-DRP（协议栈入口丢）与Rx-OVR（硬件溢出丢），再查softnet_stat、中断分布、tc/iptables策略及应用Recv-Q/somaxconn瓶颈。
网卡丢包率过高，本质是数据“进不来”或“来不及处理”。排查不能只盯着“丢了多少”，而要顺着数据包进入系统的路径一层层查——从物理链路到内核协议栈入口，每一步都可能成为瓶颈。关键不是找一个命令，而是建立分层验证逻辑。
看网卡统计：先确认丢包是否真实存在
执行 cat /proc/net/dev，找到对应网卡（如 eth0），重点关注两列：
- Rx-DRP：内核已接收但主动丢弃的包。非零说明问题在驱动之后、协议栈之前（比如 netdev_max_backlog 不足、软中断压满、内存紧张）
- Rx-OVR：Ring Buffer 溢出导致硬件丢包。非零说明网卡收得太快，驱动取太慢，优先调大 Ring Buffer（ethtool -G eth0 rx 4096）并检查 CPU 负载与中断分布
注意：别用 grep -i drop，它会混入 tx_dropped（出口队列丢包）、iptables 过滤等伪丢包；rx_errors 是 CRC/帧错误，反映物理链路质量差，不等于丢包。
查软中断与 NAPI 处理能力
丢包若集中在业务高峰且节点间不一致，大概率是软中断（NET_RX）处理不过来。运行：
- cat /proc/net/softnet_stat：看第2列（dropped）。持续增长说明 skb 在进入协议栈前被丢，常见于 net.core.netdev_max_backlog 设置过小
- mpstat -P ALL 1：观察各 CPU 的 %soft 值。若某核心长期 >30%，且该核承载了大部分网卡中断（cat /proc/interrupts | grep eth0），说明中断未均衡，需绑定 irqbalance 或手动设置 smp_affinity
排除 tc、iptables 等“隐身丢包源”
网卡统计清白，但业务仍丢包？可能是人为策略在中间截胡：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- tc qdisc show dev eth0：检查是否有 netem（模拟丢包）、policer（限速丢包）或 fq_codel（主动丢包控拥塞）。看到 loss xx% 或 dropped N 字样，就是真凶
- iptables -t mangle -vnL POSTROUTING：部分自定义规则（如 TPROXY、MARK+route）可能触发异常丢包，尤其在高并发下
这些丢包完全不会体现在 /proc/net/dev 或 ethtool -S 中，是生产环境最常被忽略的“幽灵瓶颈”。
验证应用层接收是否跟得上
即使协议栈没丢，应用读太慢也会造成假性丢包感：
- ss -tan state established | awk '{print $2,$3}' | sort | uniq -c | sort -nr | head：看哪些连接的 Recv-Q 长期 >0，表示内核接收缓冲区堆积，应用未及时 read()
- netstat -s | grep -A5 "packet receive errors"：关注 “times the listen queue of a socket overflowed”，说明 accept 队列满（somaxconn 不足或进程 accept 太慢）
此时调高 net.core.somaxconn 和应用线程数，比优化网卡参数更直接有效。
