VPN speed test methods compared: tools, timing and metrics
With one toolset, fixed time windows and just three metrics, you can judge the real speed of an international route yourself, without relying on the numbers on a promo page. The process below is repeatable, and you can write it into your own log.
VPN speed test results often disagree with the marketing page. The usual reason isn't that anyone is lying — it's that the two tests used different variables. Same tools, same time window, three metrics recorded: that's how you measure the real speed of an international route and make today's numbers comparable with next week's. Comparable matters far more than "looks fast".
Why promo page numbers don't match your own tests
A single speed test is decided by five variables: the city and ISP you're on, how congested your local egress is, the location and load of the target server, the protocol and its encryption overhead, and whether you're running single-threaded or multi-threaded. Promo pages usually quote the most favourable combination of those five, while your desktop is subject to all five at once. Change any one of them and the number changes.
One factor that's often overlooked is cold start. The first connection has to resolve the domain, complete the TCP handshake and negotiate TLS, which takes noticeably longer than reusing an existing connection. Measure only that first attempt and you're measuring startup cost, not route speed. The same tool can also give different results in a browser than on the command line: connection reuse, HTTP/2 multiplexing and page scripts all change the concurrency model.
Start by fixing the five variables
The first step isn't opening a tool — it's writing the conditions down. The checklist below is ready to follow as-is. If any item changes, treat the results as a new data set and don't mix them into the same table as the old one.
- ✅ Same device, same local broadband: don't switch back and forth between Wi-Fi and Ethernet, and don't leave downloads or cloud sync running during the test.
- ✅ Same target: pin one overseas speed test page or one download file. Changing the target each time is like changing the ruler.
- ✅ Same protocol, same route: a protocol switch counts as a new data set — different encryption and congestion control can't be subtracted from each other.
- ✅ Same time window: run every test inside the same interval, for example all within the same evening hour.
- ✅ Same concurrency model: single-thread for stability, multi-thread for the ceiling. Record the two separately and don't average them.
Put those five items in the header of your log and just fill in results after each run. A week later you'll have data that shows a trend instead of a pile of contradictory screenshots.
Three metrics: latency, throughput, jitter and packet loss
A speed test tool spits out a pile of numbers, but only three categories are worth tracking over time. The rest are either derived from them or details that matter only in specific scenarios. Record the three separately — don't roll them into one score, because then you can't tell which segment is the problem.
| Metric | What it measures | How to capture it | Common misreading |
|---|---|---|---|
| Latency | Round-trip time for a packet | Probe several times in a row, or read the handshake timing fields in command-line output | Concluding from a single probe and averaging cold start into the result |
| Throughput | The amount of data actually moved per unit of time | Run one single-threaded and one multi-threaded download, record each | Treating your local broadband peak as the route's ceiling |
| Jitter and packet loss | How much latency varies, and what share of packets is lost | Compare the minimum and maximum across several probes | Looking only at the average and ignoring tail jitter |
Latency: read the round trip, not the feeling
Latency is the time a packet takes to travel from your device to the target server and back. It decides how long you wait after a click, and whether a video call turns into people talking over each other. Measure it by sending several probes in a row and looking at the gap between the minimum and maximum; a single result includes queuing time on your local wireless network, so it's of limited value.
Throughput needs both single-threaded and multi-threaded numbers
A multi-threaded download splits the data across several connections at once, so it measures the route's ceiling; a single-threaded download uses one connection and comes closer to what you feel when opening a page or watching one video stream. Record both. With only one of them you'll overestimate or underestimate the route — especially when you really only have one browser tab open.
Jitter and packet loss decide whether a route is stable
Two routes with the same average latency can feel completely different: one stays in a narrow band every time, the other swings up and down. Packet loss shows up directly as retransmissions and stutter; a route with a beautiful bandwidth number but heavy loss is still a poor fit for real-time calls and remote desktop.
Test by time window: the evening peak is the real experience
Cross-border links have a clear daily load pattern. On weekday evenings, when home broadband is at its busiest, international egress and transit segments are the most congested; links are usually idlest in the small hours. Test only at 3 a.m. and you measure the route's potential; test only at the evening peak and you measure its floor. If you only get one shot, take the evening peak, not the small hours.
Aim to cover at least three windows: a weekday morning, the evening peak, and late night. Repeat a few times in each window and record the minimum, median and maximum separately. Whether a route is usable long-term depends on its evening-peak median, not on any single peak.
Tool choices: browser, command line and client
Each of the three has its use, and mixing them makes the data incomparable. Pick one as your primary tool for the long run and use the other two only for cross-checks.
- Browser speed test pages: open and run, good for a first pass and for showing someone else. The downside is that browser connection limits, page scripts and caching affect the result, so repeatability is only fair — the same page can give different numbers on two consecutive runs.
- Command-line tools: stable output you can script, which makes them good for reproducible records. Use ping and mtr for path and packet loss, and curl for per-phase timings.
- Built-in client tests: these measure the client-to-entry segment, which tells you whether the entry is reachable and the handshake is clean, but it isn't end-to-end throughput. The region-grouped route list inside the client is exactly what you need for node-level comparisons.
curl -o /dev/null -s \
-w 'dns %{time_namelookup}s connect %{time_connect}s tls %{time_appconnect}s ttfb %{time_starttransfer}s total %{time_total}s\n' \
https://www.example.com/Those five fields map to DNS resolution, TCP handshake, TLS negotiation, time to first byte and total time. If the resolution figure is clearly the largest, the problem is usually DNS rather than the route itself; if TLS is the outlier, check whether the handshake is being retried over and over. Point the test at a fixed overseas address, run it several times, and you have a comparable baseline. Running it again on another route is the fastest way to tell whether the problem is one node or the whole path.
DNS resolution and routing mode change the result
In rule mode, only traffic that matches a rule goes through the proxy. If your test target isn't covered by a rule, you're actually measuring a direct connection. Before testing, confirm whether you're in global or rule mode, and complete the whole set of tests in the same mode. Whether DNS goes through a local or a remote resolver also shows up in resolution time — which is why, after switching routes, some people find the page-load improvement happens mostly before the first byte.
Route types: how dedicated lines, transit and direct connections affect your results
On the same local broadband, switching route type changes the shape of the results completely. Understanding how the data travels is more useful than memorising any single number.
| Route type | How the data travels | What you see in a speed test | Best suited to |
|---|---|---|---|
| IEPL dedicated line | Traffic runs on a private channel from entry to exit, not over the public internet | Little variation at the evening peak; latency sits closer to the floor set by physical distance | Video calls, long-lived API connections, streaming |
| Transit | Connects to a transit entry first, then hops to an overseas exit | Good most of the time; peak performance depends on congestion in the transit segment | Everyday browsing and downloads |
| Direct | Connects straight to an overseas node with no transit | Latency is clearly affected by congestion at the international egress | Light use, backup routes |
One caveat: a dedicated line isn't automatically faster. It guarantees a stable path, not unlimited bandwidth — if your local egress is congested, a dedicated line can't rescue it. Route type determines the path, not the quality of the egress in your city. The same node can feel very different on different ISPs and at different times of day, which is why you always end up back at repeated measurements under your own fixed conditions.
Five common misreadings
- ❌ Letting one test result stand for a whole route: a single run mixes local network jitter with the target server's state. Repeat it at least a few times.
- ❌ Looking only at peak bandwidth: the peak shows the ceiling, the median shows the experience. Read them together.
- ❌ Ignoring resolution time: slow DNS makes "pages load slowly" look like "the route is slow", and your troubleshooting starts off in the wrong direction.
- ❌ Treating the client's speed test button as end-to-end: it measures the client-to-entry segment and doesn't cover anything past the exit.
- ❌ Comparing new protocol results straight against old data: encryption and congestion control differ, so you have to establish a fresh baseline.
If any one of these five catches you out, the comparisons that follow are meaningless. The value of a speed test isn't the number — it's leaving only one variable different between two measurements.
Turning test results into a choice
After a round of testing you should have a minimum, median and maximum for each time window, plus two sets of throughput figures, single-threaded and multi-threaded. Then judge three things: is the evening-peak median stable, does jitter settle down, is packet loss acceptable. Pass all three and the route can be your daily driver; a route with a pretty peak but a drifting median is better kept as a backup.
Make your test target a fixed routing rule and switch to global mode only when you need to re-test — that keeps unrelated traffic from skewing the results. When several devices are online, check that none of them is downloading, or you'll be measuring how your household bandwidth is being shared. Log the date, time window, route name and protocol for every test; half a month later you'll know exactly which route works at which hour.
The same applies when choosing a service: rather than one peak number, look at whether it gives you enough routes to test against each other, and whether you can get your money back if the results don't satisfy you. VPNQK offers 90+ countries and 190+ routes, plans from ¥9.9 per month with 60GB included, a 7-day money-back guarantee, and you can get started with just a username and password — no email address needed — with no limit on simultaneous devices. More routes means more control groups; a refund policy means you don't have to settle for results you're unhappy with.