The point of a VPN speed test isn't opening a speed-test site and running it once. It's fixing the measurement conditions so that today's numbers and next week's numbers can sit in the same table and be compared. Latency, jitter, packet loss and bandwidth each answer a different question, and peak-hour behaviour differs sharply from the rest of the day. What follows is a repeatable routine, in order: which metrics to measure, when to measure them, how many rounds to run and which value to take, how to read the results, and why the numbers on different vendors' marketing pages can't be compared with each other.
Which Metrics to Measure
"Fast" is a vague word. Unpacked, it is at least four separately measurable quantities: latency, jitter, packet loss and bandwidth. There is no conversion between them — a low-latency route can have very little bandwidth, and a route with a big advertised bandwidth can jitter badly at peak hours. Only by logging the four separately can you tell whether the problem is physical distance, link congestion, or your own local network.
| Metric | Unit | Common method | What to watch for |
|---|---|---|---|
| Latency (RTT) | Milliseconds | Client built-in latency test, TCP handshake time | Distance sets the floor; cross-continent can't match same-city |
| Jitter | Milliseconds | Spread across 10+ consecutive samples | A good median with high jitter still breaks up calls |
| Packet loss | Percent | Continuous probes or TCP retransmission counts | Check loss before latency — the order matters |
| Downstream / upstream bandwidth | Mbps | Measure single-thread and multi-thread separately | Can't exceed your home broadband plan |
| DNS lookup time | Milliseconds | Time to resolve a new domain the first time | Local vs tunnelled resolution changes the result a lot |
| Time to first byte | Milliseconds | Network panel in the browser dev tools | Partly the target site's own doing, not the route |
ICMP probes are rate-limited or dropped outright on some networks, so a failed ping doesn't mean the route is down. For reachability, TCP handshake time or the client's built-in latency test is more reliable — and closer to what the browser actually does when it opens a connection.
Fix Your Test Conditions First
The same node can produce results that differ by a factor of two across devices, wireless bands and background load. The first step of a speed test isn't pressing Start — it's pinning the variables down. Otherwise the data is a reference at best, not evidence.
- ✅ Use the same device and the same network throughout — no switching Wi-Fi or falling back to mobile data mid-test.
- ✅ Prefer a wired connection; if you must go wireless, stay on the 5GHz band and in the same spot.
- ✅ Turn off background traffic: system updates, cloud sync, streaming video.
- ✅ Within one comparison set, keep the client, protocol and target node identical.
- ✅ Timestamp every run and keep peak-hour and off-peak statistics separate.
- ❌ Don't download while testing, and don't switch nodes mid-test.
Pin the protocol too. VMess depends on the client and server agreeing on time; clock drift causes handshake failures rather than a simple slowdown. Hysteria2 and TUIC run over QUIC/UDP and usually hold up better than TCP-based protocols on lossy routes — but if your local network throttles UDP, the result flips. Any protocol change gets its own row; never average it together with the previous set.
Time Slots: Give Peak Hours a Row of Their Own
International bandwidth is shared. Between 20:00 and 23:00 the local carrier's outbound links and the cross-border path are both under pressure, and the same route may measure half of what it showed in the morning. Testing only in quiet hours gives you the best-looking numbers of the day — from a time when you're not actually using it.
A workable schedule: 10:00 as the baseline, 15:00 as a second baseline, 21:00 as the peak-hour sample and 00:30 as a control. Run three rounds per slot, two to three minutes apart, and take the median. A mean is easily skewed by one bad sample, and the best value doesn't represent what you'll see when you open a page; the median ignores individual outliers and tracks everyday experience more closely.
How to read latency, jitter and packet loss
Light travels through fibre at about 200,000 km/s, so round-trip distance sets a hard floor on latency. A node in a neighbouring Asian country a thousand or two kilometres away has a theoretical floor of a few tens of milliseconds; a transpacific round trip of 20,000 km or more starts above 100 ms. So when one screenshot shows "Tokyo 30 ms" and "Los Angeles 30 ms", the second figure is almost certainly measuring a local entry point, not the actual exit node.
- Same region: under 30 ms — clicks and page turns feel instant.
- Neighbouring Asian countries: 30 to 80 ms — web pages, video and file downloads all behave normally.
- Cross-continent: 120 to 250 ms — pages still load, but real-time competitive play feels laggy.
- Above 300 ms: a noticeable wait between click and response.
These ranges are rules of thumb, not guarantees; actual results also depend on your local carrier, the route type and where the target site sits. Jitter is the spread between neighbouring samples: if the max and min of ten consecutive samples differ by 50 ms, voice calls will break up even when the median is only 60 ms. For real-time audio and video, jitter hurts more than latency. Packet loss below 1% is essentially invisible; above 3% video starts to artefact and pages occasionally fail to load; above 10% the route is effectively unusable. Once loss appears, change route type first and consider changing protocol second.
Concluding from a single run is the most common mistake. One result mixes route state, momentary congestion and local network noise. You need at least three rounds of ten samples each before the numbers mean anything.
Bandwidth: Single-Thread, Multi-Thread and Unit Conversion
Single-thread bandwidth governs the throughput of one connection — that's what high-bitrate video and single large downloads rely on. Multi-thread bandwidth governs the total, and only matters when several tasks run in parallel. Browser speed-test sites usually open several connections at once, which flatters the number; client built-in tests are often single-thread or let you set the connection count, which is closer to what a single app feels like. Measure both, but never compare one against the other.
Align the units first. Mbps is megabits per second, MB/s is megabytes per second — a factor of 8 apart, so 100 Mbps is roughly 12.5 MB/s. Read a downloader's 12 MB/s as 12 Mbps and you will assume the line delivers only a tenth of its rated speed.
Bandwidth is capped by three things at once: your home broadband plan, the bandwidth allocated on the node side, and protocol encapsulation overhead. Measured downstream never exceeds your plan and is usually a little below it; upstream is generally far smaller than downstream, so when a video call stutters, check upstream first instead of re-testing downstream.
Why Advertised Numbers Aren't Comparable
Before two speed figures can be compared, check four things: where the test target sits, how many connections were used, what time of day it ran, and how it was probed (ICMP, TCP or application layer). Change any one of them and the conclusion can flip.
| Common claim | What it really means | What you need to reproduce it |
|---|---|---|
| Top advertised bandwidth | Multi-thread peak at the best hour on the best node | Same slot, same node, same thread count |
| Lowest advertised latency | Probe to the nearest entry point or node | Say whether it's entry or exit, and which probe |
| No throttling | No artificial rate cap | Still limited by your broadband and route capacity |
| Stable at peak hours | Small drop versus daytime | State the comparison slot and sample count |
When a provider advertises a very high peak and you measure a fraction of it at home on a single thread, the two aren't contradictory — the conditions differ. To make a judgement, level the conditions: same time slot, same node, same protocol, same thread count, then see whose throughput drops less at peak hours.
A Log Sheet You Can Copy
Below are the columns of the log sheet; one row is one complete measurement in one time slot. A spreadsheet or plain text both work — what matters is that the columns stay fixed and you don't add new ones halfway through.
date,slot,node,protocol,rtt_med_ms,jitter_ms,loss_pct,down_mbps,up_mbps,notedate/slot: date and time slot. Use fixed slot values (e.g. 10:00, 15:00, 21:00, 00:30) so you can sort by column.node/protocol: node city and protocol name. If you change node or protocol, start a new row — don't overwrite old data.rtt_med_ms/jitter_ms: median latency and jitter, each from at least 10 samples.loss_pct: packet loss percentage. Write 0 when there's no loss; leaving it blank makes later statistics skip the row.down_mbps/up_mbps: downstream and upstream bandwidth, measured once single-thread and once multi-thread, with the thread count noted in the remarks.note: your broadband tier, whether it was a peak slot, and anything unusual at the time (e.g. video playing concurrently).
A suggested fixed order of six steps:
- Run one round while disconnected, as a baseline for your local network.
- Connect to the target node and wait 10 seconds for the connection to settle.
- Three consecutive latency rounds of 10 samples each; record median and jitter.
- Measure bandwidth once single-thread and once multi-thread, recording downstream and upstream separately.
- Repeat steps 1 to 4 in another time slot and append the results to the same sheet.
- After a week, compute the drop ratio as peak-hour downstream ÷ morning downstream.
A drop within 20% is normal variation and needs no action. Between 20% and 50% is a perceptible slowdown, and a good moment to start comparing other routes. Above 50%, that route is badly congested in that slot — change route type rather than swapping protocols and hoping.
Reading the Results and Common Pitfalls
Routes come in three types: direct, relay and dedicated. Direct leaves the local carrier's network straight away, which is the shortest path but the most volatile at peak; relay first lands at an entry point in mainland China before heading abroad, adding one hop but usually improving stability; dedicated runs over a point-to-point link, with steadier latency and bandwidth at a higher cost. When testing, group statistics by route type rather than by city — the pattern shows up faster. Every route in the route list is labelled with its type, so you can fill in the log sheet straight from it.
- Testing latency with ping against a domain name: the first result includes DNS resolution time and reads high; only from the second ping onward do you get true round-trip time.
- Treating Mbps as MB/s and concluding the route delivers an eighth of its rated bandwidth.
- Picking a test server in the speed-test site that sits far from the node — you're then measuring that server's distance to the node, not yours.
- Testing only late at night, concluding the route "never slows down", and never once using it at 21:00.
- Changing nodes without re-measuring the baseline, then averaging old and new data in one table.
The goal of a speed test isn't to find the best-looking number; it's to find the steadiest route for the hours you actually use. Same time slot, same node, same protocol, median of three consecutive rounds — that's what you can base a decision on.