Linux网络性能实战：一键公网测速脚本在边缘设备与云服务器上的部署与应用

1. 为什么你需要一个自己的公网测速脚本？

如果你手头有闲置的树莓派、刷了OpenWrt的路由器，或者几台分布在各地的云服务器，你可能会好奇：它们的网络到底怎么样？服务商承诺的百兆带宽真的跑满了吗？晚上八点看视频卡顿，到底是家里路由器不行，还是运营商在“挤牙膏”？我以前做路由器开发的时候，就天天被这些问题困扰。靠网页版的Speedtest不是不行，但每次都要打开浏览器、点来点去，没法自动化，更别说集成到监控系统里了。于是，我就用Shell写了这个一键测速脚本。

这个脚本的核心价值在于“掌控感”。它把复杂的网络质量评估，变成了一个可以在后台定时运行、输出标准化数据的命令行工具。你不再需要依赖第三方网站的界面，也不用担心测试节点被屏蔽或变更。脚本会智能选择一个相对理想的测速节点，分别测试上行和下行带宽，并把结果以纯文本形式保存下来。这对于运维工程师来说，意味着你可以把它丢到Crontab里，每小时跑一次，长期监控网络质量波动；对于网络爱好者，你可以用它来对比不同时间段、不同运营商线路的实际表现，用数据说话。

更重要的是，它极其轻量。整个脚本就依赖curl、dd、awk、sed这些Linux系统里几乎标配的工具，没有额外的安装负担。这意味着它可以从容运行在资源极其有限的边缘设备上，比如只有32MB内存的OpenWrt路由器，或者ARM架构的嵌入式开发板。下面，我们就从零开始，把它部署到你的设备上。

2. 脚本全解析：从一行命令看透网络性能

拿到一个脚本，直接运行固然可以，但理解其每一步在做什么，才能让你在出问题时游刃有余，甚至根据自己的需求进行定制。我们来把原始脚本拆开揉碎了讲。

2.1 环境准备与依赖检查

在运行任何脚本之前，良好的习惯是先检查环境。这个脚本对系统环境要求很低，但确保关键工具存在是第一步。

#!/bin/bash # 检查必要命令是否存在 for cmd in curl awk sed sort grep dd; do if ! command -v $cmd &> /dev/null; then echo "错误：未找到命令 '$cmd'，请先安装。" exit 1 fi done # 检查是否具有写入临时目录的权限 if [ ! -w /tmp ]; then echo "错误：对 /tmp 目录没有写入权限。" exit 1 fi echo “基础环境检查通过，开始测速...”

这段前置检查能避免很多“莫名其妙”的错误。比如在极简的Docker镜像或某些嵌入式系统里，curl可能默认没有安装。在OpenWrt上，你可以用opkg update && opkg install curl来安装。在CentOS/RHEL上是yum install curl，在Debian/Ubuntu上是apt install curl。

2.2 核心逻辑拆解：如何找到“最佳”测速点？

脚本的第一个聪明之处在于它不是硬编码一个测速服务器地址，而是动态获取并筛选。我们来看关键部分：

# 获取一组可用的测速节点列表（这里以speedtest.cn的节点为例） /usr/bin/curl --connect-timeout 2 -o /tmp/nodes.txt -s "https://nodes.speedtest.cn/?https=1&browser=1&page=1" # 从返回的JSON数据中提取出测速节点的URL，并逐个进行试探性连接 fasted_site=$(cat /tmp/nodes.txt | sed 's/https:/\n/g' | sed 's/Url/\n/g' | grep "/hello" | awk -F '","' '{print $1}' | sed 's/\\\//\//g' | awk -F "/" '{print "http://"$3"/hello"}' | xargs curl --connect-timeout 2 -r 0-1048576 -L -w "%{speed_download}--%{http_code}--%{url_effective}--" -s | sort -n | grep "\-\-200--" | head -1 | awk -F "--" '{print $3}' | awk -F "/" '{print $3}')

这一长串管道命令看起来复杂，其实是在干几件事：

1. 获取列表：从一个公开的接口获取一批测速服务器的地址信息。
2. 数据清洗：用sed和awk把杂乱的文本或JSON处理成干净的URL。
3. 试探测速：对每个URL发起一个微型的下载请求（-r 0-1048576表示只下载前1MB数据），并记录下载速度 (%{speed_download}) 和HTTP状态码。
4. 择优录取：sort -n对速度进行升序排序，head -1取第一个（即最慢的）。这里有个很重要的技巧：原始脚本默认选择的是“最慢”的节点。这是出于一种保守策略，避免一开始就用最快的节点测出虚高的速度。但如果你想直接测试极限带宽，或者你的网络本身就很差，需要找一个响应最好的节点，那就把sort -n改成sort -nr（反向排序，取最快）。

这个过程模拟了我们在网页上点“开始测速”时，客户端自动寻找最近、最佳服务器的行为。通过命令行实现，为我们后续的自动化打下了基础。

2.3 下载与上传测试：真实的数据流模拟

找到节点后，就开始真正的带宽测试了。下载测试相对直观：

download_speed=$(curl --connect-timeout 10 -m 40 -L -o /dev/null "http://$fasted_site/download?size=1000000000" >/tmp/downinfo.txt 2>&1 ; ... )

这条命令向选定的测速节点请求下载一个大约1GB (size=1000000000字节)的文件，但输出重定向到/dev/null，我们并不保存这个文件，只关心传输过程。-m 40设置了整个操作最长40秒，防止网络太慢时无限等待。所有的进度信息都被重定向到/tmp/downinfo.txt文件。

关键的数据提取发生在后面那一连串的awk和sed处理中。curl的进度信息会实时输出，其中包含了瞬时速度。脚本的聪明之处在于，它并不是取最后一个速度值，而是将所有出现的速度值（比如每秒输出一次）进行平均计算。它会分别处理以 “M”（兆字节/秒）和 “k”（千字节/秒）为单位的数据，最后输出一个平均速度。这样得到的结果，比单次瞬时值要稳定和准确得多，更能反映整个测试周期的平均带宽。

上传测试则更有趣一些，它模拟了一个文件上传的表单提交：

# 先创建一个约1GB的临时测试文件（内容全是零） dd if=/dev/zero of=/tmp/test.jpg bs=1K count=1000000 >/dev/null 2>&1 # 然后使用curl的`-F`参数，模拟表单上传这个文件 upload_speed=$( (time curl --connect-timeout 10 -m 30 -X POST -F'image=@/tmp/test.jpg' "http://$fasted_site/upload?r=0.6127") >/tmp/uploadinfo.txt 2>&1 ; ... )

这里用dd命令快速生成一个内容全为零的大文件，避免了磁盘读写速度成为瓶颈（因为是从/dev/zero读取）。然后用curl的-F选项模拟网页表单的文件上传功能。后面的速度提取逻辑和下载测试类似。测试完成后，脚本会贴心地删除这个临时文件 (rm -f /tmp/test.jpg)，避免占满你宝贵的存储空间，尤其是在路由器上。

3. 实战部署：从OpenWrt路由器到云端服务器

理解了原理，我们来动手把它部署到各种环境中。不同的平台，关注点略有不同。

3.1 在资源受限的OpenWrt路由器上运行

在路由器上跑脚本，最大的挑战是资源（CPU、内存、存储）和依赖包的完整性。

第一步：脚本适配与精简OpenWrt的Shell环境通常是ash或dash，而不是完整的bash。好消息是，我们这个脚本用的都是POSIX标准命令，兼容性很好。你只需要将脚本第一行的#!/bin/sh保留（或改为#!/bin/ash）即可。可以将脚本保存到路由器的持久化存储中，比如/etc/testspeed.sh。

第二步：安装缺失依赖通过SSH登录到你的OpenWrt路由器，运行：

opkg update opkg install curl coreutils-sort # 确保curl和sort命令可用

如果awk或sed缺失（通常不会），也需要相应安装。

第三步：设置定时任务OpenWrt使用cron进行任务调度。编辑定时任务：

crontab -e

添加一行，例如每天凌晨3点测试一次，避免影响日常使用：

0 3 * * * /bin/sh /etc/testspeed.sh >> /tmp/cron_testspeed.log 2>&1

这样，每天都会自动运行，并将日志追加到/tmp/cron_testspeed.log。注意，/tmp目录在路由器重启后会丢失，如果需要持久化日志，可以重定向到/etc/testspeed.log（确保有写权限）。

第四步：解读路由器上的结果在路由器上跑，你可能会发现速度远低于你宽带的理论值。这很正常，可能受限于：

1. 路由器CPU性能：加密、解密、NAT转发都需要CPU，百兆以上的带宽就可能让低端路由器的CPU成为瓶颈。
2. Wi-Fi信号与干扰：如果你是通过Wi-Fi连接路由器进行测试的，那么速度瓶颈很可能在无线环节。最理想的测试方式是，将测试脚本放在路由器本身上运行，然后通过路由器的WAN口进行测速，这样才能真实反映你的“出口带宽”。

3.2 在云服务器（VPS）上部署

在云服务器上部署就轻松多了，环境通常很完整。

第一步：下载与授权直接使用wget或curl将脚本下载到服务器，并赋予执行权限：

curl -o /usr/local/bin/testspeed https://your-domain.com/path/to/testspeed.sh chmod +x /usr/local/bin/testspeed

第二步：配置系统Cron编辑系统级的crontab或用户级的crontab：

crontab -e

添加更频繁的测试，例如每30分钟一次，监控网络稳定性：

*/30 * * * * /usr/local/bin/testspeed >> /var/log/testspeed.log 2>&1

第三步：云服务器测速的特殊意义在云服务器上运行这个脚本，主要目的不是测你家的宽带，而是测云服务器本身的网络出口质量。这对于以下场景至关重要：

• 评估云服务商：不同服务商、不同地域、不同计费模式（“突发性能实例” vs “通用型”）的网络表现差异巨大。长期监控可以帮你验证服务商是否提供了承诺的带宽。
• 诊断跨国/跨地区访问：如果你的应用需要服务海外用户，在目标区域的云服务器上部署测速，可以了解从该区域访问公网的质量。
• 监控网络异常：结合日志分析，可以发现规律性的网络降速（如下午时段拥堵），为故障排查提供数据支持。

4. 结果解读与进阶：从数据到洞察

脚本运行后，会在/tmp/testspeed.txt生成类似这样的结果：

download_speed:15.160M upload_speed:15.926M

4.1 Bytes vs Bits：千万别搞混了！

这里有一个超级重要的坑：脚本输出的单位是MB/s（兆字节每秒）或KB/s（千字节每秒）。而运营商宣传的带宽单位是Mbps（兆比特每秒）。1 Byte = 8 Bits。

所以，如果你的宽带合同是“100M宽带”，这里的“100M”指的是100 Mbps。它的理论最大下载速度大约是 100 / 8 = 12.5 MB/s。如果你看到脚本输出download_speed:15.160M，这表示15.16 MB/s，换算成比特率是 15.16 * 8 ≈ 121.3 Mbps，已经超过了100 Mbps的标称值，这可能是因为运营商提供了余量，或者测试节点非常理想。

换算公式：

• 已知脚本结果 (MB/s)，求运营商带宽 (Mbps)：Mbps = MB/s 数值 * 8
• 已知合同带宽 (Mbps)，求理论最大下载速度 (MB/s)：MB/s = Mbps 数值 / 8

把这个概念牢牢记住，能避免你误以为运营商“缺斤短两”，或者反过来，误以为自己的网络“快得飞起”。

4.2 参数调优：让测试更符合你的场景

原始脚本的默认参数是保守和通用的。你可以根据实际情况调整：

1. 测试文件大小 (size=1000000000)：默认下载/上传约1GB数据。对于低速网络（如4G热点），这个量可能太大，导致测试时间过长。可以改为size=100000000（100MB）甚至更小。反之，对于万兆网络，1GB可能不足以让速度跑满，可以适当增大。
2. 超时时间 (--connect-timeout,-m)：--connect-timeout 2是连接探测的超时，-m 40是整个下载操作的最大时长。在网络环境较差（如跨境）时，可以适当延长这些时间，避免因短暂延迟而误判节点不可用。
3. 选择“最快”还是“最慢”节点：如前所述，修改sort -n为sort -nr，可以让脚本在初始探测阶段就选择响应最快的节点，这对于测试网络极限峰值带宽更有意义。

4.3 集成到监控系统：自动化运维的关键

单次测试的结果只是一个快照。真正的威力在于长期、持续的监控。我们可以将脚本的输出，格式化成监控系统能抓取的数据。

示例：输出为Prometheus可抓取的格式修改脚本的最后部分，将结果输出为：

# TYPE network_download_speed_bytes gauge network_download_speed_bytes{host="my-router"} 15882649.6 # TYPE network_upload_speed_bytes gauge network_upload_speed_bytes{host="my-router"} 16700477.4

这里将15.160M转换成了以字节为单位的浮点数（15.160 * 1024 * 1024 ≈ 15882649.6）。然后，你可以在路由器或服务器上运行一个像node_exporter这样的文本文件收集器，或者写一个简单的Python HTTP服务暴露这个指标，让Prometheus定期来抓取。这样，你就能在Grafana上绘制出漂亮的网络带宽历史趋势图，设置报警规则（如“连续3次下载速度低于10MB/s”）。

示例：输出为Zabbix Agent可读的格式对于Zabbix，你可以让脚本将结果写入一个文件，然后配置Zabbix Agent的UserParameter去读取。或者在脚本中直接使用zabbix_sender命令将数据发送给Zabbix Server。

通过这种集成，网络性能监控就从手动执行的临时任务，变成了运维基础设施中自动、可视、可预警的一部分。

5. 避坑指南与经验之谈

在实际使用中，我踩过不少坑，这里分享给你，希望能帮你节省时间。

坑1：临时文件空间不足。脚本会在/tmp下生成一个约1GB的test.jpg文件。如果你的设备/tmp分区很小（比如只有几十MB的旧路由器），脚本会失败。解决方案有两个：一是修改脚本中dd命令的count参数，减少测试文件大小；二是指定一个更大的临时目录，可以通过修改脚本中的/tmp/test.jpg路径实现，比如改成/home/user/temp/test.jpg。

坑2：测速节点失效或无法访问。脚本中硬编码的获取节点的URL（nodes.speedtest.cn）可能会失效。这是此类脚本最大的维护点。你需要关注这个接口的稳定性，或者寻找其他公开、稳定的测速节点列表API。作为备用方案，你也可以在脚本中预设几个已知的、可靠的测速服务器IP或域名，当动态获取失败时，使用备用列表。

坑3：防火墙或安全组拦截。特别是在云服务器上，安全组规则可能会阻止向外部特定端口（如8080）发起HTTP连接。确保你的出站规则是放通的。同样，在公司内网环境，可能会有代理或防火墙策略限制，导致连接测速节点超时。

坑4：脚本在后台运行时的资源竞争。如果你将测试频率设置得很高（如每分钟一次），并且测试文件很大，可能会在测试期间短暂占用较高的CPU和I/O，影响设备上其他服务的性能。建议将测试安排在业务低峰期，并合理设置测试间隔。

最后，这个脚本是一个起点，而不是终点。你可以基于它的框架进行扩展，比如增加对延迟（ping）、抖动（jitter）的测试，或者同时测试多个目标节点做对比。网络诊断的世界很深，但这个小小的脚本，已经能为你提供一把衡量网络质量的可靠尺子。把它用起来，你会对自己的网络环境有一个前所未有的清晰认识。