真正代表丢包的字段是/proc/net/dev中的RX-DRP和RX-OVR：RX-OVR上涨说明Ring Buffer溢出，属驱动层瓶颈；RX-DRP上涨而RX-OVR为0则表明内核协议栈丢包，需检查softnet队列、socket缓冲区及NAPI处理延迟。
丢包率高不等于带宽打满，真正瓶颈常藏在内核协议栈内部——比如 socket 缓冲区溢出、softnet 队列堆积、NAPI 处理延迟或 SYN backlog 满。排查关键不是看“有没有丢”，而是确定“在哪一层丢”和“为什么来不及处理”。
盯住 /proc/net/dev 的 RX-DRP 和 RX-OVR
这是最快速的入口判断：
- RX-OVR 持续上涨 → Ring Buffer 溢出，问题在网卡驱动层，先查 ethtool -g eth0 看当前接收队列大小，再考虑调大（如 ethtool -G eth0 rx 4096）
- RX-DRP 上涨但 RX-OVR 为 0 → 包已进 Ring Buffer，却被内核协议栈丢弃，说明瓶颈在软中断或 socket 层
- 两者都涨 → 可能是 CPU 负载高导致驱动取包慢 + 协议栈消费更慢，需同步优化
检查 softnet 队列是否溢出
/proc/net/softnet_stat 第二列（dropped）反映 softnet 队列溢出次数：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 该值持续增长，说明 NAPI 轮询或 softirq 处理跟不上收包节奏
- 配合 cat /proc/interrupts | grep eth0 看中断是否集中在单个 CPU；若偏科严重，启用 RPS 分散负载：echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus（按实际 CPU 数调整掩码）
- 检查 net.core.netdev_max_backlog 是否过小（默认 1000），高并发场景建议调至 5000 或更高
定位 socket 层丢包原因
用 netstat -s | grep -A 5 -B 5 "drop\|overflow\|full" 查协议栈统计：
- Udp: receive buffer errors 非零 → UDP socket 接收缓冲区满，调大 net.core.rmem_default 和 rmem_max
- Tcp: packet receive errors 上升 → 可能是校验失败、IP 分片异常或端口未监听（InNoPorts 在 /proc/net/snmp 中体现）
- TCPSynRetrans 显著增加 → SYN 包被丢，常见于 net.ipv4.tcp_max_syn_backlog 不足或防火墙拦截
排除 tc 规则和 conntrack 干扰
很多“丢包”根本不是故障，而是人为策略：
- 运行 tc -s qdisc show dev eth0，重点看是否有 netem loss、policer 或 fq_codel 规则，以及 dropped 计数是否在涨
- 容器环境别只查 eth0，还要看 cali+、lxc+ 等虚拟接口上的 tc 规则
- 执行 conntrack -S，若 insert_failed 持续上升 → conntrack 表满，新建连接被静默丢弃，调大 net.netfilter.nf_conntrack_max
