VPS买完服务器标注的带宽是不是真跑满？VPS服务器的线路质量怎么样？晚高峰延迟会不会很高？很多时候，供应商的配置参数和真实使用体验之间有明显差距。通过测速，你可以验证承诺的带宽是否达标，排查网站响应慢的原因，甚至判断是否有必要更换线路更优的服务器。对于游戏、实时通信这类对网络敏感的场景，测速更是必须做的功课。
最简单的方法，不需要额外安装任何工具。测延迟用ping
ping -c 10 www.baidu.com重点关注两个指标：一是time数值，代表数据包往返时间，通常50ms以内算正常，超过100ms就要注意了；二是丢包率，0%丢包是理想状态，超过2%说明线路质量有问题。不过ping只能测延迟，不能测带宽。
测下载速度用wget或curl
想知道服务器从某个节点下载文件有多快？直接下个大文件测一测最直观。终端会显示实时速度，比如看到“15.2 MB/s”，换算成Mbps需要乘以8，大约是120Mbps。小技巧：可以同时测试不同地区的测速文件，对比哪个节点速度更快，这对选择服务器位置很有参考价值。
专业测速工具
speedtest-cli测公网带宽最方便，这是Speedtest官方推出的命令行工具，用法和网页版一样简单。安装方法：
Ubuntu/Debian
sudo apt install speedtest-cli
CentOS/RHEL
sudo yum install speedtest-cli一键测速：
speedtest-cli只输出关键数据（适合脚本调用）：
speedtest-cli --simple指定国内节点测回国速度：
speedtest-cli --list | grep -i china
speedtest-cli --server 节点IDspeedtest-cli会自动选择最近的服务器，测试结果包含Ping值、下载速度和上传速度，覆盖面广，非常适合快速评估服务器到全球各个节点的带宽质量。
iperf3是测两台服务器之间的真实带宽
speedtest测的是到公共节点的带宽，而iperf3可以测试你自己控制的两台服务器之间的实际传输速度，结果更贴近业务真实场景。两家都需安装。
两台服务器都安装
sudo apt install iperf3 -y在接收端（服务端）启动监听：
iperf3 -s在发送端（客户端）执行测试：
基础测试，默认10秒
iperf3 -c 服务端IP测试30秒，取更稳定的平均值
iperf3 -c 服务端IP -t 30测试反向带宽（服务端→客户端，即下载速度）
iperf3 -c 服务端IP -R多并发流测试，模拟真实多用户场景
iperf3 -c 服务端IP -P 4测试UDP带宽和丢包率
iperf3 -c 服务端IP -u -b 100Miperf3输出中重点关注Bandwidth（实际传输速率）和Retr（TCP重传次数）。重传次数越低说明线路质量越好。UDP模式下则关注Lost/Total的丢包率。
mtr：持续监控延迟和丢包
mtr结合了ping和traceroute的功能，可以实时显示数据包经过每一跳路由的延迟和丢包情况。
安装
sudo apt install mtr -y交互模式（实时刷新）
mtr 目标IP报告模式（运行100个包后输出结果）
mtr --report --report-cycles 100 目标IPmtr输出中，Loss%列显示丢包率，Avg列显示平均延迟。如果某一跳之后丢包率突然升高，说明问题就出在那个网络节点上。
一键测速脚本：省时省力的综合方案
如果你觉得手动跑上面这些工具太麻烦，社区里有不少一键脚本，一条命令就能测完CPU、内存、磁盘和网络带宽，并给出综合报告。
bench.sh（秋水逸冰脚本） ：最经典的一键脚本，显示系统信息、IO测试（取三次平均值）、全球多节点测速。
wget -qO- bench.sh |SuperBench：在bench.sh基础上增加了服务器虚拟化架构检测和国内三网（电信、联通、移动）测速节点。
curl -LsO https://raw.githubusercontent.com/FunctionClub/ZBench/master/ZBench-CN.sh && ZBench-CN.sh测速结果怎么解读？
拿到测速结果后，怎么判断服务器到底行不行？一个简单直接的判断方法是：找个测试IP，白天ping一下，晚上8点再ping一次。如果延迟从50ms飙到200ms以上，丢包率超过3%，说明这线路不太适合做面向国内用户的服务。
以下是一些参考标准：
| 测试项目 | 优秀 | 合格 | 需优化 |
| Ping延迟（国内-美西） | <150ms | 150-200ms | >200ms |
| 下载速度（标称带宽占比） | >90% | 70%-90% | <70% |
| 晚高峰丢包率 | <1% | 1%-3% | >3% |
| TCP重传次数 | <10 | 10-50 | >50 |
测速之后还能做什么？
测速不光是发现问题，更是为了解决问题。如果你发现服务器网络表现不佳，有几个优化方向可以尝试。
开启BBR拥塞控制算法。BBR是Google开发的TCP拥塞控制算法，相比传统的CUBIC算法，在有一定丢包的网络环境下（比如跨太平洋链路），BBR能更充分地利用带宽，提升传输速度20%-300%。
检查内核版本（需4.9以上）
uname -r开启BBR，编辑sysctl.conf文件
sudo nano /etc/sysctl.conf在文件末尾添加：
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr保存后应用：
sudo sysctl -p更换线路。如果开启BBR后效果仍然不佳，可能需要考虑更换服务器地域或选择CN2 GIA、9929这类优质线路。
测速不是跑一次就完事。不同时间段的网络状况差异很大，建议做几次测试取平均值。同时记录历史数据建立性能基线，方便后续对比。
购买新服务器后第一时间跑一遍完整的测试，确认配置达标。后续每隔一段时间再测一次，监控性能是否稳定。结合自己的业务场景选择测试重点——数据库为主的服务器多测磁盘IO，面向国内用户的网站多测回国路由和晚高峰丢包。掌握了这些方法，你的服务器到底行不行，自己就能判断。
