在银河麒麟系统中需分层定位网卡丢包：用ip -s link show查dropped（协议栈丢弃）和missed（Ring Buffer溢出）；/proc/net/dev中Rx-DRP、Rx-OVR、Rx-ERR分别对应协议栈、硬件缓冲区、物理链路错误；ethtool -S挖掘驱动级细节；并检查tc限流规则是否主动丢包。
在银河麒麟操作系统中查看网卡统计丢包数据，不能依赖单一命令输出“丢包率百分比”，因为内核只记录绝对计数器，且不同字段反映不同层级的丢包原因——比如rx_dropped是协议栈丢弃，rx_missed_errors是Ring Buffer溢出，rx_crc_errors则指向物理链路故障。直接相除会得出错误结论，必须分层定位。
用 ip -s link show 查接收/发送侧丢包计数器
这是现代Linux标准命令，比废弃的ifconfig更清晰区分丢包层级。
执行 ip -s link show ens11f0（将ens11f0替换为你的真实网卡名），重点看RX和TX两段：
RX段中的【dropped】表示内核协议栈丢弃（如socket buffer满、反向路径过滤失败）；【missed】表示Ring Buffer溢出，属驱动/硬件层问题；这两项持续上涨才真正代表丢包。
TX段中的dropped多因队列满或驱动拒绝发包，若该值非零，需检查tx_queue_len设置是否过小。
单次执行无意义，应间隔5秒运行两次，取差值观察单位时间增长趋势。
查 /proc/net/dev 中的 Rx-DRP 和 Rx-OVR
这是最轻量、兼容性最好的入口，适用于所有麒麟版本。
执行 cat /proc/net/dev | grep ens11f0，定位到对应网卡行，关注Recv列下第4、5、6字段：
第4列是【Rx-DRP】：包已进Ring Buffer但被协议栈丢弃；
第5列是【Rx-OVR】：Ring Buffer溢出，DMA写入时直接覆盖旧包——这是硬件级丢包，说明驱动取包太慢；
第6列是【Rx-ERR】：驱动上报的硬件错误总和，非零即需立即用ethtool -S深挖。
若Rx-OVR持续上涨，优先调大Ring Buffer：sudo ethtool -G ens11f0 rx 4096。
用 ethtool -S 挖掘驱动级丢包细节
该命令输出网卡芯片寄存器原始值，字段因厂商而异，必须结合ethtool eth0确认Link状态后再解读。
方法一：快速筛查关键错误
运行 ethtool -S ens11f0 | grep -E "(rx_|tx_).*[dD]rop|fifo|miss|crc|frame)"。
别用grep -i drop——会漏掉rx_missed_errors等关键字段，也可能把tx_aborted_errors误当丢包。
方法二：针对性验证物理链路
若rx_crc_errors或rx_frame_errors非零且持续增长，基本可断定是线缆松动、光模块衰减或双工不匹配；
若rx_fifo_errors上涨，说明接收FIFO满，常见于高吞吐+低中断响应场景；
若rx_missed_errors显著增加，虚拟化环境中需检查vCPU调度是否过载。
确认有没有 tc 在主动丢包
很多“丢包”根本不是故障，而是人为配置的限流策略，完全不体现在网卡统计里。
第一步：检查规则是否存在
运行 tc qdisc show dev ens11f0，看输出中是否有netem、loss、policer等关键字。
第二步：查看真实丢包数
加-s参数：tc -s qdisc show dev ens11f0，重点关注dropped列是否在涨。
容器环境要特别小心：CNI插件（如Calico、Cilium）可能在host interface上挂了tc规则，别只查ens11f0，也检查cali+或lxc+类虚拟接口。
