Single connection: 3.1 MB/s. Four concurrent connections summed: 12.7 MB/s. Local broadband: 210 Mbps. Cross-border tunnel: 2.1 MB/s. Only with all three numbers side by side did it become clear that the “25 Mbps plan throttling” from the first round of speed tests was a misattribution — the bottleneck wasn’t at the VPS plan layer, but at single-connection throughput.

Why I Did This

I was giving two AWS Lightsail VPS instances — one in Tokyo, one in Seoul — a health check. The original need was simple: I wanted to know the download speeds and network parameters of these two machines, to judge whether they were good enough to serve as proxy nodes.

But once I actually got my hands dirty, I found that the answer was harder to nail down than expected — and the first round of conclusions was outright wrong. The entire troubleshooting process is itself a decent case study in “cross-border network measurement methodology” — which speed test sources are usable, which ones will fool you, and how your own conclusions get overturned. So I documented the whole process.

Conclusion First

Below is the full process.

Speed Test Sources Will Fool You: First Round Wiped Out

The instinctive approach to testing speed on a VPS is to curl a batch of well-known speed test URLs. The actual result: total failure across the board.

Four different failure modes: CF returned a 403 refusal (likely rate-limiting or blocking the AWS IP range), cachefly returned 200 but only served 25 bytes (suspected throttling of non-browser UAs or datacenter IPs), Hetzner and OVH couldn’t even complete a TLS handshake. Both VPS instances failed identically — if you only ran this round, it would be easy to conclude “these two VPS machines have terrible networking.”

The turning point was switching to an unexpected source: Tencent’s WeChat installer CDN (dldir1.qq.com). This source ran stably at full speed on both VPS instances and became the primary source for all subsequent tests. The lesson: when testing VPS international network performance, don’t blindly trust speed test files from major Western providers. Prepare a set of sources from various regions and rotate through them — if data flows, that’s what matters.

The Truth Behind 3.1 MB/s: The Conclusion Was Overturned by My Own Follow-up Test

After switching to the QQ CDN, both VPS instances showed ~3.1 MB/s on single-connection downloads, each downloading about 140MB in 45 seconds, with a flat, stable curve. Two machines in different availability zones gave nearly identical numbers (3,116,975 vs 3,123,117 B/s). The first reaction was: this is the Lightsail plan’s bandwidth ceiling — the 25 Mbps tier.

This inference looked airtight: two machines, two different schedules, different AZs, yet the numbers were completely identical — what else could it be but a plan-level throttle?

The verification method was cheap: add concurrency. Open 4 simultaneous curl connections on the VPS. If it were truly a plan-level total bandwidth cap, the 4 connections combined would still total 25 Mbps; if it were a single-connection throttle, the aggregate speed would multiply.

Results:

1
2

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

Each concurrent connection held steady at ~3.1 MB/s, with 4 summed at ~12.7 MB/s (~100 Mbps). The plan-throttle theory was overturned. The bottleneck was at the “single connection” dimension — possibly a per-flow rate limit at the CDN edge node, or a TCP throughput ceiling on the China→Japan/Korea international link for individual connections. The practical implication is direct: in multi-threaded download and multi-user sharing scenarios, both machines can hit the hundred-megabit level.

If I had stopped at the first round and published, and a reader believed the “25 Mbps plan” and went to upgrade their plan, the money would have been wasted. The attribution chain of a measurement conclusion needs verification just as much as the numbers themselves.

Full Health Check Table for Both VPS Instances

A few details worth expanding on:

The 16ms gap on 8.8.8.8 is a routing coincidence. Google’s 8.8.8.8 is anycast — the same IP maps to many physical nodes worldwide, and which one you hit depends on routing policy. Tokyo’s traffic hit a local Tokyo node (2.3ms), while Seoul’s traffic was routed elsewhere (16.4ms). This doesn’t affect actual usage, but if you use ping 8.8.8.8 as a “machine network quality” metric, anycast will pull a fast one on you. 1.1.1.1 came in at 2–3ms for both machines, confirming that both machines have very healthy local networks in their respective cities.

Tokyo has a ~17ms edge for return-to-China latency. Using Baidu Beijing as the test point: Tokyo 171ms, Seoul 188ms. I initially thought the gap was 30ms, but later realized that 30ms was the difference in “local machine reaching the two VPS instances via relay” (180−152=28ms) — which is a different thing from “VPS returning to China.” The two concepts are easy to conflate, and conflating them would inflate the conclusion. QQ’s Guangzhou-direction nodes didn’t respond to ping (nodes dropping ICMP), so the return-to-China direction only has a single test point — this is a limitation of this measurement.

The tunnel only worked after restarting tailscaled. At the start of testing, both VPS instances were completely unreachable: the local machine had no IPv6 egress, both mihomo proxy instances had dead egress, and the Tailscale coordination server had been disconnected for over 2 minutes. After restarting tailscaled, everything recovered, and all subsequent tests went through Tailscale’s DERP Tokyo relay. This background is important — it means the “cross-border segment” numbers below include relay detour overhead and do not represent the true performance of a bare cross-border direct connection.

Local Broadband: 210 Mbps, Far From the Bottleneck

Testing local machine direct connection speed (bypassing the proxy environment variables hanging in the shell, with --noproxy '*'), the Tsinghua mirror downloaded 658MB in 25 seconds:

1

26,347,612 B/s ≈ 26.4 MB/s ≈ 210 Mbps (re-tested at 26.5 MB/s, stable)

Domestic latency was equally healthy: Tencent CDN ~14ms, Alibaba DNS ~7.5ms, Baidu ~30ms, Tsinghua educational network ~36ms. Single connection maxed out, two rounds of re-testing consistent, no fluctuation — this home broadband line is in great shape.

With local 210 Mbps + VPS local hundred-megabit pipe, both ends’ “fat pipes” are fat enough — so where is the narrowest segment when a user is actually using a proxy? It’s at the cross-border link.

Cross-Border Segment Measured: 2.1 MB/s Through Relay

Transferring 100MB of random (incompressible) data via scp through the Tailscale tunnel:

• Download direction (tokyo→local): 100MB / 50s = 2.1 MB/s
• Upload direction (local→seoul): 100MB / 2m9s = 0.77 MB/s

These two numbers need to be interpreted correctly: the traffic goes through the DERP Tokyo relay (data is first detoured to Tailscale’s Tokyo relay server, then forwarded to the VPS), and scp itself has SSH encryption overhead, so this is a lower bound — the true throughput of a bare cross-border direct connection is likely higher. But as a reference value for “practical usable tunnel,” 2.1 MB/s (~17 Mbps) means this link is more than sufficient for video streaming, web browsing, and API calls, though large file syncs will feel slow.

Stitching all three parties together, the numbers a user sees when running speedtest through a proxy become explainable:

1

Your computer (210Mbps) → cross-border segment (~17Mbps+) → VPS (hundred-megabit+, 2-3ms) → speedtest Tokyo/Seoul server

Speedtest selects a server based on the VPS egress IP, so it’s always testing “next to the VPS” — the speed measured through a proxy is the end-to-end throughput of the entire link, determined by the narrowest cross-border segment. This answers a common confusion: why does a 200 Mbps home broadband only show tens of megabits through a proxy, and why does upgrading to a more expensive VPS plan not help — you’re upgrading the fattest segment of the pipe.

Methodology Notes: Reproducible Commands

All tests are reproducible. Core commands documented below:

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

# VPS single-connection download (key: add -L to follow redirects, QQ CDN does 302)
curl -sL -o /dev/null -w "%{speed_download} B/s\n" -m 45 \
  "https://dldir1.qq.com/weixin/Windows/WeChatSetup.exe"

# VPS concurrent total bandwidth (4 concurrent, check the sum)
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

# Local direct connection speed test (--noproxy bypasses shell proxy variables)
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"

# Cross-border tunnel throughput (random data to prevent compression cheating)
ssh vps 'dd if=/dev/urandom bs=1M count=100 of=/tmp/speedtest.bin'
time scp vps:/tmp/speedtest.bin /tmp/

Four pitfalls, all learned the hard way: speed test sources will 403 or throttle — prepare multi-region sources and rotate; QQ CDN always does a 302, so remember -L in curl; gzip /dev/zero will compress 200MB down to 200KB, so throughput tests must use urandom; to determine which layer the throttling is at, adding concurrency is the cheapest experiment to draw the line.

Limitations

The VPS download speed in international directions (European/American sources) was not measured this time — all four international speed test sources failed, which itself is a lead worth pursuing (AWS Lightsail egress may have issues with certain source endpoints). Return-to-China latency only has the single Baidu Beijing test point. The cross-border segment went through DERP relay plus SSH encryption, so it can only be considered a lower bound. Beyond 4 concurrent connections, no further pressure testing was done, so the true total bandwidth ceiling (plan layer) was not explored.

One last number: that local-to-Tokyo tunnel, 2.1 MB/s, stable as if someone clamped it — next round I plan to swap DERP for direct peering and test again, to see how much of that 17 Mbps is relay overhead.