VPN speed tests: first check which part of the route you're measuring
How do you test VPN speed accurately? Keep the device, route, test server, and proxy mode consistent, then repeat tests at your usual times. Peak download speed is only part of the picture: judging web browsing, video buffering, or choppy calls also means looking at latency, jitter, packet loss, and sustained throughput.
A speed test usually follows a route from your device through your local network and ISP, then through the service’s entry point and exit, and on to the test server. Congestion anywhere along the way can affect the result. A speed test therefore reflects the performance of the entire route at that moment—not an isolated rating of a particular server.
First, make sure the test traffic actually goes through the proxy. Split-tunneling rules may send a speed test site over a direct connection, or route browser traffic through the proxy while command-line tools connect directly. Check the client’s connection log and rule matches, and compare the exit IP in the same tool environment. Checking your IP in a browser alone doesn’t prove that every app uses the same route.
Understanding latency, jitter, and throughput
“Fast” means both quick responses and smooth data transfer. Low latency matters for interactive tasks; high throughput helps move data. The two are related but aren’t interchangeable. Pages also need to resolve a domain, establish a connection, and wait for the server to respond, so a strong download result doesn’t necessarily mean pages will load quickly.
| Metric | What it measures | Common use cases | Common pitfalls |
|---|---|---|---|
| Latency | The round-trip time for a request to reach a specified destination and return, usually measured in ms | Web browsing, remote access, voice calls | Latency reported by the client may differ from latency in an app |
| Jitter | How much latency varies over time | Video meetings, calls, real-time interaction | Low average latency can still hide sharp moment-to-moment spikes |
| Packet loss | When a test packet fails to arrive or no response is received | Investigating dropouts, retransmissions, and stalled connections | Test packets may be rate-limited or filtered, which doesn’t necessarily mean app traffic is also being dropped |
| Download throughput | The amount of data received per unit of time, usually measured in Mbps | Video buffering, file downloads | A brief peak doesn’t represent sustained speed over time |
| Upload throughput | The amount of data sent per unit of time | Cloud backups, file uploads, video calls | Looking only at downloads can miss problems caused by limited upload speed |
It’s also worth distinguishing idle latency from latency under load. A route may respond quickly when idle but slow down considerably when a download or upload saturates the connection. This can point to queueing, router buffering, or bandwidth contention. If latency rises only under load, don’t assume the exit is simply too far away.
Jitter calculations and sampling methods vary between tools, so their results shouldn’t be compared side by side without care. Download apps often use MB/s, while speed test sites usually report Mbps; the numbers aren’t comparable at a glance. Keep the original units in your notes and convert them only if needed.
Comparing speed test tools: separate diagnostics from real-world app testing
Choose a tool based on the question you’re trying to answer. To check large-file transfer performance, measure throughput. To investigate slowdowns, look at latency and connection setup. To find out whether a service works smoothly, test it in the app itself.
| Tool or method | What it can help assess | What to keep in mind |
|---|---|---|
| Speedtest | Download, upload, and latency to a selected test server | Keep the server and test mode fixed so automatic server selection doesn’t change the conditions |
| Fast.com | Transfer performance to Netflix’s content delivery infrastructure | Doesn’t represent speeds on every streaming platform or confirm access to a particular library |
| Ping and traceroute | Latency changes to a responsive destination and clues about parts of the network route | Standard proxies may not forward ICMP; a nonresponsive hop doesn’t necessarily mean the route is broken |
| Browser developer tools | Domain lookup, connection setup, response wait time, and resource loading | Check cache state, where page resources come from, and proxy rules |
| Using the target app | Playback buffering, call quality, download stability | Also affected by the app’s servers, account permissions, and content delivery policies |
The automatically selected test server may change when your exit route changes. If results improve after switching routes, the test endpoint may simply be closer—not evidence that the route is better overall. For a fair route comparison, keep the endpoint fixed where possible. To understand everyday performance, also test the services you actually use.
Command-line tools are useful for repeatable tests, but check how they handle proxies first. Some read proxy environment variables, some need separate configuration, and others bypass the system proxy. If browser tests work but terminal tests fail, check the route before drawing conclusions about the connection.
Repeatable real-world testing: steps and how to log results
A useful test log should let you remember exactly how you ran the test. You don’t need a complex dashboard: note your network setup, client mode, route, destination server, time, and real-world experience. The fewer conditions you change, the easier it is to explain differences.
- Establish a local baseline. Pause cloud sync, system updates, and other bandwidth-heavy tasks. Check that your local connection is working normally. Use a wired connection if available; on Wi-Fi, keep the device in the same place and use the same band.
- Keep test conditions consistent. Use the same device, client version, and speed test tool, and select the same test server. Note whether you’re using the system proxy, rule-based routing, or a virtual network adapter, and confirm that the test request actually uses the selected route.
- Check idle and loaded performance. Record response times while the connection is idle, then run download and upload tests. Watch for pauses during transfers and slower interactions while the network is busy; don’t just capture the highest speed.
- Repeat tests and keep the full results. Run tests again under the same conditions and check how closely the results cluster. With enough samples, the median can describe typical performance. Keep outliers and failed runs too—don’t record only the fastest result.
- Test the app you care about. Play content you watch regularly, open a familiar site, or make a test call. Note any buffering or long waits, and check for error messages from the app itself.
- Change one variable at a time. Keep everything else the same while comparing routes, network connections, or client modes. Changing only one factor at a time makes it easier to identify what caused a difference.
You can use these fields in your test log: date and time, network connection, device and client, proxy mode, route name, test server, download and upload speeds, idle and loaded latency, and real-world app performance. If a tool doesn’t report a metric, mark it “not tested” rather than estimating a value.
When to test—and why peak hours matter
Choose test times around your own routine, not just the hours most likely to produce a high score. If you work online during the day and stream in the evening, record results in both situations. ISP and service workloads vary by location, so there’s no single congestion window that applies to everyone.
Keep conditions consistent, compare your usual busy hours with a quieter period, and repeat the tests on different days. If throughput drops and latency becomes more variable in the evening, then recovers during quieter hours, the route may be experiencing time-dependent resource contention. The bottleneck could be your home network, local ISP, service entry point, or destination server.
Direct connections, relays, and IEPL dedicated lines describe different network arrangements; none is a substitute for testing. A relay adds steps to the route, but a well-chosen entry point and route may improve performance. IEPL dedicated lines can still be affected by shared resources and exit capacity. The name can help explain the route, but it can’t guarantee end-to-end performance.
Protocol names aren’t speed rankings either. Performance depends on the connection protocol, transport, device, and network conditions. Tests are meaningful only with configurations supported by both the client and server. Don’t enable configurations from unknown sources just to compare speeds, and don’t post subscription links in public test reports.
Troubleshoot based on symptoms, not by switching routes repeatedly
- ✅ Every route is slow: Check your local network, background uploads, Wi-Fi signal, and device load first. Then test on another network to see whether the issue changes with your local environment.
- ✅ Only one speed test site is slow: Keep the conditions the same, try a different test endpoint, then check the target app. The test server may be busy, or the route from your exit to that server may be different.
- ✅ High test scores, but slow websites: Check DNS lookup, connection setup, and time to first byte. Review which client rules were matched and confirm that page resources aren’t taking a different route.
- ✅ Video works smoothly, but calls are choppy: Check upload throughput, jitter, latency under load, and the app’s real-time connection. Don’t keep comparing download peaks alone.
- ❌ Assuming a connection is unusable because ping gets no response: The probe may be filtered or may not go through the proxy. Check a real connection and app request as well.
DNS also needs to be considered separately. A DNS leak means lookup requests aren’t following the expected route; it doesn’t mean that DNS is slow. Checking the exit IP alone won’t reveal differences in the DNS route. Check the client’s DNS configuration, system settings, and test results. How DNS is handled varies by operating system and proxy mode, so follow the current client’s instructions.
System proxy and virtual network adapter modes may cover different traffic on Windows, macOS, and Linux. On mobile devices, battery-saving features and background app restrictions can also matter. When comparing platforms, note these differences instead of treating phone and computer results as evidence that one route is better.
When contacting support, share only anonymized test conditions, time, route, tool, and symptoms. Don’t post subscription links, account credentials, or full configurations publicly. Check screenshots for sensitive details before sharing them too.