Linux网卡丢包需分层定位：先查/proc/net/dev的Rx-OVR（Ring Buffer溢出）和Rx-DRP（内核丢包），再用ethtool -S分析rx_over_errors、rx_fifo_errors、rx_missed_errors、rx_dropped等驱动级指标，同时排查tc/qdisc人为丢包、软中断压力、conntrack耗尽及防火墙规则。
Linux 不会为每次丢包生成传统意义上的“日志行”（比如写入 /var/log/messages 的可读文本），内核丢包本身是快速路径上的静默行为，**没有默认开启的、带上下文描述的丢包日志**。想看到“谁在什么时候因为什么丢了哪个包”，必须主动启用对应子系统或使用观测工具抓取内核内部信号。
netstat -i 中的 RX-DRP 和 RX-OVR 是什么
这是最常被误认为“丢包日志”的指标，但它只是计数器，不带时间、协议、源/目的信息：
-
RX-DRP：数据包已进入网卡 Ring Buffer，但在从 buffer 拷贝到内核内存时因内存不足等系统原因被丢弃（softnet_data.dropped的一部分） -
RX-OVR：Ring Buffer 满了，新包根本进不来——硬件层直接丢，CPU 都没机会响应中断 - 二者都只在
netstat -i或cat /proc/net/dev里以累计值呈现，无法回溯单次丢包事件
/proc/net/softnet_stat 能告诉你什么
这个文件反映的是软中断（NET_RX）处理瓶颈，每行对应一个 CPU：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 第 1 列：
total—— 该 CPU 收到的总包数 - 第 2 列：
dropped—— 因netdev_max_backlog溢出被丢的包数（即队列满后新包直接扔掉） - 第 3 列：
time_squeeze—— 软中断一次处理不完，被迫多次调度的次数（高值说明 CPU 处理不过来） - 它不告诉你丢的是 TCP 还是 UDP，也不告诉你 src/dst IP，但能确认是否是内核接收路径拥塞导致的批量丢包
真正能定位丢包原因的内核机制
以下方法才能把“丢包”和具体原因挂钩，不是日志，但效果远超日志：
-
iptables -j LOG+syslog：仅对匹配规则的包打日志，适合排查防火墙误 DROP；需提前配置，且性能开销大 -
tc qdisc netem loss X%的统计字段（tc -s qdisc show dev eth0）：明确显示“本 qdisc 主动丢了多少包”，含dropped计数和触发条件 -
bpftrace -e 'kprobe:tcp_v4_do_rcv { @drops = count(); }'：跟踪内核函数入口，配合条件过滤（如args->skb->len ）可定位异常丢包点 -
perf record -e skb:kfree_skb -e net:netif_receive_skb：用 perf 抓包生命周期事件，再用perf script关联丢包前后调用栈
关键点在于：Linux 内核丢包没有“日志开关”一键打开，/proc 下的统计值只是结果快照，真要定位到“为什么丢”，得靠 tc 统计、bpftrace 跟踪或 perf 采样——它们不输出文本日志，但能给出精确到函数、CPU、甚至 skb 结构体的上下文。
