iftop可按连接实时排序带宽占用，需sudo iftop -n -P -N查看源IP→目标IP的TX/RX速率；-n禁DNS解析防卡顿，-P显端口，-N禁服务名转换，避免误判lo接口或DNS异常导致的unknown host。
用 iftop 看实时网络连接的流量排行
iftop 是最直接的工具，它按连接（源IP:端口 → 目标IP:端口）实时排序带宽占用，类似 top 之于CPU。默认只显示 IPv4 的 TCP 连接，且需 root 权限才能看到进程名（否则只显示 IP 和端口）。
常见错误：直接运行 iftop 不加 -P 或 -f，结果看不到具体端口或被防火墙规则干扰；不加 -n 时 DNS 反解会卡顿，尤其在无 DNS 响应的环境。
- 看当前网卡（如
eth0）的实时连接排行：sudo iftop -n -P -N（-n关闭域名解析，-P显示端口，-N不转换端口为服务名） - 指定接口：
sudo iftop -n -P -N -f "port 80 or port 443" -t（-f加过滤表达式，-t启用文本模式便于重定向） - 注意：若显示
unknown host或大量*.*.*.*，大概率是未加-n且本地 DNS 不通；若所有连接都显示127.0.0.1，检查是否误选了lo接口
用 ss + lsof 定位耗带宽的进程 PID
ss 比 netstat 更快更准，能快速列出所有 ESTABLISHED 连接及其 inode；lsof 则通过 inode 反查进程。这是没有 iftop -P 权限时的兜底方案。
关键点在于：必须用 sudo，否则 ss 能看到连接但 lsof 查不到对应进程；且 ss -tunap 中的 a（all）和 p（process）缺一不可。
- 一步定位高流量连接的进程：
sudo ss -tunap | grep ESTAB | sort -k7,7nr | head -5（按第7列——即发送字节数——倒序排，取前5） - 若输出中
pid字段为空（如显示-），说明该 socket 属于内核线程或权限不足，此时改用sudo lsof -i -P -n | grep ESTABLISHED | sort -k9,9nr | head -5（lsof第9列通常是发送字节） - 注意：
ss默认不统计已发送/接收字节数，需配合/proc/net/snmp或/proc/net/nf_conntrack手动关联；所以实际排查时更依赖连接频次、并发数、目标地址异常性（如大量连同一外网IP）来判断“耗带宽”
用 nethogs 按进程维度实时监控流量
nethogs 是唯一真正按进程（而非连接）聚合带宽的命令行工具，适合快速识别哪个 python 或 curl 实例在刷流量。但它不支持容器内监控，且对多线程程序（如 Chrome）可能只显示主线程名。
安装后首次运行常报错 Unable to get pid of process，基本是 SELinux 或 cgroups v2 限制导致；普通用户运行则只能看到自己的进程。
- 基础使用：
sudo nethogs eth0（指定网卡，避免混杂模式干扰） - 按上传/下载排序：
sudo nethogs -s eth0（-s按发送速率排序） - 导出快照用于分析：
sudo nethogs -t eth0 | head -20（-t文本模式，可管道处理） - 注意：若进程名显示为
unknown TCP，说明该连接由内核模块（如nf_conntrack_ftp）创建，无法关联到用户态进程
为什么 cat /proc/net/dev 不适合查“哪个进程”耗带宽
/proc/net/dev 只提供网卡总收发字节数，是设备层统计，完全不涉及进程、连接、协议。它适合判断“整机是否跑满”，但无法回答“谁在用”。有人试图用两次采样做差值再除以时间算平均速率，这依然得不到进程粒度信息。
更隐蔽的坑是：某些驱动（如 veth 在容器场景）或 offload 功能（如 GSO、TSO）会让 /proc/net/dev 的数值与实际 IP 层流量不一致，导致误判。
- 正确用途：配合
watch -n1 'cat /proc/net/dev'快速确认网卡是否打满（比如eth0RX 大于 900MB/s 表示接近千兆瓶颈） - 错误联想：看到
lo流量高就认为是本地服务问题——其实可能是 Docker bridge 或 Kubernetes CNI 的内部转发，真实源头仍在外部进程 - 真正需要进程级归因时，必须回到
iftop、nethogs或ss+lsof这三条路径，别在/proc/net/dev上浪费时间
真正的难点不在命令怎么敲，而在于区分“瞬时峰值”和“持续占用”：iftop 刷屏快，但 2 秒没动静的连接未必清零；nethogs 显示的 KB/s 是滑动窗口均值，短时 burst 可能被平滑掉。盯住目标进程后，还得结合 strace -p $PID -e trace=sendto,recvfrom 看它到底在发什么。
