单连接 3.1 MB/s,4 条并发加总 12.7 MB/s,本地宽带 210 Mbps,跨境隧道 2.1 MB/s。三组数字摆在一起,才发现第一轮测速得出的"25Mbps 套餐限速"是个错误归因——瓶颈不在 VPS 的套餐层,而在单连接吞吐。

为什么做这件事

给东京和首尔两台 AWS Lightsail VPS做体检,最初的诉求很朴素:想知道这两台机器的下载速度和网络参数,好判断它们当代理节点够不够格。

但真正动手后发现,这个问题的答案比想象中难拿,而且第一轮结论还测错了。整个排查过程本身就是一份不错的"跨境网络测量方法论"——哪些测速源能用、哪些会骗你、结论怎么被自己推翻——所以把全过程记下来。

先把结论摆桌面上

下面是完整过程。

测速源会骗你:第一轮全灭

在 VPS 上跑测速,直觉做法是 curl 一批知名测速 URL。实际结果是全军覆没:

四种失败模式各不相同:CF 是 403 拒答(可能是对 AWS IP 段做了风控),cachefly 回了 200 却只给 25 字节(疑似对非浏览器 UA 或数据中心 IP 限流),Hetzner 和 OVH 干脆连 TLS 都握不上手。两台 VPS 同样全挂——如果只跑这一轮,很容易得出"这两台 VPS 网络很烂"的错误结论。

转折点是换了一个意料之外的源:腾讯的微信安装包 CDN(dldir1.qq.com)。这个源在两台 VPS 上都能稳定跑满,成了后续所有测试的主力源。教训是:测 VPS 国际网络,别迷信欧美大厂测速文件,准备一组各区域的源轮着试,数据能流出来说话。

3.1MB/s 的真相:结论被自己的补测推翻

换到 QQ CDN 后,两台 VPS 的单连接下载都是 ~3.1 MB/s,45 秒各下了约 140MB,曲线平稳无波动。两台不同机房的机器给出几乎完全相同的数字(3,116,975 vs 3,123,117 B/s),当时的第一反应是:这是 Lightsail 套餐的带宽上限,25Mbps 档。

这个推断看着严丝合缝:两台机器、两种调度、不同 AZ,数字却完全一致——不是套餐限速还能是什么?

**验证方法很便宜:加并发。**在 VPS 上同时开 4 条 curl,如果真是套餐总带宽限制,4 条并发加起来还是 25Mbps;如果是单连接限速,总速率会翻几倍。

结果:

1
2

tokyo 4并发: 3167345 + 3165129 + 3160152 + 3167378 = ~12.7 MB/s
seoul 4并发: 3181886 + 3178392 + 3176990 + 3182286 = ~12.7 MB/s

每条并发连接各自稳定在 ~3.1 MB/s,4 条加总 ~12.7 MB/s(约 100Mbps)。**套餐限速论被推翻。**瓶颈出在"单连接"这个维度——可能是 CDN 边缘节点的单流限速,也可能是中→日/韩国际链路对单条 TCP 连接的吞吐天花板。对实际使用的含义很直接:多线程下载、多用户共享场景下,两台机器都能跑到百兆级别。

如果当时止步于第一轮就发文章,读者里要是有人信了"25Mbps 套餐"去升级套餐,钱就白花了。测量结论的归因链条,和数字本身一样需要验证。

两台 VPS 完整体检表

几个值得展开的细节:

8.8.8.8 的 16ms 差距是路由巧合。 Google 的 8.8.8.8 是 anycast——同一个 IP 在全球有很多个实体节点,你 ping 到哪个取决于路由策略。tokyo 的流量命中了东京本地节点(2.3ms),seoul 的流量却被调度去了别处(16.4ms)。这不影响实际使用,但如果你拿 ping 8.8.8.8 当"机器网络质量"的指标,就会被 anycast 摆一道。1.1.1.1 两台都在 2-3ms,说明两台机器在各自城市的本地网络都很健康。

回中国方向 tokyo 略优 17ms。 以百度北京为测点,tokyo 171ms、seoul 188ms。原本以为差距有 30ms,后来发现那 30ms 是"本机走中继到两台 VPS"的差(180-152=28ms),跟"VPS 回中国"是两回事——两个概念很容易混,混了结论就会夸大。广东方向的 QQ 节点 ping 无响应(节点丢 ICMP),所以回中国方向只有单测点,这是本次测量的局限。

**重启 tailscaled 才打通的隧道。**测试开始时两台 VPS 完全连不上:本机没有 IPv6 出口、两个 mihomo 代理实例出口全挂、Tailscale 的协调服务器断连 2 分多钟。重启 tailscaled 之后恢复,之后所有测试都走 Tailscale 的 DERP 东京中继。这个背景很重要——它意味着下面"跨境段"的数字含中继绕路开销,不是裸跨境直连的真实水平。

本地宽带:210Mbps,远非瓶颈

测试本机直连速度(绕开 shell 里挂着的代理环境变量,--noproxy '*'),清华镜像 25 秒下了 658MB:

1

26,347,612 B/s ≈ 26.4 MB/s ≈ 210 Mbps(复测 26.5MB/s,稳定)

国内方向延迟同样健康:腾讯 CDN ~14ms、阿里 DNS ~7.5ms、百度 ~30ms、清华教育网 ~36ms。单连接跑满、两轮复测一致、无波动,说明这条家宽线路质量很好。

本地 210Mbps + VPS 本地百兆管子,两端的"粗水管"都够粗——那用户实际用代理时,最细的那段在哪?在跨境。

跨境段实测:走中继的 2.1MB/s

用 scp 通过 Tailscale 隧道传 100MB 随机数据(不可压缩):

• 下载方向(tokyo→本机):100MB / 50s = 2.1 MB/s
• 上传方向(本机→seoul):100MB / 2m9s = 0.77 MB/s

这两个数字要正确解读:走的是 DERP 东京中继(流量先绕到东京的 Tailscale 中继服务器,再转给 VPS),且 scp 本身有 SSH 加密开销,所以这是下界——裸跨境直连的真实吞吐大概率比这个高。但作为"实际可用隧道"的参考值,2.1 MB/s(约 17Mbps)意味着这条链路上跑视频流、网页、API 调用绰绰有余,跑大文件同步会嫌慢。

把三方拼在一起,用户挂代理跑 speedtest 时看到的那组数字,就能解释了:

1

你的电脑(210Mbps) → 跨境段(~17Mbps+) → VPS(百兆+,2-3ms) → speedtest 东京/首尔服务器

speedtest 按 VPS 出口 IP 选服务器,所以测的永远是"VPS 旁边"那台——挂代理测出的速度,是整条链路端到端的吞吐,由最细的跨境段决定。这回答了一个常见困惑:为什么家里 200 兆宽带,挂上代理测速只剩几十兆,而且换更贵的 VPS 套餐也没用——你升级的是最粗的那段水管。

方法论沉淀:复现命令

全部测试可复现,核心命令留档:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# VPS 单连接下载(关键:加 -L 跟重定向,QQ CDN 会 302)
curl -sL -o /dev/null -w "%{speed_download} B/s\n" -m 45 \
  "https://dldir1.qq.com/weixin/Windows/WeChatSetup.exe"

# VPS 并发总带宽(4 条并发,看加总)
for i in 1 2 3 4; do
  curl -sL -o /dev/null -w "%{speed_download}\n" -m 20 \
    "https://dldir1.qq.com/weixin/Windows/WeChatSetup.exe" &
done; wait

# 本地直连测速(--noproxy 绕开 shell 代理变量)
curl -s --noproxy '*' -L -o /dev/null -w "%{speed_download} B/s\n" -m 25 \
  "https://mirrors.tuna.tsinghua.edu.cn/ubuntu-releases/22.04/ubuntu-22.04.5-live-server-amd64.iso"

# 跨境隧道吞吐(随机数据防压缩作弊)
ssh vps 'dd if=/dev/urandom bs=1M count=100 of=/tmp/speedtest.bin'
time scp vps:/tmp/speedtest.bin /tmp/

四条坑,都是踩出来的:测速源会 403/拒流,准备多区域源轮询;QQ CDN 一定 302,curl 记得 -L;gzip /dev/zero 会把 200MB 压成 200KB,测吞吐必须用 urandom;判断限速层级,加并发是最便宜的分界实验。

局限

国际方向(欧美源)的 VPS 下载速度本次未测到——四个国际测速源全部失败,这本身是个值得追的线索(AWS Lightsail 出口对部分源站可能有问题)。回中国延迟只有百度北京单测点。跨境段走的是 DERP 中继加 SSH 加密,只能算下界。4 并发之外没有继续加压,总带宽的真实上限(套餐层)未探明。

最后一个数字:本地到东京那条隧道,2.1 MB/s,稳定得像被谁掐过——下一轮准备把 DERP 换成直连打洞再测一次,看看这 17Mbps 里有多少是中继的开销。