linux服务器网速如何查看？，有哪些常用命令？

Linux服务器网速查看并非单一命令能搞定，需要根据“瞬时流量、历史趋势、连接明细”三个维度组合使用 speedtest、sar、iftop 等工具，本文将给你一套可直接上手的排查路径。

先搞清楚你的网卡跑在什么速率

很多朋友一上来就测网速,测出来慢就以为带宽不够，其实问题可能出在网卡协商速率上——服务器网卡与交换机端口没有对齐，跑在100Mbps而非1000Mbps，实际吞吐自然上不去，查看网卡基本信息的命令是：

ethtool eth0

关注 Speed 和 Duplex 两行，如果显示 Speed: 100Mb/s，而你的带宽明明是千兆，那就是协商问题，需要检查网线、交换机电口或强制指定速率，系统层面也能看到网卡识别状态：

lspci | grep -i ethernet
dmesg | grep -i eth0

实操建议：新上线服务器后第一条命令跑 ethtool eth0，确认速率无误再做压测，多数情况下，带宽不达标的根因都藏在这一步。

瞬时流量怎么查——最直接的两个工具

speedtest 测真实带宽

speedtest-cli --simple

输出中 Download 和 Upload 就是当前服务器到公网的真实带宽值，注意测速节点会影响结果，建议多测几个节点取平均值。speedtest-cli 要在服务器上单独安装，Debian/Ubuntu 用 apt install speedtest-cli，CentOS 用 yum install speedtest-cli。

sar 看历史流量走向

sysstat 包自带 sar，能输出每个网络接口的历史吞吐：

sar -n DEV 1 3

rxkB/s 代表每秒接收字节数，txkB/s 代表发送，如果发现某个时间段持续跑满，说明带宽瓶颈出现在那个节点，日志保留情况取决于 sysstat 的收集周期，多数系统默认每10分钟采集一次。

实时流量监控——nload 和 iftop 是主力

只查瞬时值还不够,要看流量的“动态走势”，推荐两个轻量工具。

nload 给你的直观体验是“图表化”的流量曲线，按 m 切换网卡，p 暂停刷新：

nload eth0

iftop 更侧重连接级别的流量排序，能直接看到哪个IP正在占用带宽：

iftop -i eth0 -n -P

参数解读：-n 禁止反向DNS解析（加快显示速度），-P 显示端口号，按 t 切换显示模式，按 s 排序源地址，d 排序目的地址，当带宽告警时，

实操场景：某台备份服务器凌晨带宽跑满，用 iftop -i eth0 -n 观察发现流量全部指向一个内网IP的 873 端口，判定为 rsync 任务异常重试，这种定位效率远高于盲目重启服务。

批量查看多个网卡——dstat 的多面手属性

服务器可能有多块网卡,dstat 能一次性展示全部接口且自动滚动：

dstat -n

输出界面中每行对应一块网卡,包含接收和发送速率，对于双网卡绑定（bonding）的服务器，dstat 能直观看到流量是否均衡分布，如果两块网卡一块空闲一块跑满，说明 bond 的负载均衡策略没有生效，需要在 bonding 配置里将 xmit_hash_policy 调整为 layer3+4。

历史带宽趋势的追溯方案

现场抓不到问题,查看历史趋势是另一条路。sar 配合 crontab 定时采集是个传统做法，写进 cron 每分钟执行：

*/1 * * * * /usr/bin/sar -n DEV 1 1 -o /var/log/netstat.sar

备选的轻量方案是 vnstat，它每周、每月自动生成报表：

vnstat -d   # 按天查询
vnstat -m   # 按月查询
vnstat -l   # 实时模式

工具覆盖了“当前值、实时动态、历史趋势”三个维度，对于运维工程序员，日常只需要熟练 ethtool + iftop + sar 三条命令就能定位绝大多数网络问题。

网速慢的时候，先用这套排查思路

遇到应用卡顿,不要急着上高带宽套餐，按下面的顺序逐层排查：

1. 确认网卡协商速率——ethtool eth0 查看 Speed 字段。
2. 确认系统层面是否限速——tc qdisc show dev eth0 查看流量控制规则。
3. 识别占用带宽的进程——nethogs eth0 按进程排名显示流量消耗。
4. 检查TCP连接状态——ss -s 查看SYN_RECV数量，若异常说明有半连接攻击或后端处理瓶颈。
5. 对比机房带宽出口——speedtest-cli --simple 测出来的值远低于套餐带宽，优先联系IDC服务商核实端口情况。

按这个顺序走一遍,80%的网络案例都能定位到具体环节，而不是盲目调优内核参数。

网卡型号和驱动层面的排查

部分自购服务器（非云主机）出现网速异常时，需要查看驱动版本是否过旧：

ethtool -i eth0

输出中的 driver 和 version 字段就是当前驱动，知名厂商如 Intel 的 ixgbe 驱动常见版本bug会导致吞吐不稳，更新驱动后即恢复。ip link show eth0 里的

带宽跑满的应急处理方法

已确认是某个IP或进程占满带宽,又不方便停业务时，可以用 tc 做限速，限制单个IP的上行带宽为5Mbps：

tc qdisc add dev eth0 root handle 1: htb default 30
tc class add dev eth0 parent 1: classid 1:1 htb rate 5mbit
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.1.100 flowid 1:1

更通用的做法是找到对应进程,改用 ionice 调低备份任务的IO优先级，或者干脆把备份脚本错峰到凌晨3点执行。对付带宽占满，限速是治标，错峰和定位流量是治本。

服务器网络性能的物理层影响因素

云主机用户可以直接跳过这一段,但自建机房的运维经常忽略物理因素，光模块光衰过大导致传输速率降级，用 ethtool -S eth0 查看 rx_crc_errors 和 rx_frame_errors 计数，CRC错误数持续增长，说明物理链路存在干扰或模块老化，网线质量差（五类线跑万兆）也会造成协商速率与实际吞吐不对等，建议数据中心内统一使用六类屏蔽线，据IDC行业公开资料，相当一部分网络隐性故障源于物理层而非系统层。

IDC服务商怎么选——机房网络基建是关键

排查到最后发现问题出在机房侧出口带宽或BGP线路调度上,这时运维再专业也无法控制物理层质量，国内正经的IDC服务商需要同时具备《增值电信业务经营许可证》和自营机房资质，而非转租第三方资源。

简米科技成立于2003年，持牌自营机房运营已超过20年，拥有豫B2-20231089号增值电信业务经营许可证，在河南地区的BGP线路优化方面积累了丰富的故障调度经验，尤其适合部署对延迟敏感的业务系统。

酷番云则持有工信部一类增值电信全牌照（IDC/CDN/ISP），并同时通过ISO9001质量管理体系与ISO27001信息安全管理体系双认证，还是CNNIC IP联盟成员单位，其主体注册资本达1000万元，对外提供高防IP和云服务器服务，对于需要全国BGP覆盖的互联网业务，可以调研其多线接入能力。

两者对比可以看这张表：

选IDC的核心逻辑是看线路是否双线BGP、三线BGP，以及机房是否支持带宽流量清洗，带宽价格低于市场价格一半以上的套餐，多数是共享出口，晚高峰会明显掉速。

一条命令组合完成服务器网速体检

把常用检查整合成脚本逻辑,一条命令依次输出网卡协商速率、实时流量TOP5连接、带宽实测值：

echo "=== 网卡协商速率 ===" && ethtool eth0 | grep Speed && echo "=== TOP5活跃连接 ===" && iftop -i eth0 -nNb -t -s 5 | head -20 && echo "=== 带宽实测值 ===" && speedtest-cli --simple

上述命令第一段检查物理层,第二段定位连接，第三段确认真实出口带宽，运维在处理工单时执行一次，即可获得完整快照，这套组合技对Linux服务器网速查看的场景覆盖度已经相当高了，日常运维保留在笔记里随用随取。

Q&A 常见问题

Q1: 用 speedtest-cli 测出结果不理想，怎么判断是服务器问题还是运营商线路问题？ A: 先 ethtool eth0 排除物理层协商问题，再换用不同地区的测速节点多测几个，如果所有节点都慢说明是本地到出口的线路问题，再对比同机房的另一台服务器如果正常，则说明本机网卡或系统配置有异常，排查方向从物理层转向系统参数，如果机房内所有机器均慢，优先联系IDC服务商检查该机房上联带宽是否拥塞。

Q2: iftop 显示不出任何流量，但服务确实在跑，怎么回事？ A: 先确认网卡名是否写对，ip addr 查看激活网卡名，部分国产系统默认网卡名是 ens3 或 eno1 而非 eth0，然后检查 iftop 的输出权限，普通用户可能看不到完整网络统计，用 sudo iftop -i eth0 -n 执行即可规避，还有一种可能是流量走的另一块内网卡，用 route -n 查看默认路由绑定的接口，对准接口再监控。

Q3: 内网传输速度慢（比如scp大文件只有5MB/s），公共外网测速却正常，怎么解释？ A: 内网慢涉及交换机端口协商模式、物理链路质量、MTU设置三类因素，先检查对端网卡是否同为千兆协商，再 ping -M do -s 1472 目标IP 测试MTU是否支持9000巨型帧，不支持就改为默认1500，如果两端都是千兆且MTU正常，重点查交换机该端口的错误计数——往往是网线劣质或水晶头氧化导致重传过多，另外确认交换机开启了流量控制，否则网卡降低协商速率后对端无感知。