Why You Can't Take Marketing Numbers at Face Value
On the same device and the same route, a different time window can change the number by a factor of two. A speed test is affected by at least five variables: the real capacity of your local broadband connection, whether the test window is congested, where the test server sits, the overhead added by the proxy protocol and encryption, and whether your client's routing rules actually send the test traffic through the proxy.
Marketing pages usually quote the best-case run: a nearby test node, an idle time window, and a peak aggregated from multiple threads. That number answers “how fast can this link go under ideal conditions”, not “will video buffer at 9 p.m.”. The value of testing it yourself is that you fix the real conditions and watch how different time windows and different routes compare.
Clear the field first: pause system updates, cloud-drive sync, and any video or download running on other devices. If even one device on the same network is pushing heavy traffic, your numbers will come out low — and there's no way to estimate by how much.
How to Choose Speed Test Tools: Three Layers, Each With a Job
No single tool answers every question. Stack three layers — baseline first, then locate the problem, then return to real-world use — and you can handle most day-to-day judgments.
Layer 1: Browser-based tests for a quick baseline
Speedtest by Ookla, Fast.com, and Cloudflare Speedtest all belong here: open the page and you get download, upload, and latency. There's only one rule: pick the test server manually, and use the same server for every comparison run. Automatic selection switches servers as network conditions change, which makes the numbers incomparable.
Layer 2: Command-line tools to find which segment is at fault
ping and mtr cover latency, jitter, and hop-by-hop packet loss; iperf3 covers raw throughput and long-run stability; curl's -w flag prints the time spent in each of four stages — DNS lookup, TCP connect, TLS handshake, and time to first byte — so you can see exactly which step makes a page feel slow.
# Latency and jitter: 20 consecutive pings, focus on the gap between max and min
ping -c 20 example.com
# Hop-by-hop loss: is the problem in the local network, at the international gateway, or at the far end
mtr -rwzbc 50 example.com
# Per-stage timing: how long lookup, connect, handshake, and first byte each took
curl -o /dev/null -s -w "dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s\n" https://example.comLayer 3: Tests in real usage
Download a large file from a source you actually use, or watch a video and count the buffering events. There's no pretty number here, but it comes closest to what you feel day to day. For judging whether video will stutter, a single-thread result is more useful than a multi-thread aggregate.
A multi-thread test adds up the speed of several connections, so the figure it shows is usually higher than the bandwidth any single app can get. Web pages, video streams, and single download jobs are mostly single-threaded or use a limited number of connections — record and compare the two sets of numbers separately.
| Tool | What it measures | Best for | Watch out for |
|---|---|---|---|
| Speedtest（Ookla） | Download, upload, latency | Quick baseline; before/after route changes | Lock the same test server manually |
| Fast.com | Download bandwidth and latency | Judging bandwidth for streaming | No upload test; jitter and loss need another tool |
| Cloudflare Speedtest | Bandwidth, latency, jitter | A quick look at jitter | The node is chosen by the other network; you can't pick it |
| ping / mtr | Latency, jitter, hop-by-hop loss | Finding which segment of the path is failing | Needs a target address; ICMP may be rate-limited |
| iperf3 | Raw throughput, long-run stability | Self-hosted nodes, sustained load testing | Needs both ends set up; a higher bar to entry |
| curl -w | DNS lookup, connect, handshake, first-byte timing | Finding which step makes a page load slowly | Command-line output; you need to understand each stage |
How to Schedule Time Windows: Off-Peak vs. Evening Peak
Take at least two windows: one when your local network is idle (a weekday morning or afternoon) and one at the evening peak (20:00 to 23:00). Same node, same tool, three consecutive runs per window at least a minute apart, and take the median rather than the peak. Weekend evenings are usually more congested than weekdays, so add a weekend round if you want a sharper picture.
Cross-border access also means factoring in the other side's time zone: it may be the middle of the night where you are while the far end is in its busiest hours. This is where route types differ most visibly — direct and relayed routes both cross public international gateways and swing more at peak; IEPL dedicated lines run on separate channels and don't compete for public gateway capacity, so their off-peak and peak numbers usually sit closer together. That comparison says more about route quality than any single run.
Most speed-test servers sit at CDN edges. If the test domain matches a direct-connection rule, what you're measuring is your local broadband to the CDN — nothing to do with the proxy route. Check your routing rules before testing, or switch to global mode temporarily.
Three Metrics: How to Read Latency, Jitter, and Packet Loss
Bandwidth is the number everyone looks at, but three other metrics usually decide how the connection feels. Read them together — any one on its own tells you little.
Latency (RTT): compare the deltas, not the absolute value
Measured in milliseconds. Cross-border latency is naturally higher than local, so the comparison that matters is between two deltas: the gap versus your direct baseline (the extra cost the proxy and route add) and the gap between peak and off-peak (whether the path is congested). If the same route shows clearly higher latency at peak with jitter rising alongside it, it's almost certainly sharing a public gateway.
Jitter: the make-or-break metric for real-time audio and video
Jitter is the difference between two consecutive latency samples; it shows how steady the path is. Voice calls, video meetings, and competitive games are the most sensitive: however low the average latency, a large jitter still means dropouts and stutter. Run 20 consecutive pings on the command line and look at the spread between max and min — far more useful than the average.
Packet loss: the most overlooked metric, with the most direct impact
Even a few percent of packet loss makes TCP retransmit again and again; what you feel is pages spinning and progress bars stuck. QUIC-based protocols (Hysteria2, TUIC) tolerate loss better than TCP-based ones (Shadowsocks, VMess, Trojan, VLESS), at the cost of higher bandwidth use and a UDP forwarding path that has to hold up.
DNS resolution is another easily missed link: if the client's DNS requests don't travel through the proxy, a local resolver may send you to a distant entry point, which shows up as slow connection setup and slow first byte while bandwidth tests look perfectly fine. Print the per-stage timings with curl — a noticeably large time_namelookup is the signal.
| Metric | Unit | How to measure | What a higher value means |
|---|---|---|---|
| Latency (RTT) | Milliseconds | ping, mtr, speed-test sites | Longer or congested path; slower interactivity |
| Jitter | Milliseconds | Max minus min across consecutive pings | Dropouts and stutter in real-time audio/video |
| Packet loss | Percent | mtr hop statistics, ping statistics | More retransmits; downloads and pages slow down noticeably |
| Download / upload bandwidth | Mbps | Speedtest, iperf3, large-file downloads | Sets the ceiling for large files and video quality |
| DNS lookup time | Milliseconds | curl -w time_namelookup | Resolution takes a detour; first paint and connection setup slow down |
A Speed Test Routine You Can Reproduce
The sequence below pins down one variable at a time. Run through it once — about half an hour — and the results can be compared side by side.
- Fix the variables. Same device, same test server, same route, same protocol. Change any one of them and the comparison starts over.
- Clear the field. Turn off background downloads, system updates, and cloud-drive sync; use Ethernet instead of Wi-Fi if you can, and if you're on Wi-Fi, stay in the same spot.
- Measure the direct baseline. Turn the proxy off and record download, upload, latency, jitter, and loss. A number without a baseline has nothing to compare against.
- Measure the route. Turn the proxy on and confirm the test domain goes through it (global mode, or add the test domain to the proxy rules). Run three times at least a minute apart and take the median.
- Repeat in another time window. One round off-peak, one at the evening peak, recorded separately — the size of the gap between them is the point.
- Compare route types. One round each on direct, relayed, and IEPL dedicated routes in the same region, changing nothing but the route.
- Log everything. Keep a table with nine columns — date, time window, route, protocol, download, upload, RTT, jitter, loss — and look at the trend a week later.
The two steps people skip most often are the third and the seventh: without a baseline you can't tell how much overhead the proxy and route add, and without a trend you're drawing conclusions from a single run.
Reading the Results: Common Misjudgments
Once the numbers are in, how you read them matters just as much. The habits below either destroy comparability or mix problems from different layers together.
- ❌ Treating a single peak as the steady value: a high reading in the early hours doesn't mean it holds at the evening peak.
- ❌ Concluding anything without checking routing rules: if the test domain went direct, the two sets of numbers weren't measuring the same path at all.
- ❌ Testing download only: video meetings, cloud uploads, and remote desktop all run on upload bandwidth.
- ❌ Taking the test server's latency as page-load speed: DNS lookup, handshake, and first byte each add their own delay, and no amount of bandwidth rescues that.
- ✅ Fix the variables, run three times, take the median, then look at how far the evening peak drops from off-peak — the only reading that supports comparison.
- ✅ Track the trend over a week: route quality is a distribution, not a single score.
A speed test doesn't answer “which provider is fastest” — it answers “which segment of my connection is slowest”. Fix the variables, compare time windows, and repeat the measurements, and you can answer for yourself whether the marketing numbers deserve trust and whether a route holds up at the evening peak.
If the bottleneck consistently shows up at the international gateway during peak hours rather than in your local broadband or the test server, that's a route-type problem — switching to a route that doesn't compete for public gateway capacity is more useful than re-testing the same numbers. VPNEQ offers 100+ countries and 210+ routes, grouped by region with multi-route redundancy, works on Windows, macOS, iOS, Android, and Linux, with no limit on simultaneous devices — a useful reference route for your comparison table.