SeigRobotics1. 先搞清楚iftop到底是“库”还是工具，以及哪些场景非它不可
我第一次接触“CentOS下iftop库的使用”这个说法时愣了一下，因为iftop严格来说不是一个“库”，而是一个命令行下的实时流量监控工具。它全称是Interface TOP，逻辑上和top命令类似——top监控的是进程对CPU、内存的占用，iftop监控的是网卡上每个连接对流量的占用。很多人会把它和boost、eigen、libevent这类C++/C库混在一类关键词里去搜，但它们完全不是一个层面的东西。iftop运行起来是一个交互式界面，不是供你写代码时include的头文件；它唯一的“库依赖”是libpcap，因为底层要靠它去抓取经过网卡的数据包，从而按连接维度统计流量。
那这个工具到底能解决什么问题？我用一个实际场景来说明。去年有一台业务服务器，深夜突然被投诉访问卡顿。登录上去一看，CPU和内存都正常，负载也不高，但外网出方向带宽被打到了接近300Mbps——而我们的带宽上限是200Mbps。这个时候用top看不到任何异常，因为不是进程把CPU跑满了，而是某个连接在疯狂发包。这种情况你去看系统的实时流量，只看到总速率异常，却不知道是谁在占。iftop就是干这个的：它会按照“源IP -> 目标IP”把每一条活跃连接的速率列出来，哪个IP在偷跑带宽，一眼就能扫出来。
除了排查带宽被打满，iftop在另外几个场景里也很好用。比如你在内网发现某台机器访问共享存储特别慢，可以在存储服务器上看看到底是哪个客户端在大量读写；比如你怀疑有机器中了挖矿木马，木马进程一般不会让你的CPU飙升到100%，但会持续向外网某个IP发送数据，iftop的按IP聚合功能可以直接暴露出这些异常目标地址；再比如你想验证一下自己配的限速策略是否生效，也可以临时开着iftop观察一下对应IP的速率变化。
说回“库”这个叫法。我猜这个搜索词的来源，大概率是有人把“iftop工具”误写成了“iftop库”，也可能是搜索引擎把“CentOS下ifconfig、iftop等工具的使用”这类文章里的词汇做了错误关联。不管怎样，阅读本文时你只需要记住：iftop是一个运维排障工具，不是什么开发库。学会它的安装、界面阅读和参数组合，就能解决很多网络层面的疑难杂症。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. CentOS安装iftop的三个主流路线与依赖坑
安装iftop不算复杂，但不同CentOS版本、不同网络环境，走的路线差别很大。我在CentOS 7.9、CentOS 8、CentOS Stream 9上都装过，把踩过的坑一并写出来。
2.1 yum/dnf安装：最快的路线，但要先搞定源
CentOS 7自带的base源里默认没有iftop，直接执行：
bash复制yum install -y iftop
大概率会提示No package iftop available。正确姿势是先装EPEL（Extra Packages for Enterprise Linux）源：
bash复制yum install -y epel-release
yum install -y iftop
EPEL源里的iftop版本通常足够用，而且会自动帮你装好libpcap依赖。CentOS 8及以后版本把包管理换成了dnf，但dnf install iftop同样需要EPEL源，安装命令是：
bash复制dnf install -y epel-release
dnf install -y iftop
CentOS Stream 9也一样，只是epel-release包名可能变成epel-release或者epel-next-release，根据自己的系统选。装完之后用iftop -v验证一下版本，能正常输出版本号就说明装好了。
这里有个很容易踩的坑：有些精简版系统（比如Docker容器、Minimal版）默认没装epel-release的GPG密钥，安装时可能会报错。如果遇到GPG key retrieval failed，可以先yum install -y epel-release --nogpgcheck临时绕过，但生产环境建议还是把密钥链配好。
2.2 编译安装：源不好使时的备选方案
如果你所在的内网环境连不上EPEL源，或者你用的发行版仓库里实在找不到iftop，可以走编译安装。但说实话，除非万不得已，我不推荐这条路——iftop本身依赖libpcap，编译安装时你至少还要手动装libpcap和libpcap-devel，依赖链比yum长得多。
编译安装的大致流程如下：
bash复制# 先安装编译工具链和依赖库
yum install -y gcc make libpcap libpcap-devel ncurses-devel
# 下载iftop源码，注意官方老域名已经不怎么维护，建议到GitHub上找release包
wget https://github.com/.../iftop-xxx.tar.gz
tar zxf iftop-xxx.tar.gz
cd iftop-xxx
# 配置、编译、安装
./configure --prefix=/usr/local/iftop
make && make install
# 使用时要指定完整路径，或者加个软链接
ln -s /usr/local/iftop/sbin/iftop /usr/sbin/iftop
编译过程中最常见的报错是找不到pcap.h头文件，这是缺少libpcap-devel导致的。还有一类报错是缺ncurses.h，对应缺少ncurses-devel。如果你只是临时用一下，不追求新版本，还是建议老老实实走yum路线，别跟自己过不去。
2.3 安装完成后的验证与权限注意
安装完成后，直接执行iftop大概率会遇到Permission denied或者界面刷一下就退出。原因很简单：抓包需要root权限。普通用户只能看到一堆报错信息，无法正常读取网卡数据。所以运行时要么用root登录，要么用sudo iftop。
还有一个我在生产环境踩过的坑：如果你用sudo执行、但sudo的环境变量没保留，可能提示找不到iftop命令。这是因为/sbin或/usr/sbin没有包含在普通用户的PATH里。用sudo $(which iftop)或者sudo /usr/sbin/iftop可以完美解决。
下面用表格总结三条安装路线的差异：
| 安装方式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| yum/dnf + EPEL | 最快，自动处理依赖 | 需要联网访问EPEL源 | 绝大多数有外网的服务器 |
| 编译安装 | 不依赖特定源，可自定义版本 | 需要手动解决gcc、libpcap依赖 | 内网环境、离线环境 |
| 直接复制rpm包 | 一次下载，多机安装 | 需要找对rpm版本和依赖 | 批量部署同版本系统 |
3. iftop界面逐区域拆解：数字、颜色、排序、单位都代表什么
装好iftop只是第一步，我更想强调的是：很多人装完以后打开界面，发现完全看不懂，然后就把工具丢在一边。其实iftop的界面信息密度很高，只要拆开看，思路就清晰了。这里以默认的交互界面为例，按区域从上到下讲。
3.1 顶部带宽刻度尺
屏幕最上方是一行类似12.5Kb 25.0Kb 37.5Kb 50.0Kb......的刻度，这是当前网卡总流量峰值的动态范围。它不表示某个固定上限，而是会随着流量大小自动缩放。比如流量只有几百Kbps时，刻度尺上限可能只有1Mbps；当总流量冲到几百Mbps时，刻度尺上限会自动跳到400Mbps或更高。这个刻度尺配合界面中间的柱状图，能直观看出当前总体带宽压力的趋势。
3.2 中部连接列表：源IP、目标IP和三个速率列
列表每一行代表一条活跃连接，格式大致如下：
text复制192.168.1.10:ssh => 172.16.3.5:52000 2.00Mb 1.50Mb 1.20Mb
192.168.1.10:ssh <= 172.16.3.5:52000 3.00Mb 2.80Mb 2.10Mb
这里有个关键点：=>表示本机向对端发送的出方向流量，<=表示本机从对端接收的入方向流量。所以一个完整的TCP连接通常会出现两行，一行出、一行入。右侧三列数字分别代表2秒、10秒、40秒时间窗口内的平均速率。为什么要有三列而不是只显示瞬时值？因为瞬时值抖动太大，有时候一秒内跑满、下一秒归零，看着心惊肉跳。2秒列反映当前最及时的状态，10秒和40秒列则帮你判断这个速率是突发的还是持续性的。如果2秒数值很高、40秒数值很低，说明是短时突发流量；如果三个数值都很高且接近，说明该连接已经持续占用带宽一段时间了，需要重点排查。
界面上还会出现一些颜色高亮（不同终端下配色略有不同），通常表示最近2秒内有速率变化的连接。速率越高，颜色越醒目。这个视觉效果在连接数很多时非常有用，你可以一眼扫到最活跃的那几条。
3.3 底部汇总区和快捷键
界面最底部有三行汇总：TX发送累计、RX接收累计、TOTAL总流量。注意这里有两个维度，一个是cum（累计总量，从你打开iftop开始统计），一个是peak（峰值速率）。默认情况下，这些数值的单位是bit/s——这点非常容易引起误解。很多人看到数字以为自己是MB/s，算半天觉得数字不对。实际上iftop出于网络设备的习惯，默认采用比特而非字节作为显示单位。按B键可以在bit和byte之间切换，建议日常使用直接加-B参数，用字节为单位显示。
交互界面还支持大量快捷键，我把最常用的几个整理成表格：
| 快捷键 | 作用 |
|---|---|
| n | 切换IP地址显示模式（显示IP还是反解域名） |
| N | 切换端口显示模式（显示端口号还是服务名） |
| t | 切换连接行的显示格式（源/目的展示方式） |
| B | 切换bit/byte单位显示 |
| p | 暂停/恢复界面刷新 |
| T | 显示/隐藏累计总量列 |
| S | 按源IP排序 |
| D | 按目标IP排序 |
| 2/3/4 | 分别按2秒、10秒、40秒平均速率排序 |
| < / > | 左右移动排序字段 |
| ? | 显示全部快捷键帮助 |
这些快捷键不需要全部背下来，但B、n、S、D这几个一定要记住。特别是B，它决定了你看到的数字到底是比特还是字节，直接影响你的判断。
3.4 为什么iftop能看到“每个连接”的流量
这里需要简单提一下原理，因为理解了原理才能用好它。iftop基于libpcap库，在指定网卡上做数据包捕获，然后从数据包的IP头、TCP/UDP头里提取五元组信息（源IP、源端口、目标IP、目标端口、协议），再按连接维度累计字节数。所以它在计算速率时不是去读网卡的计数器，而是在用户态对每个包的长度做累加。
这个机制带来两个特性。第一，iftop能看到的流量上限受限于libpcap的抓包能力，在超大流量（比如万兆网卡打满）时，抓包本身可能产生丢包，导致统计偏低。第二，iftop在计算时通常会包含TCP/IP头部开销，所以你看到的速率可能比应用层统计到的实际数据速率略高。知道这两个特性，你在对比iftop显示的数值和业务侧统计的数值时就不会一脸懵：有一点偏差才是正常的。
4. 常用参数组合与真实排障案例：从看到异常到找到真凶的完整链路
只看默认界面，你只能看到一堆数据，还不一定能定位问题。真正让iftop发挥价值的是参数组合。这一节重点讲参数选择，再用三个真实案例带你走一遍完整的排障思路。
4.1 核心参数速览
先看我最常用的几个参数及其适用场景：
bash复制# 指定网卡。多网卡机器上必用，否则默认监听第一个网卡
iftop -i eth0
# 不反解DNS。生产环境强烈建议加，否则iftop会对每个IP做反向解析，界面卡顿且显示慢
iftop -n
# 以字节为单位显示。默认是bit，看着不直观
iftop -B
# 显示端口信息，配合-N直接显示数字端口而非服务名
iftop -P -N
# 只显示指定网段的流量，比如只看内网段
iftop -F 192.168.1.0/24
# 文本模式输出，指定几秒后退出，最多显示10行。适合脚本采集快照
iftop -t -s 5 -L 10 -n -N
参数之间可以组合，比如排查外网流量时我习惯用这个组合：
bash复制sudo iftop -i eth0 -n -B -N
这样界面清爽、单位直观、不带DNS反解延迟，适合快速判断。
4.2 案例一：从“带宽被打满”到“揪出爬虫IP”
背景：某公网Web服务器，业务方反馈网页打开极慢，检查发现出方向带宽持续打满。服务器上有Nginx、Redis、MySQL等多个进程，用top看CPU和内存都正常。
排查第一步，用iftop -i eth0 -n -B观察连接列表。在默认按2秒速率排序下，我发现有一个IP地址在出方向持续占着2Mbps左右的速率，且40秒均值也很高。由于这个IP并不属于公司已知的办公网段或合作方网段，我立即对它起了疑心。
第二步，用ss -tnp看看这个IP对应的连接落在哪个进程上：
bash复制ss -tnp | grep 223.xxx.xxx.xxx
结果显示该连接归属于Nginx的worker进程。
第三步，翻Nginx的访问日志，按这个IP过滤最近一段时间的请求：
bash复制grep 223.xxx.xxx.xxx /var/log/nginx/access.log | tail -100
结果发现这个IP在持续请求一个较大的接口数据，且带有明显的脚本特征（User-Agent固定、请求间隔均匀）。基本可以断定是爬虫或脚本在大量拉取数据。
处理方式：先在防火墙层面临时封禁这个IP，观察iftop界面，出方向流量立刻回落。之后和业务确认了具体原因，在Nginx配置里加了针对该IP的限速规则。
这个案例说明一个很重要的工作流：iftop负责定位连接和IP，ss负责定位进程，日志负责确认原因。三个工具一环扣一环，任何单靠iftop得出的结论都只是“现象”，而不是“根因”。
4.3 案例二：内网两台机器互访慢，iftop显示双向速率差很多
还有一个我印象很深的案例：内网有两台机器，A向B传大量小文件，B收到的数据量明显小于A发出的数据量。在A上运行iftop -n -B，可以看到A到B的出方向速率很高；再到B上运行iftop -n -B，发现B从A收到的入方向速率低很多。两边同一个连接的方向速率对不上。
这个现象说明流量在中间链路发生了丢弃。用ethtool -S eth0查看网卡丢包计数，或者用netstat -i看是否有RX-DRP（接收丢包）和TX-DRP（发送丢包），很快就能定位到是哪一端的网卡或交换机端口有异常。iftop本身不直接告诉你丢包，但它能帮你快速确认“问题出在这条连接上”，缩小排查范围。
4.4 案例三：离线采集流量快照，写脚本做定时报告
如果你不能时刻盯着iftop界面，可以用它的文本模式把流量快照写入文件，然后配合定时任务做趋势分析。比如：
bash复制# 每5分钟输出一次当前网卡Top 10连接
*/5 * * * * root iftop -t -s 5 -L 10 -n -N -B > /var/log/iftop/iftop_$(date +\%F_\%H\%M).log 2>&1
-t是文本模式，-s 5表示采样5秒后退出，-L 10只输出速率最高的10行。生成的日志可以直接用grep、awk处理，也可以按天打包归档。遇到网络问题需要复盘时，这些历史快照就是最直接的证据。
需要提醒的是，文本模式下的输出内容和交互界面略有差异——它不会显示刻度尺，只显示TOP行的连接速率和底部汇总。而且由于是文本快照，看不到动态的快捷键交互，所以参数组合要一次配好。
4.5 与tcpdump配合：当iftop发现异常IP，下一步该抓包
iftop能告诉你“谁在占带宽”，但有时候你还想知道“它在传什么”。如果怀疑是攻击或数据泄露，可以在iftop确认异常IP后，用tcpdump对该IP做定向抓包：
bash复制tcpdump -i eth0 host 223.xxx.xxx.xxx -w /tmp/abnormal.pcap -c 10000
抓完包后用Wireshark打开分析负载内容。注意抓包会产生额外性能开销，在流量较大的服务器上不要直接全量抓包，一定要先用host或port参数做过滤，缩小抓包范围。
5. 与nload、nethogs、bmon、vnstat的选型对比：别让工具选型拖慢排障
iftop不是唯一的流量监控工具，甚至在很多场景下它不是最优的。我在实际工作中经常被问到“既然有nload、nethogs，为什么要学iftop”，所以这里专门做一次选型对比，帮你建立自己的工具矩阵。
5.1 工具定位对比
| 工具 | 监控维度 | 核心优势 | 不足之处 |
|---|---|---|---|
| iftop | 连接/IP/端口粒度 | 按连接拆分速率，适合定位哪个IP在占用带宽 | 无法直接显示进程；不做历史数据存储 |
| nload | 网卡整体粒度 | 界面直观，一个屏幕显示进/出流量图表，适合快速看整体趋势 | 看不到具体连接，无法定位到IP和端口 |
| nethogs | 进程粒度 | 按进程名显示速率，适合定位“哪个进程在跑流量” | 与iftop相反，它不关心目标IP和端口 |
| bmon | 多网卡/带宽统计 | 支持多网卡切换，plot图更丰富，能顺便查看错误包统计 | 交互模式上手门槛略高 |
| vnstat | 历史流量统计 | 按小时/天/月保存历史数据，适合长期趋势和审计 | 不是实时工具，数据刷新有延迟 |
5.2 我的选型建议
根据不同的排障场景，我的习惯是这样的：
如果你只是想快速看一眼这台机器的进出流量是否正常，用nload最合适，打开就是两个大箭头，进和出一目了然，数字也大，适合给非运维同事做演示。
如果你是需要回答“哪个连接占满了带宽”，那就用iftop，它能按IP给你排序，还能在交互模式下切换排序字段，定位效率最高。
如果你需要回答“哪个进程在跑流量”，那就用nethogs，它能把进程名和速率列出来，比如sshd、nginx、java各占多少。特别是面对多进程服务时，nethogs能快速告诉你是不是某个Java进程在疯狂发包。
如果你需要做长期记录，比如“这个月哪天流量异常高”，那就用vnstat，配置好之后它会持续往数据库里记数据，你随时能查过去30天的日流量和小时流量。
5.3 三件套组合拳
实际运维中，我很少只依赖一个工具。遇到网络问题，我的标准操作流程是：
先看nload确认整体进/出流量是否异常，再开iftop定位异常连接和IP，最后用nethogs确认是哪个进程在产生这条连接。三个工具各管一个维度，组合起来基本能覆盖90%的带宽类排障场景。
有个容易忽略的坑是：这几个工具的默认显示单位不一致。nload默认按bit显示，iftop默认也是bit，nethogs默认按KB/s显示且可以切换。如果拿不同工具截图对比，一定要先统一单位，否则很容易出现“两个工具数字对不上，怀疑是某个工具统计错了”的乌龙。我之前就见过一个同事，拿着iftop显示的MB值和nethogs显示的KB值对比，折腾半天才发现是单位问题。
6. 离线环境与双网卡环境下的iftop使用小技巧
最后再补充两个我在实际项目中高频用到的场景，一个是离线内网机器怎么装iftop，另一个是双网卡路由环境下怎么避免看错网卡。
6.1 离线环境安装：rpm包打包搬运法
有些内网生产环境完全不允许连接外网，yum源只有内部镜像，而内部镜像不一定收录EPEL。这时候推荐在能联网的同版本机器上下载rpm包，再拷贝到目标机器安装。例如在CentOS 7.9上：
bash复制# 在能联网的机器上执行
yum install -y epel-release
yum install --downloadonly --downloaddir=/tmp/iftop-rpm iftop
--downloadonly会把iftop及其依赖的rpm包全部下载到/tmp/iftop-rpm目录。然后把这个目录打包拷贝到内网机器上，用rpm -Uvh *.rpm或yum localinstall *.rpm安装即可。注意不要漏掉依赖，所以下载时最好连依赖一起拉下来。
6.2 双网卡机器上，最容易看错网卡
很多服务器不止一张网卡，比如一张内网卡、一张外网卡，或者一张业务网卡、一张管理网卡。iftop默认监听的是系统的第一个网卡，也就是eth0（在CentOS 7及之后可能叫ens33、ens160等）。如果你运行iftop后看不到期待的流量，大概率是监听错网卡了。
先运行ip addr或ifconfig确认你关心的流量走的是哪个网卡名，然后显式指定：
bash复制sudo iftop -i ens160 -n -B
还有一种情况，机器上存在多个网卡但流量做了策略路由（比如双网卡一进一出），此时只监听其中一个网卡只会看到单向流量。正确的做法是分别在两个网卡上运行iftop，对比进出流量，同时用ip route get <目标IP>确认路由走了哪张网卡，避免被界面上的“速率差异”误导。
6.3 CentOS Stream 9与旧系统的差异提醒
如果你用的是较新的CentOS Stream 9，网络管理栈已经切换到NetworkManager + systemd-networkd，网卡命名规则也变成ensxxx或enpXsY，不再是老的eth0。iftop本身不受影响，但查看网卡名、配IP、重启网络服务的命令都有变化。在你运行iftop -i之前，一定要先确认网卡名，不要凭经验直接写eth0，否则会提示Interface eth0 not found。这也是很多从CentOS 6/7转到CentOS 9的运维同学最容易卡住的地方。
用到现在，我的个人体会是：iftop是一个“排障链路”里的关键一环，但绝对不是所有场景的银弹。它适合告诉你“哪条连接、哪个IP、哪个端口在占用流量”，但当你需要知道“哪个进程在跑流量”时，还是要配合nethogs或ss使用。真正高效的网络排障，不是只背熟一个工具的快捷键，而是构建起一套“整体流量 -> 连接/IP -> 进程/日志 -> 抓包确认”的完整排查链。顺手写个小技巧：日常巡检时，可以用下