nethogs是唯一能原生按进程维度实时显示吞吐（KB/s、MB/s）的命令行工具，直接读取内核socket计数器，需sudo权限，支持按发送/接收排序及单位切换。
直接看进程实时带宽：用 nethogs 最快最准
想立刻知道哪个进程在发多少、收多少，nethogs 是唯一能原生按进程维度显示实时吞吐（KB/s、MB/s）的命令行工具。它不依赖 DNS、不抓包、不采样，直接读取内核网络命名空间中的 socket 流量计数器，延迟低且结果可信。
常见错误是没加 sudo——它必须有 CAP_NET_ADMIN 权限才能访问进程级 socket 统计，不加会报错 Unable to get pid from /proc/net/tcp 或界面空白；另外容器环境（如 Docker、Podman）中若未共享主机网络命名空间，nethogs 默认看不到容器内进程，得指定 -t 选项或进对应 netns 手动执行。
实操建议：
- 运行
sudo nethogs -d 2 eth0：每 2 秒刷新一次，聚焦eth0网卡 - 按
s键按发送排序，r键按接收排序，m切换单位（推荐从KB/s起手，避免小流量被四舍五入为 0） - Java、Node.js 等多线程服务常统一显示为
java或node，需记下 PID 后补查：ps -o pid,cmd -p <pid></pid> - 若输出中
SENT/RECEIVED长期为 0，但vnstat显示网卡有流量，说明该流量来自内核模块（如 iptables 规则转发、bonding 子接口）或 systemd socket 激活服务（尚未真正 fork 出进程）
查历史走势与物理带宽对比：必须提前部署 vnstat
vnstat 不是实时监控工具，它是靠轮询 /proc/net/dev 累积计数器生成趋势报告的。这意味着——没提前装、没初始化，就永远看不到“昨天三点是否飙高”这类关键信息。很多故障复盘卡在这一步，不是不会查，而是数据根本不存在。
物理带宽上限（比如千兆网卡理论峰值 1000 Mbps ≈ 125 MB/s）不能直接从 vnstat 输出读出，得人工比对：它的 rx/tx 单位是 KiB 或 MiB，而网卡标称带宽单位是 Mbit/s，换算时注意 8 倍关系。
实操建议：
- 装好后立即执行
sudo vnstat -u -i eth0初始化数据库，否则后续所有-h（小时）、-d（天）查询都为空 - 查最近 24 小时每小时峰值：
vnstat -i eth0 -h | awk '{print $3,$4}' | tail -n +3 | sort -nr | head -5，快速定位异常时段 - 对比物理上限：若
vnstat -i eth0 -h显示某小时tx均值达 95 MiB/s，即 ≈ 760 Mbit/s，已逼近千兆网卡能力边界，此时再看nethogs排名第一的进程是否合理 - 别信
vnstat -l实时模式——它只是滚动显示最近两分钟平均值，不是真实时，且无法回溯
需要精确到连接+进程双维度时：组合 iftop -n -N + lsof -i
当 nethogs 显示某个 PID 占用高，但你怀疑是多个连接叠加（比如一个 Python 进程开了 200 个 HTTP 长连接），就得下钻到连接粒度。这时 iftop 是唯一能直观展示 “A IP:A端口 → B IP:B端口” 实时速率的工具，但它本身不关联进程，必须配合 lsof 反查。
容易踩的坑是 DNS 解析拖慢响应甚至卡死界面：iftop 默认反向解析 IP 为域名，一旦遇到 DNS 不稳或恶意扫描 IP，会阻塞几秒才显示一行。生产环境务必加 -n（禁 DNS）和 -N（显端口号而非服务名）。
实操建议：
- 先运行
sudo iftop -n -N -i eth0 -P tcp，专注 TCP 连接，避免 UDP 噪声干扰 - 看到可疑连接如
10.1.2.3:45678 => 198.51.100.42:443，复制远端 IP 和本地端口，执行sudo lsof -i :45678查归属进程 - 若
lsof返回空，说明该连接可能由内核模块（如 ip_vs、nf_conntrack）建立，或属于已退出但 socket 尚未完全关闭的 TIME_WAIT 状态，此时应检查ss -tni | grep :45678 - 别用
netstat替代ss：前者在高并发连接下性能差、输出冗长，ss -tni更轻量且含重传、RTT 等底层指标
为什么不用 pidstat -d 查网络 IO？
pidstat -d 名义上支持网络 I/O 统计，但实际在绝大多数主流内核（5.4+）和发行版中，它只返回 0 或极小值，因为 pidstat 依赖的 /proc/[pid]/io 文件不记录网络 socket 的读写量，只记录文件/块设备 IO。这是内核设计决定的，不是配置问题。
有人尝试用 pidstat -d 1 监控某进程，发现 kB_rd/s 和 kB_wr/s 始终为 0，却看到 nethogs 同一 PID 在跑 10 MB/s——这不是工具错了，是它压根不统计网络路径。硬要用 pidstat，只能配合 -r（内存）或 -u（CPU）做交叉验证，比如确认高带宽进程是否也伴随高 CPU 使用率。
所以，别把 pidstat -d 当作网络 IO 工具用。它适合查磁盘读写瓶颈，不适合查网卡。
