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

Linux系统中实时监控网络流量需根据具体需求选择互补工具：nload适合直观查看网卡瞬时速率，nethogs精准定位高带宽消耗的进程（直接关联PID与流量），iftop则擅长分析连接级细节（如哪个IP和端口在通信）；但三者各有局限——iftop无法显示进程名，nload易被图表误导且受虚拟化环境影响，nethogs依赖正确指定网卡并需sudo权限；真正可靠的诊断从来不是依赖单一工具，而是结合三层视角交叉验证，穿透内核收包、iptables规则、容器网络等层层抽象，直击真实带宽归属。

直接看结论：查实时网速用 nload 最省心，查哪个进程在吃带宽用 nethogs 最准，查连接级流量（比如谁连了 80 端口）用 iftop 最合适——三者不冲突，经常要一起开。

为什么不用 iftop 查进程带宽

iftop 显示的是每个 socket 连接的流量（IP+端口），但它不显示所属进程名或 PID。即使加了 -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），不是累计量，但它的柱状图纵轴没有刻度标识，新手常误以为峰值就是“总带宽”。实际它只反映瞬时吞吐，且默认采样周期约 500ms，对突发短连接（如 HTTP/2 多路复用）不敏感。

• 关键参数：nload -u M eth0 强制单位为 MB/s；nload -t 1000 把刷新间隔拉到 1 秒，避免视觉抖动
• 容易踩的坑：在虚拟机或容器里跑 nload，看到的可能是宿主机网卡聚合值，而非容器实际出口流量；此时应进容器 ns 执行：nsenter -t -n nload
• 兼容性注意：某些嵌入式 Linux（如 OpenWrt）默认没编译 curses 支持，nload 会报错 error opening terminal，得换 vnstat -l 看近一分钟滚动统计

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

运行 nethogs 不带参数时，它会自动选第一个非 lo 接口（通常是 eth0），但若系统有多个网卡（比如 ens33、docker0、vethxxx），它可能监控错设备，导致“明明在传大文件却看不到流量”。

• 正确做法：先用 ip -br a 确认目标接口名，再显式指定：nethogs ens33
• 特殊场景：监控 Docker 容器流量，不能只盯 docker0，因为容器出向流量会经 iptables SNAT 到宿主机 IP——此时得在宿主机上用 nethogs 监控物理网卡，再结合 docker top 对 PID
• 权限问题：nethogs 需要 CAP_NET_RAW 能力，普通用户执行会报 Unable to create socket，必须加 sudo；但 sudo nethogs -p（混杂模式）在某些内核版本下会触发 SELinux 拒绝，得临时设为 permissive 模式

真正难搞的从来不是工具本身，而是网络栈分层带来的视角差：内核收包、iptables 修改、cgroup 限速、容器网络命名空间……这些都会让一个“简单”的网速数字变得上下不一致。别迷信单个工具的输出，交叉验证才是常态。

以上就是《Linux实时网速与带宽查看工具推荐》的详细内容，更多关于的资料请关注golang学习网公众号！