监控网络接口丢包需分层采集：用 ip -s link 查 errors/dropped 趋势，ethtool -S 定位具体错误类型（如 rx_crc_errors、rx_missed_errors），/proc/net/dev 辅助比对，再检查 tc qdisc 是否存在静默丢包规则。
Linux 中监控网络接口的错误包与丢包，关键在于分层采集、交叉验证，不能只看一个数字。物理层错误、驱动层溢出、内核协议栈丢弃，成因不同，统计位置也不同。
用 ip -s link 查实时聚合统计
这是最轻量、最可靠的第一步，无需安装额外工具：
- 运行 ip -s link show eth0（把 eth0 换成你的实际接口名），重点关注 RX 和 TX 下的 errors 和 dropped 字段
- RX errors 表示接收方向硬件/驱动级错误总和（如 CRC 错、帧错、FIFO 溢出），持续上涨基本指向物理链路或驱动问题
- RX dropped 表示包已进 Ring Buffer，但在内核协议栈中被主动丢弃（如 socket 队列满、内存不足、反向路径过滤失败）
- 注意：单次数值无意义，要两次执行取差值，观察单位时间内的变化趋势
用 ethtool -S 定位具体错误类型
ip -s 只给总数，真正要归因，得深入驱动寄存器：
- 先确保已安装：sudo apt install ethtool（Debian/Ubuntu）或 sudo yum install ethtool（RHEL/CentOS）
- 运行 ethtool -S eth0 | grep -i "error\|drop\|miss"，重点盯这些字段：
- rx_crc_errors：非零且增长 → 网线松动、光模块衰减、双工不匹配
- rx_missed_errors：虚拟化环境尤其关键，上升说明 vCPU 调度延迟或宿主机 CPU 过载
- rx_fifo_errors 或 rx_over_errors：Ring Buffer 太小或中断处理不及时，可尝试 ethtool -G eth0 rx 4096 扩大接收队列
- rx_dropped：与 ip -s 中的 dropped 含义接近，但更底层，确认是否为驱动上报的真实丢弃
- 不同网卡芯片字段名不同（如 Intel igb 与 Broadcom bnxt），别只靠关键词，先用 ethtool eth0 确认 Link 状态、速率、双工模式是否正常
查 /proc/net/dev 辅助比对
这个文件是内核通用统计入口，适合脚本轮询，但要注意局限性：
- 字段固定：第5列是 rx_errors，第13列是 rx_dropped，解析时务必按空格分割并 trim，避免 tab 干扰
- 它不是采样值，而是驱动累加的计数器，只要驱动正常上报，数据就是准的
- 但部分虚拟网卡或老驱动可能不更新该文件中的 errs 列，长期为 0；若发现 /proc/net/dev 显示 0 而 ip -s 显示非零，优先信后者
- 需自行处理计数器回绕（uint32_t 满值后归零），两次采样间隔不宜过短（建议 ≥1 秒），否则可能误判丢包突增
排除人为配置导致的“静默丢包”
很多丢包根本不在网卡统计里，而是由流量控制规则悄悄吃掉的：
- 运行 tc qdisc show dev eth0，检查是否有 netem、loss、policer、fq_codel 等关键字
- 加 -s 参数看真实丢包数：tc -s qdisc show dev eth0，关注输出中 dropped 列是否持续增长
- 容器环境要扩展排查范围：CNI 插件（如 Calico、Cilium）常在 cali+ 或 lxc+ 虚拟接口上挂 tc 规则，不能只查物理口 eth0
- 误配 tc qdisc add dev eth0 root netem loss 5% 就会导致 5% 出向包被静默丢弃，删掉规则即可恢复
