Linux怎么看服务器带宽占用情况
Linux查看服务器带宽占用，核心思路是区分“实时观测”与“事后分析”，常用命令包括iftop、nload、nethogs和vnstat，其中iftop用于实时监控流量来源，nethogs用于定位占用带宽的进程，而vnstat负责长期流量统计。如果你正面临服务器带宽跑满、网站访问变慢的困境，下文将按照紧急排查、进程定位、历史回溯三个层面，配合具体参数和输出解读,帮你快速找到问题根源。
实时流量监控：先用iftop和nload看清总量
登录服务器后，第一步是确认当前整体带宽是否真的达到瓶颈，多数云厂商的控制台自带监控图表，但存在几分钟延迟，无法反映瞬时波动，此时需要登录服务器,使用命令行工具做秒级观测。
安装方式：CentOS/RHEL系使用 yum install iftop nload -y，Debian/Ubuntu系使用 apt install iftop nload -y。
iftop用法：直接执行 iftop -i eth0 -n -N -P，-i 指定网卡（可用 ip addr 查看实际网卡名），-n 禁止反向解析IP，加快显示速度，-N 直接显示端口号而非服务名，-P 显示每个连接的端口信息，界面顶部会滚动显示最近2秒、10秒、40秒的平均流量，单位自动适配为bit/s，按下 t 键可在发送/接收/总量显示模式间切换，按 b 键切换流量单位（bit或byte）。
一个常见的误区是只看总流量数值，却忽略了峰值出现的时间点，建议连续观察至少30秒，注意屏幕顶部的峰值速率，如果峰值持续贴近网卡上限（例如公网带宽是5Mbps，峰值稳定在5Mbps以上），说明带宽确实被占满,接下来需要定位是谁在消耗流量。
nload用法：执行 nload eth0 进入全屏界面，它会同时展示实时入站（Incoming）和出站（Outgoing）流量曲线，并用绿色柱状图直观呈现变化趋势，相比iftop，nload更侧重于展示整体带宽的利用率和流量走向,适合快速判断是上传还是下载方向拥堵。
进程级定位：用nethogs找到占用带宽的元凶
确认带宽跑满后，下一个核心问题是：是哪个进程在消耗流量？这时候 nethogs 是最直接的答案。
安装与使用：执行 nethogs eth0，它会在终端中动态显示每个进程的发送和接收速率，并标注PID和程序完整路径，例如某进程的发送速率持续达到数MB/s，而你的业务又不应该产生这么大流量,大概率就是异常情况。
实战场景：
- 网站服务器带宽异常，若nethogs显示
nginx或php-fpm进程发送速率极高，且与当前在线用户数严重不符,可能是遭遇了CC攻击或盗链下载。 - 若显示
java或python进程持续上传数据，需要检查是否中了挖矿木马或后门程序，这类程序常伪装成系统服务运行,占用外联带宽。 - 若系统自带
sshd进程流量巨大，说明有人正在通过SSH暴力破解或进行大文件传输，应立即检查/var/log/secure日志中的登录记录。
nethogs无法显示历史数据，只适合在线排查，如果你发现进程反复重启导致无法抓取，可采用 watch -n 1 nethogs eth0 每秒刷新抓取,并提前将输出重定向到日志文件备用。
历史流量与连接数分析：vnstat与ss的联动复盘
多数场景下，带宽故障是间歇性的，比如每天固定时段跑满，或者持续数天后自动恢复,此时需要历史数据辅助判断。
vnstat长期统计：该工具基于网卡流量累计数据库工作，安装后需要先初始化数据库，执行 vnstat -i eth0 查看每日流量汇总，vnstat -h 查看按小时统计的最近24小时数据，vnstat -m 查看月度流量，当你发现昨天22点流量异常飙升，而业务高峰期并不在此时，说明存在非业务流量,需要进一步结合系统日志排查。
ss连接状态分析：ss -n state established '( dport :80 or sport :80 )' | wc -l 可统计当前处于ESTABLISHED状态的连接数，若该数字远超服务器并发处理能力，且大量连接来自同一IP段，基本可判定为恶意流量，执行 ss -n | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head 可列出与服务器建立连接最多的前10个IP地址,此命令是排查DDoS攻击的常用手段。
趋势判断技巧：将vnstat的小时数据与业务日志（如Nginx访问日志）中对应时间段的请求数进行比对，如果流量飙升但请求数未增加，说明存在非HTTP流量，极可能是UDP Flood或P2P木马行为，如果请求数同步激增,则大概率是业务突发或恶意爬虫行为。
四类常见带宽异常的处理策略
服务器带宽异常，往往对应不同特征,采取的应对策略截然不同。
| 异常特征 | 可能原因 | 紧急处理操作 |
|---|---|---|
| 出站流量持续占满，连接数少 | 木马外发数据或视频盗链 | nethogs定位PID，kill进程后排查启动项 |
| 入站流量极高，大量SYN_RECV状态 | SYN Flood攻击 | 防火墙临时限制来源IP，启用SYN Cookie |
| 连接数多且来自少数固定IP | 爬虫或CC攻击 | 防火墙屏蔽IP，配合CDN开启访问频率限制 |
| 流量在所有时段均匀增长 | 业务正常扩容或数据同步 | 检查业务日志，确认后升级带宽或优化传输方式 |
拓展思考：如何用Linux看服务器带宽占用的历史峰值？ vnstat只保存分钟级汇总，无法回看某个时刻的精确峰值，如果确实需要长时间精确记录，可使用 sar -n DEV 1 10 查看网卡实时吞吐，该命令由sysstat包提供，能输出每秒收包数、字节数及错误包数，通过cron定时任务将结果追加到文件，可实现按秒级留痕，多数云厂商的监控服务也提供按分钟粒度的历史数据，控制台可直接查询近30天的流量曲线,这也是排查问题时省时省力的途径之一。
日常监控与自动化告警配置建议
人工盯屏并非长久之计，合理配置监控告警才能防患于未然，行业共识认为,带宽监控应纳入所有服务器的基线告警体系。
zabbix或Prometheus：对于中大型集群，部署zabbix采集网卡流量，当入站或出站速率超过阈值（如总带宽的80%）持续5分钟时，触发邮件或企业微信告警，实际配置时，建议针对不同网卡和带宽峰值分别设置触发器,避免业务突发导致误报。
轻量级方案：单台服务器可直接用 vnstat -i eth0 --oneline 输出精简统计，配合cron脚本判定当前速率是否超过预设阈值，超限时调用 curl 推送消息至钉钉或飞书机器人，这类方案无需额外组件，适合快速部署,但功能相对单一。
自动化溯源思路：监控告警触发后，自动执行nethogs采集脚本，将当时流量排名前5的进程、连接IP、端口号保存到日志目录，为事后分析提供直接证据，很多有一定运维经验的工程师会这样做，因为流量尖峰往往转瞬即逝,人工介入时现场已被破坏。
另一种常见场景是购买云服务器时带宽规格选择不当，例如业务以文件下载为主，却选了3Mbps小带宽，即使进程定位零异常，峰值时段的流量表现依旧受限，此时关注的目标应放在如何验证当前带宽是否够用，可以尝试在业务低谷执行大文件下载测试，观察实际吞吐是否达到购买带宽的理论值，若差距过大,需要排查本地网络因素或联系服务商确认限速策略。
Q&A：Linux带宽排查常见疑问解答
Q：执行iftop没有反应，界面空白是什么原因？
A：多数情况是权限不足或网卡名指定错误，切换到root用户执行，或用 ip addr 确认当前活动网卡名称，部分云服务器的公网网卡名是eth0，也有不少新实例使用ens5或ens192，若执行命令后仍无流量显示，检查系统防火墙是否屏蔽了用于采集的netlink通信，或更换 -i any 参数让iftop自动选择网卡。
Q：nethogs显示的是实时速率，如何查看某个进程累计产生的总流量？
A：nethogs本身不提供累计值，可在服务器上安装 nettop 或使用 pidstat -d 按进程维度监控I/O统计，但准确度有限，更靠谱的办法是持续运行 nethogs -t 将每行输出追加到文件，结束时用awk按PID累加第二列和第三列的发送/接收值，需要注意的是，该方式走势清晰且实现简单，但会占用少量磁盘空间,长时间监测需定期清理日志。
Q：服务器带宽跑满但无法登录，怎么远程排查？
A：多数云平台支持VNC登录或网页版终端，可绕过SSH连接层直接进入系统，这是首要的应急通道，进入系统后优先执行 ss -n | grep -c ESTAB 查看连接数，若数值异常高则尝试用 iptables -I INPUT -s 攻击IP -j DROP 做紧急封禁，然后再通过nethogs逐步排查业务进程，若VNC也卡顿，说明系统负载过高或连接数已耗尽系统资源，需在防火墙层面或云控制台的安全组先行封禁可疑IP,再尝试正常登录。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/776929.html
