2026-09-12 Networking About 7 min

How to Run an Accurate VPN Speed Test: 2026 Methods and Tools

Speed numbers on promo pages are not a reliable reference. This guide walks through the full DIY method: which tools to use, which time slots to test in, which metrics matter, and how to spot a flattering speed test screenshot.

Why Speed Test Numbers on Promo Pages Don't Hold Up

How do you run an accurate VPN speed test? Here is the short answer first: a single result reflects the slowest segment of the chain — local broadband → your ISP's outbound gateway → the cross-border route → the overseas data center → the speed test server. A number on a promo page usually describes one day, one route and one test server; switch servers and the figure can change by an order of magnitude.

The most common distortion comes from where the test server sits. Speed test apps pick the lowest-latency server by default; if that turns out to be a node in your own city, you are measuring local broadband and the cross-border path never enters the picture. To compare routes, pin the test server to your target region manually.

The second distortion is units. Speed test apps report Mbps (megabits per second) while download tools report MB/s (megabytes per second) — a factor of 8 apart: 100 Mbps is roughly 12.5 MB/s. If a screenshot shows 100 MB/s, that is 800 Mbps. Do the conversion first, then ask whether it fits within your own broadband plan.

Unit check

“Mbps” and “MB/s” differ by one letter but by a factor of 8 in the numbers. When a screenshot looks especially good, find the unit first, then do the division.

8× The conversion factor between 1 MB/s and Mbps — the most common trick for inflating numbers in a screenshot
3 runs Minimum repeats per time slot; take the median, not the peak
3 slots Daytime, evening peak and late night — cover at least three time slots
20–23 The evening peak hours in Beijing time, when cross-border routes slow down most

Five Variables to Lock Down Before a Speed Test

A speed test is not about opening a web page and clicking a button — it is a controlled comparison. Change any one of the five variables below and two results are no longer directly comparable.

Device and connection type — same device, same browser; use Ethernet rather than Wi-Fi whenever you can. On Wi-Fi, check signal strength first, or you are really measuring the distance between your device and the router.
Client and protocol — typical Shadowsocks, VMess, Trojan and VLESS setups run over TCP, where congestion control drags throughput down as soon as packets are lost; Hysteria2 and TUIC are built on QUIC/UDP, which holds throughput better on lossy routes but is more sensitive to how your ISP handles UDP. When comparing numbers, keep the protocol identical.
Routing mode — global and rule-based modes can send traffic along completely different paths. In rule mode, the speed test server's domain may match a direct-connection rule, in which case you are actually measuring local broadband.
Test server — stick to one server in the same city and on the same carrier. Switching servers is like switching rulers.
Time slot — cover at least three windows (daytime, evening peak, late night) and log them over several consecutive days, instead of cherry-picking the best moment.

First, confirm your traffic actually goes through the route

Before testing, open the My IP page and confirm the exit IP belongs to your target region. If it still shows a local IP, your traffic is going direct and the numbers that follow have nothing to do with the route.

Which tools to use: browser, command line and built-in client tests

No tool is inherently better; what matters is knowing what each one measures. Bandwidth, latency and packet loss are three different things, and few tools measure all three accurately at once.

Tool	Type	What it shows	Caveats
Speedtest (Ookla) web / desktop app	Multi-thread bandwidth	Download, upload, latency, jitter	Auto-selects the nearest server by default; you must specify the target region manually
fast.com	Multi-thread bandwidth	Download bandwidth, switchable to upload	The endpoint is chosen by Netflix and cannot be changed; useful as a video streaming reference
Cloudflare Speed Test	Latency and bandwidth	Idle and loaded latency, jitter, packet loss, up and down	Shows how latency shifts when bandwidth is saturated, not just a peak figure
iperf3	Raw throughput	Up and down between your own server and the client	Requires your own overseas server; results depend heavily on the server's location
mtr / WinMTR	Path quality	Per-hop latency and packet loss	Measures the path rather than bandwidth; pinpoints the hop where quality starts to degrade
curl / browser download	Single-connection test	Actual throughput and time to first byte on a single HTTPS connection	Closest to the real feel of opening a page or pulling a file

Also note that the built-in “speed test” button in many clients only performs a single handshake or HTTP request per node. That measures latency, not bandwidth. Use it to shortlist nodes, never as a verdict on speed.

Which Metrics Matter: Latency, Jitter, Packet Loss and Single-Thread Bandwidth

Bandwidth is the easiest number to read and the easiest to be misled by. Ranked by impact on real experience: packet loss first, then jitter, then latency, and only then the bandwidth ceiling.

Latency (RTT): the round-trip time in milliseconds; it sets how fast things respond after a click. Low and steady is what counts.
Jitter: how widely latency swings between consecutive samples. On a high-jitter route, video calls and real-time games stutter no matter how much bandwidth you have.
Packet loss: the single most damaging factor on cross-border routes. TCP-based protocols slow down and retransmit when packets are lost, so bandwidth figures drop with them; UDP-based protocols do not retransmit, but video turns blocky and audio cuts out.
Download bandwidth: sets the ceiling for downloads and video playback.
Upload bandwidth: usually lower than download, and the deciding factor for live streaming, cloud drive sync and cloud backups.
Time to first byte (TTFB): the time from sending a request to receiving the first byte, shaped by both latency and DNS resolution.

Also separate single-thread from multi-thread results. A multi-thread test adds up several connections, so it can reach the bandwidth ceiling while hiding the degradation of any single connection; single-thread comes closer to what you feel when a video buffers or a file downloads. Record both — the wider the gap, the more the route depends on concurrency.

# Single-connection test: real throughput and time to first byte (Cloudflare speed test endpoint)
curl -o /dev/null -s -w 'dns %{time_namelookup}s | connect %{time_connect}s | ttfb %{time_starttransfer}s | speed %{speed_download} B/s\n' \
  'https://speed.cloudflare.com/__down?bytes=100000000'

# Path quality: 50 consecutive probes to inspect per-hop latency and packet loss
mtr -rwzc 50 1.1.1.1

A log sheet that is good enough

Log six columns per test: time, route and region, protocol, latency, jitter, single-thread download. Keep multi-thread results in a separate column and never compare them against single-thread figures.

Logging by time slot and by day: a repeatable test procedure

The procedure below needs no extra tooling — one device and one spreadsheet are enough. It does not ask “how fast can it go at best”, but “how much bandwidth does this route deliver, in which time slot, and with how much variation”.

Disconnect the route and measure a baseline first: same device, same test server, log the latency and download speed of your local broadband.
Connect the route and switch the client to global mode, or confirm that your routing rules cover the speed test server's domain.
Open the IP lookup page and confirm the exit IP has changed to your target region.
Run 3 consecutive tests against the same server, logging latency, jitter, download and upload each time.
Run a single-thread test with curl or a browser download, logging actual throughput and time to first byte.
Run mtr with 50 probes to see which hop packet loss starts at.
Move to the next time slot and repeat steps 2 to 6, covering at least three windows: daytime, evening peak and late night.
After logging for several consecutive days, compare the median and the range for each time slot rather than the best-looking run.

How to judge Whether a route is stable comes down to the median and jitter range across repeated tests in the same time slot; a single peak only proves the link was not congested at that instant.

How to Spot a Flattering Speed Test Screenshot

Sort out the route type first

Direct, relay and IEPL dedicated routes follow completely different paths, so putting their numbers side by side proves nothing.

Direct: the client connects straight to an overseas data center over the public internet. Low cost, and the most exposed to international gateway congestion during evening peak.
Relay: traffic first reaches a relay server in mainland China, which then carries it overseas. The path is more controllable with fewer hops and is usually steadier than a direct connection, though the relay node itself can become the bottleneck.
IEPL dedicated line: an end-to-end international Ethernet private line that does not traverse the public international gateway, giving steadier latency and jitter at a higher cost.

Screenshot checklist

✅ The screenshot shows the test server's city and carrier, plus the test time.
✅ The unit is clearly marked as Mbps or MB/s and stays consistent.
✅ Latency, jitter, packet loss and bandwidth appear together, not just one download figure.
✅ Single-thread and multi-thread results are listed separately, with the route under test named.
❌ Only the peak run is shown, with no server, time or unit.
❌ The figure flips between Mbps and MB/s, making it look bigger than it is.
❌ A same-city test server or a LAN iperf3 result is passed off as cross-border route speed.
❌ Protocol and route type are left unstated, mixing direct, relay and IEPL results in one comparison.

Common Myths and Takeaways

Bigger numbers are better — bandwidth only sets the ceiling; latency and packet loss set the floor.
One test is enough to draw a conclusion — cross-border links change with the time of day, so a single result says nothing about stability.
All routes in one client perform the same — different regions and route types follow entirely different paths and must be tested separately.
Low latency means fast — when bandwidth is short, low latency is only enough for text messages; video still buffers.
Watching only the single number from a speed test app — slow page loads and buffering video often come from DNS resolution or single-connection quality, which an aggregate bandwidth result may not reflect.

Back to the opening question: an accurate speed test is really repeated comparison with the variables held fixed. Lock down the device, protocol, routing mode and test server, log latency, jitter, packet loss and single-thread bandwidth across time slots, then compare medians and ranges instead of the best-looking run. Only numbers gathered this way can tell you whether a route is worth using long term.

Bottom line Fix the variables → repeat across time slots → record medians and jitter ranges. Do those three things and your own numbers will come closer to real-world experience than any peak on a promo page.