Linux实时网速与带宽占用查看工具推荐

查实时网速用nload最省心，查哪个进程在吃带宽用nethogs最准，查连接级流量（如谁连了80端口）用iftop最合适；三者定位不同、互补共存，常需同时运行交叉验证。

开门见山，直接说结论：想要快速查看实时网速，nload 是最省心的选择；想要揪出是哪个进程在疯狂占用带宽，nethogs 最为精准；而想要看清连接级别的流量细节，例如谁在连接80端口，iftop 则最为合适。这三款工具定位各不相同，非但不冲突，在实际排查网络问题时，常常需要同时开启它们，进行交叉验证。

为什么不用 iftop 查进程带宽

许多人会误用 iftop 来查找进程，这是一个常见的陷阱。iftop 的核心功能是展示每个 socket 连接（IP+端口）的流量，但它并不会直接告诉你这个连接属于哪个进程。即使你加上 -P 或 -p 参数，它也只是进行端口解析，并不会去查询 /proc 文件系统来关联进程。因此，当你看到某个 IP:45678 的连接占满了带宽时，你依然无法立刻判断这是 curl 在下载，还是某个 python3 app.py 在后台发送数据包。

一个典型的错误现象是：使用 iftop -n 看到了高流量连接，但用 ps aux | grep :45678 却无法搜到对应的进程。这可能是因为端口已经释放，或者进程的命令行里根本没有暴露端口信息。

真正能够将进程和网络连接关联起来的工具是 nethogs。它的原理是直接读取 /proc//fd/ 和 /proc//net/tcp 等内核信息，天然支持按进程聚合流量。

从性能影响来看，两者也有区别：iftop 依赖 libpcap 抓包，如果开启混杂模式（-p），会轻微增加 CPU 开销；而 nethogs 通过轮询 /proc 获取数据，开销通常更小，但它无法捕获 UDP 碎片或内核模块直连的流量。

nload 的图表和单位容易误解

nload 使用起来很简单，但它的图表和单位设置也容易让人产生误解。它默认显示的是「当前瞬时速率」（单位是 KB/s 或 MB/s），而不是累计流量。问题在于，它那动态的柱状图纵轴没有刻度标识，新手很容易把柱子的瞬时峰值误认为是“总带宽”或“带宽上限”。实际上，它只反映采样时刻的吞吐量。

另外，nload 默认的采样刷新周期大约是 500 毫秒，这对于 HTTP/2 多路复用这类突发性的短连接流量可能不够敏感，图形上可能捕捉不到瞬间的峰值。

有几个关键参数可以帮你调整视图：nload -u M eth0 可以强制将单位固定为 MB/s，避免单位自动切换带来的困惑；nload -t 1000 则可以把刷新间隔设为 1 秒，让图形变化更平滑，避免视觉上的剧烈抖动。

还有一个容易踩的坑：在虚拟机或容器里直接运行 nload，看到的可能是宿主机物理网卡的聚合流量，而不是该容器实际的出口流量。正确的做法是进入容器的网络命名空间执行：nsenter -t -n nload。

兼容性上也需要注意，某些嵌入式 Linux 发行版（比如 OpenWrt）默认可能没有编译 curses 库支持，运行 nload 会报错 error opening terminal。这种情况下，可以换用 vnstat -l 来查看近一分钟的滚动流量统计。

nethogs 启动必须加设备名才可靠

使用 nethogs 时，一个必须牢记的要点是：启动时最好显式指定网卡设备名。如果不带参数运行，它会自动选择第一个非回环接口（通常是 eth0）。但如果你的系统有多个活跃网卡（比如 ens33、docker0、各种 vethxxx 虚拟设备），它很可能监控错了对象，导致出现“明明在传输大文件却看不到任何流量”的诡异情况。

正确的做法是，先用 ip -br a 命令确认你要监控的目标接口名称，然后显式指定：nethogs ens33。

在监控 Docker 容器流量时，情况会更特殊一些。你不能只盯着 docker0 这个网桥，因为容器出向的流量经过 iptables 的 SNAT 规则后，源 IP 会变成宿主机的 IP。此时，更有效的方法是在宿主机上用 nethogs 监控物理网卡（如 eth0），看到高流量进程的 PID 后，再结合 docker top 命令来核对，看该 PID 是否属于某个容器。

权限问题也不容忽视。nethogs 需要 CAP_NET_RAW 能力，普通用户执行通常会报错 Unable to create socket，所以必须加上 sudo。但注意，在某些内核版本下，使用 sudo nethogs -p（启用混杂模式）可能会触发 SELinux 的拒绝策略，这时可能需要临时将 SELinux 设置为 permissive 模式才能正常运行。

说到底，真正让网络流量监控变得复杂的，往往不是工具本身，而是现代 Linux 网络栈的多层抽象带来的视角差。内核收发包、iptables 规则修改、cgroup 带宽限制、容器的网络命名空间隔离……这些层层叠叠的机制，都可能让一个看似简单的“网速”数字在不同层面表现出不一致。因此，千万别迷信单个工具的输出结果，交叉验证才是运维工作中的常态。