应直接用ip -s link show dev 网卡名查看，RX errors是物理层错误总和（如CRC、帧长错），持续增长指向网线松动、光衰或双工不匹配；RX dropped是内核主动丢弃，常见于socket缓冲区满或net.core.netdev_max_backlog不足；TX errors罕见，非零需查carrier/aborted；TX dropped多因qdisc队列满或驱动缓冲区溢出。
直接用 ip -s link show dev 网卡名 查看，重点盯 RX/TX 下的 errors 和 dropped 字段——它们分别反映物理层错误和内核主动丢弃，不是一回事。
怎么看 RX/TX errors 和 dropped 的真实含义
RX 块里的 errors 是硬件级错误总和（如 CRC 校验失败、帧长度错），持续上涨说明网线松动、光模块衰减或双工不匹配；dropped 是内核协议栈丢弃，常见于 socket 缓冲区满、反向路径过滤触发或 net.core.netdev_max_backlog 不足。
TX 块里的 errors 很少见，非零时要查 carrier（链路反复断连）或 aborted（发送重试失败）；dropped 多因 qdisc 队列满、TC 限速或驱动缓冲区溢出。
怎么正确执行命令并避免误读
- 先确认网卡名：
ip link show或ls /sys/class/net/ | grep -v lo - 加
-h参数让单位自动换算：ip -s -h link show dev ens33 - 别用
ifconfig或netstat -i：字段模糊、统计口径旧，errs列不区分类型，容易把rx_crc_errors和rx_dropped混为一谈 - 单次数值没意义，要两次取差值看趋势——比如隔 10 秒运行两次，对比
errors是否增长
发现 errors 上涨后该查什么
errors 非零且持续涨，说明问题在物理层或驱动侧，下一步必须用 ethtool 深挖：
- 查链路状态：
ethtool ens33看Link detected、Speed、Duplex是否正常 - 查底层寄存器：
ethtool -S ens33 | grep -E "(crc|frame|fifo|miss)" -
rx_crc_errors > 0→ 线缆接触不良或交换机端口故障 -
rx_missed_errors或rx_no_buffer持续涨 → ring buffer 太小，调大：ethtool -G ens33 rx 4096 -
rx_over_errors高 → 接收 FIFO 溢出，和 CPU 负载、RPS/RFS 绑定强相关
别被 /proc/net/dev 的 errs 值带偏
/proc/net/dev 第三列 errs 和 ifconfig 的 RX errors 同源，它只是驱动上报的 RX 错误总和，部分虚拟网卡或老驱动会一直为 0，即使实际有错包；而且它不实时更新、不区分错误类型。真正可信的是 ip -s link 的 rx_errors：它直连 netlink，维度细、刷新准。如果它非零而 /proc/net/dev 为 0，信前者。
