查实时网速用nload最省心，查哪个进程在吃带宽用nethogs最准，查连接级流量（如谁连了80端口）用iftop最合适；三者定位不同、互补共存，常需同时运行交叉验证。
直接看结论：查实时网速用 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/<pid>/fd/和/proc/<pid>/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 <pid> -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，因为容器出向流量会经iptablesSNAT 到宿主机 IP——此时得在宿主机上用nethogs监控物理网卡，再结合docker top <container>对 PID - 权限问题：
nethogs需要CAP_NET_RAW能力，普通用户执行会报Unable to create socket，必须加sudo；但sudo nethogs -p（混杂模式）在某些内核版本下会触发 SELinux 拒绝，得临时设为 permissive 模式
真正难搞的从来不是工具本身，而是网络栈分层带来的视角差：内核收包、iptables 修改、cgroup 限速、容器网络命名空间……这些都会让一个“简单”的网速数字变得上下不一致。别迷信单个工具的输出，交叉验证才是常态。
