为什么晚上移动代理表现更差，而测速却显示满格

我们收集了移动网络中的5964次测量数据，并观察了网络通道在一天24小时内的表现。结果发现，所有人选择代理时参考的那个数字，恰恰在工作体验最差的时候反而上涨。

关于为什么兆比特根本不能描述网络质量，我们在文章「Mbps并不能代表移动代理的质量」中已经详细讨论过。这里要讲的是同一个观点，但基于数据：延迟、抖动和丢包在一天内是如何变化的。

熟悉的场景

你选了一个更快的代理，但反检测浏览器还是不断登出会话，爬虫频繁超时，下载到一半就断了。你打开测速网站，显示四十兆，一切正常。卖家两手一摊：信道没问题，你自己看。

信道确实正常——按你测量的那个指标来看。问题在于，你测错了东西。

真正影响工作的因素

带宽只解决一个问题：大文件能下载多快。其他所有事情——打开网页、保持会话、通过验证码、爬虫的长请求——都取决于其他指标。

移动网络和有线网络的区别不在于速度慢。它的特点是不稳定：晚上基站负载过高，运营商切换频段，按计划启动限速。在浏览器里测一次，只代表一天中的某一秒——而且通常是你刚好想检查的那一秒。

数据呈现的样子

我们收集了过去十个月内通过MTS网络进行的测量，并按小时取平均值。三个指标放在三个单独的坐标轴上——这是有意为之：把它们放在同一张图里会扭曲图像。

从上到下：下载速度（Mbps）、抖动（毫秒）、丢包（%）。MTS网络中5964次测量，2025年9月至2026年8月。每个点代表一小时内所有测量的平均值，每小时包含72至388次测量。橙色区域标出晚间时段18:00–23:00；×3.4和×6.8表示该指标在夜间增长的倍数。点标记出全天最小值和最大值。

这张图的关键信息

速度几乎没有变化。从早上七点到午夜，速度保持在54–68 Mbps的范围内。无论白天什么时候运行测速，你都会看到大致相同的数字，然后得出结论，网络状况良好。

同一时间段内，抖动增加了3.4倍——从早上八点的25毫秒增加到晚上十一点的86毫秒。丢包增加了6.8倍：从白天的0.79%增加到凌晨的5.37%。

最糟糕的巧合是：晚上20:00速度达到全天峰值——68 Mbps——而同一小时的抖动却是64毫秒，是早上的2.5倍。这时候测速显示的是全天最好的结果，而恰恰是这时候的工作体验最差。

因此，类似「晚上一切都很卡，但测速显示正常速度」的抱怨不是虚构，也不是心理作用。测试测量的那个指标在晚上并不会变差。

如何正确测量

需要的不是单次测量，而是一系列测量。安装CLI，按计划运行并将数据累积到文件中：

speedmeter --json | jq -c '{t:.timestamp, d:.download, p:.ping, j:.jitter}' >> proxy.jsonl

添加到cron，每十五分钟运行一次：

*/15 * * * * /usr/local/bin/speedmeter --json >> /var/log/proxy-speed.jsonl

一天下来你会得到96个数据点，一眼就能看出你的网络是否有晚间性能下降的问题。程序是独立二进制文件，约400KB，无依赖，可以安装在任何运行自动化脚本的服务器上。

哪些数值是可以接受的

请注意，这张表里没有兆比特那一列。对于上述任务，带宽超过十兆后就不再是瓶颈了。

按小时的数据

以下是和图表中相同的数据，方便你验证或与自己的测量结果进行比较。

关于数据的说明

这些数据是众多用户和众多基站的平均值，而不是在一张受控SIM卡上进行的测量。这种切片展示了日曲线的整体形状，但不能替代对你特定网络的测量——你需要用上面的脚本自己测量。

用于收集这些数据的工具是开放且免费的：speedmeter.dev。它在服务器端测量抖动和丢包，而不是信任浏览器的报告，并将结果以JSON格式输出，方便脚本处理。