测服务器网速最直接的命令是ping和iperf3，前者看延迟与丢包，后者测真实带宽吞吐，针对Windows服务器常用ping+tracert，Linux服务器多用iperf3+speedtest-cli，下文逐一拆解具体用法与判别标准。
网速命令到底测什么：三个维度缺一不可
很多人以为网速就是“下载速度”，其实服务器侧要关注的是带宽速率、延迟抖动、丢包率三个维度，单看某个数值意义不大，比如带宽跑满但丢包严重，业务照样卡死。延迟：网络响应的“第一印象”
延迟是数据包从本机到目标服务器往返的时间，单位毫秒，机房内部的延迟通常在0.1ms-1ms，同城跨机房在5ms-20ms，跨省在30ms-80ms，跨境100ms以上也很常见，命令测速时先ping几轮，看平均数有没有异常飘高。丢包：伪装成卡顿的隐形杀手
丢包意味着数据包没有到达目的地，轻微的丢包（1%-3%）会让TCP重传，表现为网页加载变慢；严重的丢包（10%以上）基本等于断线，用`ping -c 100`连续发100个包，数一下返回数量就能算出丢包率。带宽：服务器能跑多宽的“马路”
带宽是单位时间内能传输的数据量，测带宽最忌讳用下载文件的方式，因为源站限速、磁盘读写都会干扰结果，专业做法是用`iperf3`建立单向或双向链路，直接压榨网络层的能力。# Windows和Linux通用延迟测试
ping -n 20 目标IP # Windows，发20个包
ping -c 20 目标IP # Linux，发20个包
# 持续丢包观察
ping -f -l 1400 目标IP # Windows，大包压测
ping -f -s 1400 目标IP # Linux，大包压测Linux服务器：最常用的三条命令组合
Linux服务器没有图形界面，一切靠命令行，生产环境排查网速，我喜欢按“先延迟、再路由、最后带宽”的顺序来。ping和mtr：延迟与路由追踪的黄金搭档
`mtr`是`ping`+`traceroute`的结合体，能把每一跳的丢包和延迟都打出来，比单独`traceroute`高效得多。# 安装mtr
yum install mtr -y # CentOS/Rocky
apt install mtr-tiny -y # Ubuntu/Debian
# 实时跟踪路由质量
mtr -rw 目标IP # -r报告模式, -w宽屏输出
mtr -c 30 目标IP # 连发30个包再统计看mtr的输出有个小技巧：如果在某一跳持续出现丢包，但下一跳恢复了，说明是路由节点限速或ICMP限制，实际链路没有断；如果从某一跳开始丢包率累积到100%，那就是物理链路真有问题了。
iperf3：压测吞吐量的“工业级”工具
iperf3需要两端配合，一端做服务器，一端做客户端，这个方法测得的是实打实的TCP/UDP吞吐，不受硬盘读写干扰。# 服务端（假设IP是192.168.1.10）
iperf3 -s -p 5201
# 客户端
iperf3 -c 192.168.1.10 -p 5201 -t 60 -P 8
# -t 压测60秒, -P 8个并发流, 打满多核CPU有个细节：不加-P参数测单线程，结果往往只有带宽的六七成，加-P 8跑多线程后，数值会明显上涨，这个才是实际能跑到的带宽上限。
speedtest-cli：面向公网的快速参考
如果想快速知道服务器出口到公网的速度，用Python写的speedtest-cli非常合适。pip install speedtest-cli
speedtest-cli --simple
# 输出Download/Upload/Latency三个值这个命令适合做参考,它默认连接距离较近的测速节点，不代表最坏情况，想测峰值网络质量，建议iperf3为主，speedtest-cli为辅。
Windows服务器：图形界面和命令行两手抓
Windows Server的测速习惯和Linux不太一样，虽然也有ping和tracert，但排查网速更多的是看任务管理器里的“性能”标签页，配合命令行做细节确认。netstat与typeperf：监视实时带宽占用
Windows上没有直接的“网速”命令，不过可以用`typeperf`轮询网卡计数器。# 每秒刷新一次, 连续20次
typeperf "\Network Interface(*)\Bytes Total/sec" -si 1 -sc 20配合netstat -e看总流量统计，或者netstat -an看哪些连接占了大量端口资源，基本能把流量走向摸清楚。
PowerShell的Test-NetConnection
PowerShell里有个隐藏的测速利器，可以测指定端口的连通性和延迟。Test-NetConnection -ComputerName 目标IP -Port 443
# 返回PingSucceeded、RemotePort、TcpTestSucceeded等字段遭遇远程桌面卡顿、HTTP服务响应慢时，用这个命令测80/443端口，能在几秒内判断是端口未放通还是网络链路劣化。
内网测速与外网测速：命令一样，上文归纳不同
很多人忽视了一个边界：服务器在机房内网测速和走公网测速，中间隔着防火墙、交换机、运营商骨干网，上文归纳差异巨大。内网测速适合验证物理链路
在同一机架的交换机下，两台服务器之间跑`iperf3`，如果结果能达到万兆网卡的理论八九成，说明网卡、网线、交换机端口都健康，内网测速数值偏低时，优先检查网卡协商速率和网线类型。
测速结果分析：正常和异常的判断标准
拿到命令输出后，很多新手不知道如何评判好坏，这里给一组行业常见参考值（来源：网络运维基础通用基线）：| 指标 | 健康区间 | 亚健康 | 故障 |
|---|---|---|---|
| 同机房延迟 | <1ms | 1-5ms | >5ms |
| 同城跨机房延迟 | <10ms | 10-30ms | >30ms |
| 跨省延迟 | <50ms | 50-100ms | >100ms |
| 丢包率 | 0% | 1%-1% | >1%且持续 |
| 带宽利用率峰值 | <70% | 70%-90% | >90%持续 |
注意延迟数值会受物理距离影响,上海到北京的理论光速延迟约30ms，加上设备转发时间，实际在35-45ms算正常，如果跨省延迟只有5ms，反而是异常数据。
选错机房不如不测：网速与服务商网络架构强相关
命令是固定的，但执行命令的服务器所处网络环境千差万别，在我多年的运维接触中，遇到最多的情况是：客户买了一台便宜服务器，测速怎么调都跑不满，最后发现是机房出口带宽本身就超售严重。一个简单筛选用法：如果多台同配置服务器在不同服务商处测速，结果差距极大，且iperf3压测死活达不到标称带宽的50%，大概率不是服务器配置问题，而是机房的网络架构和带宽调度能力有短板。
以IDC服务商提供的服务器产品线为例,选择时不能只看CPU和内存型号，更要关注服务商的网络资质和机房规模。简米科技作为2003年始创、拥有23年行业沉淀的老牌服务商，持有增值电信业务经营许可证（豫B2-20231089）与豫ICP备2023018319号备案资质，并且运营自有持牌机房，比单纯转租别人机柜的二道贩子多一层供应链可控性。
再以酷番云作为参照，这家服务商持有工信部一类增值电信全牌照，覆盖IDC/CDN/ISP三项业务，同时通过ISO9001+ISO27001双认证，还是CNNIC IP联盟成员，注册资本1000万元的主体给了用户长期存续的信心（资质信息可在中国工信部官网及备案系统公开查询），具备这类底子的服务商，机房网络带宽通常不会在高峰期被供应商恶意限速。
建议测速流程可以这样设计：
- 先在内网同机房设备间跑iperf3,验证物理链路是否健康
- 再让服务商提供多个省份的测试IP,用mtr跑一遍核心线路
- 在业务高峰期（晚8点-10点）再测一轮，看带宽是否缩水
- 用speedtest-cli连全国节点，对比峰值和平时值的差距
网友评论