监控实时带宽用iftop，查哪个进程在吃带宽用nethogs，抓原始包做深度分析用tcpdump；三者定位不同，混用易误判。
直接看结论：监控实时带宽用 iftop，查哪个进程在吃带宽用 nethogs，抓原始包做深度分析用 tcpdump——三者定位不同，混用反而容易误判。
iftop 实时看接口流量，但默认不显示进程
iftop 本质是监听网卡的原始数据包，靠 libpcap 汇总统计，所以它能快速给出 IP/端口级的实时吞吐，但看不到 PID 或进程名。常见错误是以为加了 -p 就能看进程，其实那个 -p 是“promiscuous mode”（混杂模式），跟进程无关。
- 必须加
sudo才能运行，否则报错socket: Operation not permitted - 用
-n关闭 DNS 解析，避免额外查询拖慢响应或污染流量 - 用
-P（大写）才显示端口号而非服务名，比如看到:80而不是:http - 想只看某网段，用
-F 192.168.1.0/24；想锁定某端口，得配合tcpdump过滤后分析，iftop本身不支持端口过滤
nethogs 按进程维度看流量，但无法跨主机聚合
nethogs 的核心价值是把流量和 pid、command 绑定，适合排查“谁在偷偷上传”。但它不汇总全网卡，只显示每个活跃进程的实时速率，且不能像 iftop 那样按连接排序。
- 安装后首次运行可能提示
Unable to open /dev/tty，说明没用sudo，别硬扛，直接sudo nethogs - 默认监听第一个非 loopback 接口，指定接口用
sudo nethogs eth0 - 按
m切换速率单位（KB/s → KB → B），按r反向排序，按q退出 - 它不记录历史，也不支持保存日志，要留痕得自己重定向输出：
sudo nethogs -t eth0 > /tmp/nethogs.log 2>&1
tcpdump 抓包分析，但别在生产环境裸跑
tcpdump 不是监控工具，是诊断工具。它把原始字节流打出来，不聚合、不美化，抓多了会卡死终端，甚至压垮磁盘 IO。关键是要学会用过滤器收窄范围，而不是“先抓了再说”。
- 最常用组合：
sudo tcpdump -i eth0 -nn -c 100 port 443（只抓 100 个 HTTPS 包，不解析域名和端口名） - 抓包文件体积大，用
-s 96截断包长（只取前 96 字节），够看 TCP 头和 HTTP header 就行 - 写入文件用
-w /tmp/out.pcap，之后用wireshark在图形界面里慢慢分析，别在服务器上用-A直接打印 ASCII——容易刷屏失联 - 如果目标是查丢包或重传，重点看
tcpdump -i eth0 'tcp[tcpflags] & (tcp-rst|tcp-syn) != 0'，而不是无差别抓全部
别忽略网卡本身的状态和采样粒度
所有这些工具都依赖内核暴露的统计信息，而底层网卡驱动或 offload 功能（如 LRO/GRO）可能导致数值偏差。比如 iftop 显示 RX 流量突增，但 /proc/net/dev 里对应接口的 bytes 收入没变，大概率是 GRO 合并导致的统计延迟。
- 验证真实吞吐，优先看
cat /proc/net/dev里的 raw bytes，这是内核最底层计数 -
vnstat的数据库是基于/proc/net/dev定时采样，所以它比iftop更稳定，但不够实时 - 容器环境里，
docker stats或podman top看的是 cgroup net_cls 统计，和宿主机iftop数值可能不一致，因为路径不同
