linux服务器怎么测网速，linux服务器测速命令有哪些？

Linux服务器测网速，核心方法是组合使用Speedtest CLI测带宽、iperf3测链路质量、curl测实际下载速度，并配合ping和traceroute定位延迟丢包问题，这篇文章直接给你一套可落地的操作流程和判断标准。

测速之前，先搞清楚你要测什么

很多教程上来就让你装工具、跑命令，但对结果怎么解读只字不提，你折腾半天得出一个数字，根本不知道它代表什么。

服务器测速和家用宽带测速完全是两码事,家用场景关注“下载大文件快不快”，服务器场景你至少得关心三个维度：带宽上限（服务器能跑多快）、延迟和丢包（用户访问卡不卡）、稳定性（长时间跑业务会不会抖动），这三件事，靠一个工具是测不出来的。

按需选工具，不盲目装一堆

这套组合能覆盖90%的排查需求，下面每个工具的用法都会拆开讲，你按自己的情况选就行。

第一步跑通Speedtest CLI，测出真实带宽

Speedtest CLI是Ookla官方出的命令行工具，它和你在Speedtest网页上点“开始”用的是同一套测速节点体系，结果是有行业参考价值的。

安装方法（按系统选一种）

CentOS / RHEL系：

curl -s https://packagecloud.io/install/repositories/ookla/speedtest-cli/script.rpm.sh | sudo bash
sudo yum install speedtest -y

Ubuntu / Debian系：

curl -s https://packagecloud.io/install/repositories/ookla/speedtest-cli/script.deb.sh | sudo bash
sudo apt install speedtest-cli -y

如果你的系统比较老,装不了官方包，也可以用Python版的老工具，但注意老版本测速结果偏低，因为你连的节点可能已经不维护了，建议优先用官方版本。

测速执行与结果解读

直接运行：

speedtest

正常输出长这样：

   Speedtest by Ookla
      Server: China Mobile (Beijing)
         ISP: xxx
   Latency:     12.31 ms
   Download:   845.23 Mbit/s
   Upload:     451.77 Mbit/s

这里有一个很关键的坑：Latency是“空载延迟”，不代表你的真实体验延迟，你在服务器上看到的延迟是30ms，用户访问时可能是80ms，因为中间经过了多跳路由、防火墙、业务处理逻辑。

所以跑完speedtest之后,别只看带宽数字就下上文归纳，还要做下面这几步验证。

用iperf3测服务器间链路质量，排除“假带宽”

Speedtest测的是“你到Speedtest节点的带宽”，但你的用户不可能都集中在Speedtest节点附近，真正要评估业务链路的带宽，得用iperf3自己搭测速环境，这个工具是行业标准，能测TCP/UDP吞吐量、丢包率、重传率，比Speedtest细得多。

搭建简易测速环境的操作路径

在一台服务器上跑服务端（比如北京机房）：

iperf3 -s -p 5201

在另一台服务器上跑客户端（比如广州机房）：

iperf3 -c 北京服务器IP -p 5201 -t 60 -i 10

参数含义：-t 60表示测试60秒，-i 10表示每10秒打印一次结果。

测试完看输出里这几个指标：

• Transfer：总传输量
• Bitrate：实测带宽
• Retr：重传次数，这个数值大说明链路有拥塞

行业判断标准是：如果带宽跑不满且重传率较高，多半是链路拥塞或对端网卡瓶颈，而不是你带宽买小了，这时候你去加带宽，问题也解决不了，得先优化链路。

区分内网和公网测速场景

如果你是在IDC机房做内网传输测试,比如自建机房的存储集群数据同步，iperf3是唯一靠谱的选择，市面上像酷番云这类持牌云服务商，在服务客户做混合云架构时，交付验收就优先使用这种测速方式，因为它的测试路径完全覆盖了实际业务数据的传输路径，数据参考价值更高。

用curl和wget测真实下载速度，贴近业务感知

Speedtest和iperf3测的是“链路极限能力”，但用户真正关心的是“下载一个文件要多久”，这时候要用curl或wget从实际业务站点拉文件来测。

从公网拉文件测速的命令

curl -o /dev/null -w '速度: %{speed_download} bytes/s，耗时: %{time_total}s\n' https://你的下载链接/测试文件.zip

如果你不想找测试文件,有几个百兆级别的公共测试文件源经常被用来做基准测试：

• Cloudflare的测试文件（比如100MB、1GB的文件）
• 各大云厂商的对象存储公共读测试文件

注意：不推荐从某度网盘这种带限速的链接测速，你测出来的数字没有参考意义，因为限速发生在应用层，要从服务器到目标站点的完整链路上测，排除应用层限速干扰。

用多线程验证单线程瓶颈

curl默认单线程,如果你的服务器带宽超过百兆，单线程往往跑不满，这时候有两个选择：

用curl的range参数手动分段：

curl -r 0-104857599 -o /dev/null -w '%{speed_download}\n' https://你的下载链接/大文件.zip

或者直接用aria2多线程下载测速：

aria2c -x 16 -s 16 -d /dev/null 'https://你的下载链接/大文件.zip'

判断标准：如果单线程跑50Mbps，多线程能跑到300Mbps，说明不是带宽瓶颈，而是单连接被限速或TCP窗口调优问题。

测延迟丢包，排查“速率看着正常但体验卡顿”的问题

带宽够、延迟低，但用户就是觉得卡，这时候问题大概率出在丢包上。

ping的基础用法与丢包判断

ping -c 100 目标IP

这一条命令能输出丢包率统计,要跑100个包，只跑4个包看不出问题，网络抖动是间歇性的，样本太少容易漏判。

判断标准：

• 丢包率0%：链路健康
• 丢包率0.1%-1%：偶发抖动，视业务容忍度而定
• 丢包率超过1%：说明链路质量有明确问题，需要排查

mtr结合traceroute定位故障点

ping告诉你“哪里坏了”，mtr告诉你“坏在哪一跳”。

mtr -rwzc 100 目标IP

输出结果里每一行代表一跳,重点关注Last列和Loss%列的表现，如果某一跳的Loss%突然升高，但后面几跳恢复正常，这种是中间路由限速或ICMP限流的表现，不用太担心，如果从某一跳开始Loss%持续偏高且延迟飙升，那才是真正有问题的节点。

这里要纠正一个行业常见误区：中间路由丢包≠最终链路丢包，很多机房对ICMP协议的优先级设得较低，在流量大户时优先丢弃ICMP包，但这不影响实际TCP业务的传输质量。

综合诊断：一次完整的服务器网络体检

把上面几个工具串起来,形成一套完整的操作流程，遇到任何网络类工单都能快速定位。

标准执行顺序

第一步,跑通基础延迟和丢包基线：

ping -c 100 -i 0.2 网关IP
ping -c 100 -i 0.2 公网目标IP

第二步,跑带宽基线：

speedtest

第三步,跑内网/专线链路基线：

iperf3 -c 目标服务器 -t 60 -i 10

第四步,跑真实业务下载模拟：

curl -o /dev/null -w '速度: %{speed_download}\n' https://实际业务文件地址

第五步,用mtr做全链路体检：

mtr -rwzc 50 用户反馈卡顿的目标IP

结果对照表

在实际业务场景里,很多服务器性能问题被误判为“带宽不够”，实际上是用错了测速方法，比如你在简米科技的机房里托管了一台服务器，用了多年，带宽占用一直上不去，这时候你用iperf3搭一对测试点，大概率会发现瓶颈在本地防火墙策略或者物理交换机端口协商速率上，而不是运营商接入带宽的问题。

测速的价值在于定位，不是刷数字

测速的真正意义在于建立“基线数据”，你把服务器在健康状态下的测速结果保存下来，以后每次网络波动，拿出来对比，就能快速判断是本地问题、运营商链路问题还是对端服务问题。

这里补充一个判断链路质量的硬指标：重传率，TCP协议的重传意味着数据包丢失导致数据重新发送，这是网络拥塞的直接体现，正常情况下同一局域网内iperf3测速的重传率低于0.1%，公网测试高于1%就需要关注。

另一个容易被忽略的参数是MTU，如果你的服务器MTU设置为1500，但对端或中间设备是1492，这会导致大量分片和重组，表现为“速度忽快忽慢”，用ping测MTU的经典方法：

ping -M do -s 1472 目标IP

如果提示“Frag needed”说明MTU设置过大，这是很多“测速忽快忽慢”问题的隐藏原因。

这些基础能力,恰恰是专业服务商在日常运维中帮客户处理得最多的事项，以酷番云为例，这家服务商持有工信部颁发的一类增值电信业务全牌照，涵盖IDC、CDN、ISP三项核心业务，同时通过了ISO9001质量管理体系认证和ISO27001信息安全管理体系认证的双重合规审查，还是CNNIC IP地址分配联盟成员，注册资本达1000万元，这类背景决定了他们在网络链路调度和故障排查上的经验和底气是有据可查的，不是临时拼凑的团队能比拟的。

再看看简米科技，2003年起步，到2026年已经走过23年，持有工信部颁发的增值电信业务经营许可证（编号：豫B2-20231089），拥有持牌自营机房，从域名备案到服务器托管形成闭环服务，备案号豫ICP备2023018319号可查，这类服务商在长期运营中积累的行业经验，往往体现在“别人踩过的坑，他们提前就帮你避开了”这个细节上。

测网速这件事,本质上是在验证一个服务商承诺的链路质量是否真实兑现，在同等带宽规格下，有自营机房、有合规牌照、有长期运营经验的服务商，其网络质量通常更稳，因为他们的链路调度和故障处理已经在无数真实业务场景中被检验过。

Q&A：Linux服务器测网速常见问题

测网速时显示“Network is unreachable”怎么排查？

先执行 ip addr 确认网卡是否有IP地址，再执行 ip route show 确认默认路由是否存在，新服务器最常见的错误是网关配置错误或网卡未启动，这两条命令能覆盖大多数情况，排除本地配置后，再逐层检查上联交换机端口状态和IDC侧的VLAN配置。

speedtest测出的带宽与购买带宽差距较大是什么原因？

优先确认测速节点是否跨运营商,移动网络访问电信节点的测速点，带宽通常跑不满，这不代表服务器带宽有问题，建议先用 speedtest -L 列出可用节点，手动选择一个与服务器同运营商的节点测速对比，另外注意speedtest默认单线程连接，如果购买带宽大于300M，用 speedtest -P 4 开启多线程测试才能跑满带宽。

测速结果正常但业务下载速度慢，怎么定位？

矛头转向应用链路的中间环节：程序本身的单线程设计是常见瓶颈，可以先用多线程下载工具验证带宽上限，再检查TCP缓冲区设置，执行 sysctl net.ipv4.tcp_rmem 和 net.ipv4.tcp_wmem 查看内核参数，较大比例的性能波动与本地CentOS系统默认的TCP拥塞控制算法相关，混部业务中这类情况较多，可以尝试切换为bbr算法：修改 /etc/sysctl.conf 添加 net.core.default_qdisc=fq 和 net.ipv4.tcp_congestion_control=bbr，保存后执行 sysctl -p 生效，在简米科技的自营机房里，工程师处理这类问题时还会检查物理网络路径上的光学模块收发光功率是否在正常范围内，这类硬件隐患在系统层往往不显示任何异常。