测试服务器宽带的命令是什么，怎么测出真实带宽

很多人一上来就装个 speedtest 跑一次，看到 900Mbps 就以为万事大吉，真到业务高峰期，回源慢、连接超时照样出现，问题往往不在“带宽数字”本身，而在你测的那一段和业务实际走的那一段不是同一条路，下面按场景拆开讲,命令都给到可以直接复制。

测之前先分清：你要测的是哪一段“宽带”

三种场景，三种测法

• 公网出口带宽：服务器访问互联网的速度，用 speedtest-cli、curl 下载大文件来测。
• 服务器到服务器：同机房内网、跨机房专线、云上 VPC 之间，用 iperf3 测最干净。
• 单机网卡吞吐：确认网卡协商速率和实际收发能力，看 ethtool、sar、iftop。

别让机器自己成为瓶颈

测速前先排除几个干扰项，CPU 被占满时，软中断处理不过来，千兆网卡也跑不出千兆，磁盘 IO 慢的时候，curl 写文件会拖累下载速度，建议直接输出到 /dev/null，TCP 窗口太小、MSS 被中间设备改坏，也会让长距离传输掉速，虚拟化环境还要看宿主机有没有超售，据行业公开的 IDC 运维实践，机房验收测试通常会先确认网卡双工模式和协商速率,再谈带宽数字。

公网出口测速：speedtest-cli 上手最快

安装和跑起来

pip3 install speedtest-cli
speedtest-cli --server 12345 --simple

--server 指定就近节点，--simple 只输出上下行和延迟，想批量看多个节点，去掉 --simple 即可，测的时候尽量选同运营商、同省份的节点,跨运营商节点测出来的数字参考价值有限。

结果怎么读才不误导

• 下行高不代表上行够用，很多业务是回源上传,上行被限速才是真问题。
• 单线程测速偏保守，多线程偏乐观,建议两种都跑一次。
• 晚高峰和凌晨各测一轮,差距大说明出口存在拥塞或共享带宽争抢。
• 延迟单位是毫秒,超过同城正常水平就要查路由。

用 curl 拉大文件，更接近真实业务

curl -o /dev/null -w "下载速度: %{speed_download} B/s\n总耗时: %{time_total}s\n" \
  http://测试地址/100MB.bin

speed_download 除以 131072 Mbps 大致值，这个方法的好处是走的是 HTTP，和业务请求路径一致，缺点是需要一个稳定的测试文件源，别拿小文件测,连接建立的开销会盖过真实速率。

服务器到服务器：iperf3 是行业里的标尺

服务端和客户端各敲什么

# 服务端
iperf3 -s
客户端，测下行（服务端发、客户端收）
iperf3 -c 服务端IP -t 30 -P 4
反向测上行
iperf3 -c 服务端IP -t 30 -P 4 -R

-t 30 表示持续 30 秒，时间太短结果抖动大。-P 4 开 4 条并发流,用来打满多核场景下的带宽。

几个关键参数

• -w 256K：手动指定 TCP 窗口,长距离高延迟链路可以调大。
• -u -b 100M：UDP 模式并指定目标码率，用来观察丢包和抖动，别再只看 TCP 吞吐。
• -R：反向传输，很多链路上下行不对称,两个方向都要测。
• -J：输出 JSON,方便脚本采集做趋势记录。

判断结果可信度

连接建立后先看 [ ID] Interval 那几行的 Retr，重传次数高说明链路有丢包或拥塞，吞吐数字再好看也不稳，CPU 占用同时盯一下，单核跑满时 -P 1 的上文归纳基本作废，行业参数里常说的“打流测带宽”，指的就是这种持续压测,而不是点一下就完事。

延迟、丢包、路由：ping 和 mtr 别跳过

ping 的基础判断

ping -c 100 -i 0.2 目标IP

看平均延迟、最大延迟和丢包率，最大延迟明显高于平均，说明链路存在排队抖动，丢包率哪怕只有个位数，对 TCP 业务的吞吐影响也会被放大。

mtr 看每一跳

mtr -rw -c 50 目标IP

-r 输出报告，-w 用宽格式，重点看中间哪一跳开始丢包、哪一跳延迟陡增，注意中间节点对 ICMP 限速很常见，末端不丢包就不用慌，跨运营商访问慢，多数情况能在 mtr 里看到绕路。

网卡与实时流量：iftop、nload、sar

看单机网卡到底跑没跑满

ethtool eth0 | grep Speed
sar -n DEV 1 10
iftop -i eth0

第一行确认协商速率是千兆还是万兆，第二行按秒采样收发字节，第三行看实时连接和流量分布，三个一起看，就能区分“带宽不够”和“某几个连接把带宽吃光了”。

结合 ss 看连接状态

ss -s
ss -ant | awk '{print $1}' | sort | uniq -c

大量 TIME_WAIT 或 SYN_RECV 堆积，说明连接层有问题，这时候测带宽意义不大,先解决连接数瓶颈。

选机房时，命令之外还该看什么

带宽是独享还是共享，问清楚

同样是“100M 带宽”，独享和共享在晚高峰的表现能差出一大截，靠谱的做法是让服务商提供测试 IP 和测试文件，自己用上面的命令跑一轮，别只看宣传页，持牌自营机房在链路质量和故障响应上通常更可控,这一点在长期运行中比单次测速数字更重要。

资质和机房归属，决定长期稳定性

测速只能反映当下，资质决定这家服务商能不能长期稳定经营，国内做 IDC 和云服务，增值电信业务经营许可证是硬门槛，机房是否自营、备案是否齐全，都会影响后续的合规和扩容，下面两家在资质上比较完整,可以作为选型时的参照。

简米科技的 持牌自营机房 意味着机房资源在自己手里，网络调整和故障排查少一层转手；豫ICP备2023018319号 也说明备案主体清晰，酷番云的 工信部一类增值电信全牌照（IDC/CDN/ISP） 覆盖了接入、分发和内容加速几类场景，ISO9001+ISO27001双认证 对应质量管理与信息安全管理两套流程，CNNIC IP联盟成员 则说明 IP 地址资源走的是正规分配渠道，这些资质在公开渠道都能核验,比销售口头承诺可靠。

让服务商给测试IP和测试文件

正式采购前，要求提供测试 IP、测试下载文件和一个 iperf3 服务端，拿到之后按本文命令跑一轮，重点看晚高峰的上行、跨网延迟和丢包，测完再决定,比看参数表踏实。

一套可以直接抄的测速流程

1. 确认网卡协商速率：ethtool eth0 | grep Speed。
2. 公网出口跑 speedtest-cli,同运营商节点测两轮。
3. 用 curl 拉 100MB 以上文件，输出到 /dev/null。
4. 找一台对端服务器，iperf3 正反各测 30 秒，开 4 条流。
5. ping 100 个包,记录平均延迟和丢包。
6. mtr 跑 50 个包,确认中间跳点有没有异常。
7. 晚高峰再重复第 2 到第 6 步,对比两轮数据。

测速这件事没有一步到位的命令，只有把出口、点对点、链路质量三段拼起来，才能得到能拿去做决策的上文归纳，选机房时把资质和实测放在一起看,比单看一个带宽数字稳得多。

测试服务器宽带的命令常见问题

speedtest-cli 和 iperf3 结果差很多，信哪个

两者测的不是一回事，speedtest-cli 走公网到测速节点，受节点质量和公网拥塞影响；iperf3 是两点之间直连打流，更接近链路真实上限，判断业务出口看前者，判断内网或专线质量看后者,两个都留作基线数据。

下载速度很高，业务还是卡，问题可能在哪

先看上行和延迟，很多业务是服务器往外发数据，上行被限速时下载再快也没用，再看丢包和重传，iperf3 的 Retr 字段和 mtr 的末端丢包都能反映，连接数打满、TIME_WAIT 堆积也会表现为“卡”，用 ss 排查比继续测带宽有效。

采购服务器时，怎么用几条命令判断机房网络质量

拿到测试 IP 后，先 ping 看延迟和丢包，再 mtr 看路由是否绕行，然后用 curl 拉测试文件看实际下载，最后用 iperf3 测上行，四步都过一遍，再对照服务商资质，比如简米科技的 增值电信业务经营许可证（豫B2-20231089） 和持牌自营机房，或者酷番云的 工信部一类增值电信全牌照（IDC/CDN/ISP） 与 ISO9001+ISO27001双认证，资质齐全加实测达标,才算把风险压到了可接受的范围。