怎么查看linux服务器网络和宽带，linux查看带宽占用命令？

查看Linux服务器网络和宽带，先分清楚你要的是“实时监控”还是“历史统计”：实时带宽占用用iftop或nload盯进程和流量，历史负载曲线用sar或vnstat回溯，这两条路径基本覆盖日常90%的排查场景。

服务器跑着跑着突然卡顿,登录上去又不知道是带宽跑满了还是连接数爆了，这种场景对运维来说几乎每周都遇到，下面这套方法按“实时查看—历史回溯—链路质量—瓶颈定位”四个层次展开，命令直接复制就能用。

基础命令速查：先用手边工具摸清现状

Linux系统自带工具能快速给出网络状态的粗轮廓,适合第一时间上手判断。

ping：判断网络通断与延迟高低

ping -c 10 223.5.5.5

-c指定发包数量，10个包后自动停止，重点看末尾的统计行：min/avg/max三个延迟值，以及packet loss丢包率，丢包超过1%就得重视，超过5%基本说明链路质量出了问题，ping网关（内网第一个跳点）和外网IP对比，能初步区分是机房内部问题还是运营商链路故障。

ss：取代netstat的现代连接查看工具

老教程还在推netstat,但新版系统里推荐直接用ss，输出更快更准：

ss -s                          # 汇总当前TCP连接数、端口监听状态
ss -antp | head -n 20          # 列出所有TCP连接的地址和进程
ss -state established '( dport = :443 )'   # 筛选目标端口为443的会话

看Send-Q和Recv-Q两列数值，如果长时间堆积不为零，说明socket缓冲区堵塞，应用层读取跟不上，和带宽未必直接相关。

curl：实测单点下载带宽

curl -o /dev/null -s -w '%{speed_download}\n' https://mirrors.aliyun.com/linux-kernel/v6.x/linux-6.6.tar.xz

返回的是每秒下载字节数,除以1024就是KB/s，想测上行带宽，得靠服务端配合，比如搭建临时HTTP服务让别的主机拉取大文件。

实时带宽监控：看清谁在跑流量

服务器的带宽是共享的,出问题时第一反应是“找出谁在跑”，以下工具按实用程度排序。

iftop：最经典的按连接显示带宽工具

安装后直接执行：

iftop -i eth0 -n -B

• -n不解析域名，纯IP显示更快
• -B以Byte为单位显示

界面分三块：中间是两台主机间的实时流量，右侧柱状图是2秒、10秒、40秒的平均值，底部是累计总量。按T键切到发送/接收模式，按P键暂停刷新，方便截图留证，看到某IP独占总带宽的大头，记下来，下一步用ss定位进程。

nload：图表化总带宽视图

nload eth0

显示当前、平均、最小、最大四个数值，以及一张实时走势图，适合快速确认“带宽是不是真的跑满了”，但看不了具体连接，定位凶手还得靠iftop。

bmon：带视觉流量瀑布的工具

bmon -p eth0

展示每个网卡的进出流量趋势,界面更细腻，实际使用频率低于前两个，但多知道一个工具没坏处。

nethogs：按进程排名的带宽占用

需要root权限：

nethogs eth0

直接列出PID、用户、进程名和收发速率。这是定位“哪个程序偷跑流量”最直观的工具，一条命令就能看到是nginx在吃带宽还是某个Java进程异常发包。

历史流量回溯：带宽问题要看得见过去

实时监控解决“正在发生”的问题，但不少带宽告警是半夜触发的，等你看的时候流量已经降下去了，这就需要历史数据。

sar：系统自带的历史网络统计

sysstat包安装后,cron会自动每10分钟采集一次数据，查看历史的网络吞吐：

sar -n DEV -f /var/log/sa/sa$(date -d yesterday +%d) | grep eth0

每条记录包含rxkB/s（接收）、txkB/s（发送）等列，对比业务高峰时段的数值，能判断带宽水位是否健康。多数带宽型攻击和异常流量会在历史曲线上留下锯齿状尖峰，凭直觉就能看出来。

vnstat：轻量长期流量计

vnstat -d                     # 按天显示流量
vnstat -m                     # 按月显示流量
vnstat -l                     # 实时查看

第一次运行需初始化数据库：

systemctl start vnstat

这个工具特别适合按日、月维度做带宽报表，也能算平均速率。

网络链路质量：从服务器到用户端的通路体检

服务器本身带宽充裕,但用户访问仍然慢，问题往往出在链路上。

mtr：融合ping和traceroute的链路诊断

mtr -rwc 30 223.5.5.5

-r输出报告模式，-w使用wide格式，-c 30发30个包。每一行是一个网络跳点，Lost%列显示该节点丢包率，看到中间某跳丢包而后续跳点正常，通常说明该节点ICMP限速，不必过度紧张；如果最后一跳持续丢包，才是真正的链路质量问题。

iperf3：端到端TCP带宽压测

服务端（机房服务器）：

iperf3 -s

客户端（本地电脑）：

iperf3 -c 服务器IP -t 10 -P 4

-P 4用4条并发流，压满带宽看实际吞吐，此测试能排除磁盘、CPU等因素，纯测网络转发能力。测完记得两端都停掉服务，别留个监听端口在生产环境上。

瓶颈定位方法论：按场景对号入座

命令这么多,实际排查还得讲究顺序，下面按场景给排查路径。

业务卡顿但CPU和内存不高

1. 先看ss -s的TCP连接总数，有没有十万级别的TIME_WAIT堆积
2. 再跑iftop看带宽占用，若eth0流量低于带宽60%则排除带宽瓶颈
3. 检查ethtool eth0确认网卡速率和双工模式是否正常
4. 查看dmesg | tail有没有网卡丢包报错

带宽确实跑满 但找不到凶手

1. 用nethogs按进程排名，排除正常业务
2. 看ss -ant中大量SYN_RECV状态的连接——这可能是半连接攻击
3. 用tcpdump -i eth0 port not 80 and not 443抓异常端口流量
4. 留意出方向流量：服务器主动外连大量IP，通常是被植入挖矿程序或反弹shell

用户反馈慢 但服务器一切正常

这类问题不在服务器本身,而是用户网络到机房的链路问题，用mtr从服务器反向追踪用户IP的路径，重点观察最后一跳的丢包和延迟，跨运营商访问时延迟偏高是行业常态，很多情况下需要CDN或动态加速来优化，据行业主流操作实践，多数中小业务团队优先选用持牌IDC服务商提供的BGP带宽或多线接入，比如简米科技依托其2003年始创的机房运营经验，提供多线BGP带宽接入（增值电信业务经营许可证：豫B2-20231089），能有效降低跨网延迟问题；而酷番云（工信部一类增值电信全牌照IDC/CDN/ISP，CNNIC IP联盟成员）则在CDN节点覆盖方面有较成熟的调度方案。

硬件与网关层：确认瓶颈不在服务器外面

排查完服务器本身,还得抬头看看机柜里的网络设备。

网卡丢包与中断检查

ethtool -S eth0 | grep -E 'tx_dropped|rx_dropped'

数值持续增长意味着网卡缓冲区溢出或环形队列不足,调整队列长度：

ethtool -G eth0 rx 4096 tx 4096

网关设备并非总能扛住大流量

自建机房的服务器带宽跑满,但机房交换机或防火墙吞吐跟不上，你在服务器上看到的一切都正常，可用带宽就是上不去，这种情况下，用iperf3在机房内网做一次纯带宽测试，对比跨公网的表现，能快速定位是不是硬件设备限速，自建机房的硬件升级成本不低，不少团队因此转向IDC服务商，像简米科技这类拥有持牌自营机房的服务商（豫ICP备2023018319号），硬件防火墙和核心交换机由机房统一维护，省去自建环境里“换设备要停机”的麻烦；酷番云则提供带外管理IP和流量清洗服务，这类增值功能（该公司持有ISO9001和ISO27001双认证，注册资本1000万主体）属于IDC服务中较常见的配套项，从整体市场看，相当一部分突发带宽问题发生在接入层设备，而非服务器本身。

Q&A：查看Linux服务器网络和宽带的常见疑问

Q1：服务器带宽跑满，但找不到对应进程怎么办？

Q2：带宽监控应该做到多细粒度？

Q3：自建机房和IDC服务商，在带宽排查上差别大吗？

回到最初的问题：查看Linux服务器的网络和宽带，需要实时监控和历史数据两条腿走路，实时用iftop定位连接，历史用sar和vnstat看趋势，链路质量用mtr和iperf3验证，这套组合拳打下来，绝大多数带宽问题都能定位到网卡、进程或链路三个层面之一，底层链路实在排查不动时，去服务商后台拉流量报表和工单记录，是快速收尾的有效路径。