应直接用ip -s link show dev 网卡名查看rx/tx errors：rx_errors是物理层错误总和，持续增长指向网线、光模块或双工问题；tx_errors罕见，非零需查carrier/aborted类错误；rx_dropped/tx_dropped属内核主动丢弃，非硬件故障。
用 ip -s link show 查聚合错误数（最轻量、必先做）
ip -s link show 是所有现代 Linux 发行版自带的命令，无需安装额外工具，适合第一时间判断是否存在底层问题。它输出的 RX errors 是物理层错误的总和，包括 rx_crc_errors、rx_frame_errors、rx_length_errors 等。
- 执行
ip -s link show eth0 | grep -A 2 "RX:"，重点关注输出中类似这行的数字：RX: bytes packets errors dropped overruns mcast 12345678 12345 42 0 0 0 -
errors这一列非零且随时间持续上涨，基本可断定是物理链路或驱动问题，不是配置错误 -
dropped和overruns属于协议栈或 ring buffer 问题，和 CRC 类错误无关，别混为一谈 - 如果你用
ifconfig eth0看到RX errors非零，那只是ip -s link的镜像输出；但注意：CentOS 7 默认可能没装net-tools，ifconfig不一定可用
用 ethtool -S 定位具体错误类型（必须装、关键一步）
ip -s link 只告诉你“错了”，ethtool -S 才能告诉你“哪类错”。它读取网卡驱动寄存器，暴露真实硬件级计数器。
- 先确认已安装：
sudo yum install ethtool - 运行
ethtool -S eth0 | grep -i "crc|frame|miss|over"快速过滤关键字段 - 常见对应关系：
-
rx_crc_errors高 → 网线松动、交换机端口故障、线缆质量差 -
rx_missed_errors高 → ring buffer 太小或中断处理不及时，不是物理层问题 -
rx_over_errors或rx_fifo_errors→ 接收 FIFO 溢出，常与驱动或队列设置有关
-
- 某些高端网卡（如 Intel X710、Mellanox）还会暴露
rx_out_of_buffer，说明内核来不及消费数据，需调大rx ring size
别信 /proc/net/dev 的 errs 列（容易误判）
/proc/net/dev 第三列叫 errs，但它只是 ip -s link 中 RX errors 的静态镜像，且存在严重缺陷：
CentOS Linux 7.9.2009
下载
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离线兼容性测试。
- 它只统计接收方向，不包含 TX 错误
- 部分驱动（尤其是虚拟网卡、老芯片如 Realtek RTL8139）根本不会动态更新该值，可能长期为 0 即使实际错包猛涨
- 它的
drop列对应的是rx_dropped，但无法区分丢包原因（是 netdev backlog full？还是 skb allocation failure？） - 如果你看到
/proc/net/dev中errs为 0，但ip -s link show显示非零，优先信后者
为什么不用 netstat -i 查错包
netstat -i 的 errs 列和 /proc/net/dev 同源，且更不实用：
- 它把 RX 和 TX 错误合并成一列，掩盖单向故障（比如只有接收出错，发送完全正常）
- 不显示
dropped、overruns、frame等细分项，诊断价值远低于ip -s或ethtool -S - 新版系统中
netstat已被ss取代，而ss根本不提供接口级统计功能
真正要定位 CRC 类错误，必须走 ip -s link → ethtool -S 这条路径。中间跳过任意一步，都可能把物理层问题误判成配置或应用层问题。
