我们怎么测

点一下“开始测试”，浏览器会花大概一分钟做四件事：下载几个文件、向十个域名发探测请求、试着碰一碰十个常被封的网站、加载一组已知尺寸的图片。整个过程都在你的浏览器里跑，服务器只负责收结果。每一步能说明什么、不能说明什么，下面逐个拆开。流程本身和 GreatFire 翻墙中心一样，我们只多加了可达性和并发峰值两项。

速度

速度测试对每个测速 URL 做一次 fetch，带 cache: 'no-store'，然后流式读取响应体——不是等整个文件下完再计时，而是边读边计数。读到文件末尾或者到时限就停，速度 = 已读字节数 / 用时。

目前有两个 URL：本站的 /api/speedtest-file（随机字节，50 MB，时限 15 秒）和 Cloudflare 的 speed.cloudflare.com/__down（同样 50 MB，时限 10 秒）。为什么两个？本站文件测的是“你到我们服务器”这条路，Cloudflare 文件测的是“你到一个全球 CDN 边缘”这条路。两条路经过的国际出口往往不一样，一个梯子可能到 CDN 飞快、到普通 VPS 很慢，反之亦然。

榜单上的“速度”是 avgAll，两个文件的平均——这是首要指标，也是 GreatFire 那边 averageSpeedAllFiles 的对应物。另外还算一个 avgVideo，只取非本站文件的平均，用来估算流媒体画质（下文）。

我们额外加了一项：对本站文件开 3 个并发流跑 5 秒，取合计吞吐作为峰值 max。单流测速受 TCP 拥塞控制和丢包影响很大，在高丢包的跨境线路上尤其明显；三个流一起跑能看到线路“能跑多快”的上限，跟单流的差距越大，通常说明丢包越严重。

延迟

延迟测试对 10 个域名各发 2 次 HEAD 请求，mode: 'no-cors'，cache: 'no-store'，8 秒超时。每次成功的请求记一个用时，20 个样本取中位数作为这次测试的延迟；失败的记进 failures。

为什么是 no-cors？浏览器不允许网页随便读别的网站的响应，但 no-cors 模式下请求照样发出去，只是拿回来一个“不透明”的响应：状态码看不到，内容看不到，但能知道它什么时候回来。我们只要往返时间，这就够了。

代价是分不清 200、403 和重定向。一个被服务器拒绝的请求和一个正常响应，在我们这里长得一样。而被 GFW 重置或丢包的连接，会表现为超时或者 fetch 直接抛错——这一类会记录为失败，不算进延迟样本。

还有几个已知的噪音来源：浏览器会缓存 DNS，第二次请求同一域名可能跳过解析；HTTP 连接复用意味着第二次请求可能走已经建好的连接，比第一次快不少；有些浏览器会在你点击之前就预连接。这些都会让测出的数字偏低一点。中位数能压掉一部分，但压不干净。

可达性

这是我们加的一项，GreatFire 没有。对 YouTube、X、Instagram、Facebook、ChatGPT、Telegram Web、Discord、GitHub、Wikipedia、Google 各发一次 HEAD no-cors 请求，8 秒超时，记录通没通、用了多久。

它回答的问题很朴素：用这把梯子，这些网站现在能不能开。延迟中位数告诉你线路整体质量，可达性告诉你具体哪些站被这条线路（或者这个出口 IP）挡住了——有些出口机房被 Google 或 OpenAI 拉黑，速度再快也没用。

同样因为 no-cors，我们只能判断“有响应”，判断不了“响应内容对不对”。一个返回 403 拦截页的站会被记为可达。这是浏览器的限制，不是我们偷懒。

稳定性

稳定性测试用一组已知尺寸的图片 [url, 宽, 高]。每张图用 new Image() 加载，URL 后面加时间戳防缓存，10 秒超时，加载完检查 naturalWidth 和 naturalHeight 是否正好等于预期值。全对算通过，稳定性 = 通过数 / 总数 × 100%。

为什么校验尺寸能发现问题？因为大多数干扰都会改变尺寸。运营商的透明代理把图片换成“该页面无法访问”的提示图，尺寸变了；某些劫持设备往响应里注入内容，图片解码失败或者尺寸变了；DNS 污染把域名解析到一个假 IP，那边要么不响应要么返回别的东西。反过来，如果图片按原样、按原尺寸加载出来，那这条通路大概率是干净的。

它测不出的是性能——一张图慢吞吞加载 9 秒但尺寸对，仍然算通过。所以稳定性和速度是两个维度，100% 稳定不代表快。

流媒体画质估算

这一项不额外测，直接用 avgVideo 换算成 Mbps（字节 × 8 ÷ 10⁶），对照一张阈值表：

速度	估算画质
< 0.7 Mbps	240p
< 1.5 Mbps	360p
< 2.5 Mbps	480p
< 5 Mbps	720p
< 8 Mbps	1080p
< 20 Mbps	1440p
≥ 20 Mbps	2160p

阈值来自 GreatFire 的实现，我们原样沿用，方便对照。它是个粗略估计：YouTube 实际用的码率随内容和编码变化，而且播放器会自适应，测速时 3 Mbps 不等于看视频时能稳定拿到 3 Mbps。把它当“大概能看到哪一档”就好。

浏览器测速的固有偏差

说到底这是在浏览器里跑的测试，不是 iperf。有几件事你应该知道：

单流下载受 TCP（或 QUIC）拥塞控制限制，在高延迟高丢包的线路上跑不满带宽，这也是我们加 3 并发峰值的原因。浏览器本身有开销，尤其是手机上。你的 Wi‑Fi、后台正在同步的网盘、同一路由器上别人在看视频，都算进去了。同一个出口节点在晚高峰和凌晨可能差三倍。

还有两件事我们验证不了：你选的位置和你填的工具名。我们只能相信你。这也是榜单要求至少 5 次测试跨 48 小时、中位数比平均数重要的原因：单次的偏差和误报，只能靠数量来稀释。

如果你想要更严格的数据，命令行工具（iperf3、speedtest-cli 直连服务器）会更准。但那样测不出“普通人用浏览器翻墙的真实体验”，而这才是这个站关心的东西。

常见问题

为什么我在别的测速网站测出来更快？ 多数测速站会自动选最近的服务器、开多个并发流。我们的主指标是单流下载，服务器也固定，数值天然偏低，但跨工具之间可比。看峰值 max 那一项会更接近别家的数字。

延迟测试为什么有些域名总是失败？ 有的域名对 HEAD 请求处理得慢，有的被你所在的网络直接重置。失败不计入延迟中位数，但会显示在详情里，本身也是一种信息。

测试结果会存哪些信息？ 你选的位置、填写的工具名和版本、四项测试的结果和详情、浏览器和系统类型。用了工具时会记录出口 IP 所在的国家，不存原始 IP。

能不能不用工具直接测？ 可以，工具选“无”。这种结果不进排行榜，但会用来计算各地区的“裸连”中位数，作为对照基线。