优先读/proc/net/dev因其是内核原生累计计数器，字段明确、零依赖、全发行版默认可用，rx_bytes和tx_bytes为真实字节数，适合脚本化采集与轻量检查。
直接看 /proc/net/dev 是最轻量、最可靠的方式——它提供内核原生的累计字节数和包数，不依赖额外工具，也不抓包、不干扰网络栈。
为什么优先读 /proc/net/dev 而不是用 iftop 或 nload
因为它是内核直接维护的底层计数器，单位是字节，字段含义明确，且所有 Linux 发行版默认可用。iftop 和 nload 实际上也是从这个文件读取数据再做计算和渲染；但它们会引入解析延迟、DNS 反解卡顿（iftop 不加 -n）、或单位混淆（比如把字节当比特）等问题。
-
rx_bytes和tx_bytes是真实收发字节数，不是估算值 - 输出不含 IP、端口、进程等上层信息——这反而是优点：避免误判（比如 DNS 卡住时 iftop 显示一堆
unknown host） - 适合写进监控脚本：一行
awk就能提取 eth0 的当前接收量：awk '/eth0/ {print $2}' /proc/net/dev - 注意：数值是自系统启动以来的累计值，不是实时速率；要算速率得两次采样后相减再除以时间间隔
ip -s link show dev eth0 看什么、不看什么
它和 /proc/net/dev 数据来源一致，但展示层级更低（OSI 第二层），重点在链路健康度，而非“用了多少带宽”。
- 真正该盯的字段：
RX: packets errors和TX: dropped carrier -
errors持续增长 → 物理层问题（网线松动、光模块衰减、驱动兼容性） -
dropped高 ≠ 网络丢包，而是内核发送队列满，常出现在突发流量打满网卡或宿主机桥接队列溢出时 -
carrier非零 → 物理链路反复断连，比如交换机端口 flapping - 它不显示 IP 地址、不显示速率（KB/s），也不能按连接或进程聚合 —— 别把它当 iftop 用
用 sar -n DEV 1 3 算实时速率最稳
如果你需要每秒多少 KB 的直观数字，sar 是唯一既免安装又自带速率计算的方案（前提是 sysstat 已启用）。它直接调用内核接口，采样间隔可控，输出单位统一为 KB/s 或 packet/s。
- 执行
sar -n DEV 1 3会输出三行采样，最后一行是平均值，字段如rxkB/s、txkB/s直接可读 - 对比
watch -n1 'cat /proc/net/dev | grep eth0'：后者只给累计值，你自己得手动算差值，容易算错单位或漏除时间 - 如果
sar未安装，CentOS 系统运行yum install sysstat，Ubuntu 运行apt install sysstat；装完通常自动启用 cron 日志采集 - 注意：
sar -n DEV默认统计所有接口，加-f /var/log/sa/sa$(date +%d)可查历史数据，但实时监控必须用实时采样参数
排查异常流量时最容易忽略的点
多数人盯着 “流量大不大”，却跳过两个关键验证步骤：确认数据来源层级、排除 lo 接口干扰。
- 先跑
ip link show确认你要查的接口名（比如是ens33而不是eth0），很多新发行版已不用 eth0 命名 - 所有工具默认可能包含
lo（回环接口），它的流量高不代表外网异常——iftop 默认不显示 lo，但cat /proc/net/dev和ip -s link都包含，务必过滤 - 容器或 K8s 环境下，
TX dropped高大概率是宿主机cbr0或docker0网桥队列满，不是容器内程序的问题 - 如果发现某个接口
rx_bytes几乎不增长，但业务连不上，别急着重启网卡——先用ethtool eth0看Link detected: yes和Speed:是否正常，物理层不通时上层统计永远为 0
