VPN speed testing compared: a complete, hands-on guide to objective speed tests

A useful VPN speed test isn't about finding the biggest download number. Keep test conditions consistent, then see how reliably each route handles real tasks. Results can vary with your device, test server and routing rules—even on the same route. Record the setup first, then compare latency, bandwidth and packet loss.

This guide offers a method you can reproduce yourself, not a preset ranking of routes. You'll need your usual client, a speed test tool that lets you select a fixed server, and a simple log.

Choose speed test metrics based on how you use your connection

“Fast” isn't a single metric. Web browsing, video streaming, file transfers and video calls all place different demands on a network. High download bandwidth doesn't guarantee responsive pages, and low latency doesn't mean large files will transfer quickly for long. Note the problems you encounter most often before testing, so you don't draw conclusions from irrelevant numbers.

Check bandwidth units, too. Speed test tools commonly report Mbps, while download apps may show MB/s. The former measures bits and the latter bytes, so the numbers aren't directly comparable. Keep the tool's original units in your notes and distinguish uploads from downloads to avoid mistaking a unit difference for a slowdown.

Set up your test: account for local interference and routing

Start by keeping your device and network conditions consistent. Computers and mobile devices differ in Wi-Fi connections, processing power and background activity, so they aren't ideal for direct route comparisons. Use a wired connection if possible. If you must use Wi-Fi, keep your location, band and router the same, and pause cloud sync, system updates and other ongoing transfers.

Next, make sure test traffic actually goes through the route you're evaluating. A system proxy usually affects only apps that follow proxy settings, while tunnel or virtual network adapter modes cover more traffic and can still be affected by routing rules. A browser speed test going through the proxy doesn't mean command-line tools use the same path. Automatic route-selection groups may also switch exits during a test, so select a fixed node first.

• ✅ Use the same device, network and speed test tool.
• ✅ Note the client mode, selected route and routing rules; don't change them during testing.
• ✅ Turn off other proxy extensions and pause background tasks that use bandwidth.
• ✅ Check your browser's exit IP with IP check, and review the actual route in the client connection log.
• ❌ Don't assume a browser exit check applies to every app on your device.

Choosing a tool: keeping the target fixed matters more

Browser-based speed tests are useful for quickly checking downloads, uploads and latency under load, but watch for automatic server changes. Different exits may be assigned different test servers; in that case, results reflect both a route change and a server change, so you can't attribute the difference to the route alone. For a fair comparison, manually select the same target and note its region and operator.

A client's built-in latency test is useful for an initial check. Depending on how it's implemented, it may measure connection time to a node or access a specified URL through that node. The result can help confirm connectivity, but it can't replace a full bandwidth test. Latency readings from different clients may not be directly comparable if they use different probe addresses.

The command-line ping tool can show a target's round-trip time and whether it responds, but its ICMP probes may not use a standard system proxy. Some servers also limit or deprioritize probe responses, so “no response” doesn't necessarily mean web traffic is losing packets. Interpret traceroutes in the same way: an intermediate hop that doesn't respond isn't proof of a fault on its own.

Finally, cross-check with a real task: open a site you use regularly, download a file from a reliable source, or test an actual meeting. Synthetic speed tests emphasize sustained transfers; real apps also depend on DNS resolution, connection setup, content delivery and server processing. They answer different questions.

A repeatable testing process

1. Record a direct-connection baseline. Measure your local network's baseline performance against a test target that works without an international route. If the direct connection is already unstable, check for Wi-Fi interference, router load and broadband issues first. The baseline helps locate problems; it doesn't have to reach every target.
2. Fix the route and test server. Select a node, then verify the exit and routing behavior before testing. When comparing another route, keep the server, client mode and tool settings the same; change only the route being tested.
3. Repeat measurements and keep outliers. Don't save only the best result. Wait for each transfer to finish and the network to return to idle before testing again. Check whether results cluster; if they vary widely, record the range or median and note any failures or interruptions.
4. Rotate the test order. Don't always test the same route first, or brief network changes may look like route differences. If Wi-Fi switches networks or a background download starts during a test, flag that result and verify it again.
5. Test at the times you actually use the service. Repeat the process during your usual daytime and evening hours, especially when problems tend to occur. Retest on different days as well; one peak or low point doesn't represent long-term performance.
6. Check real-world tasks. Compare page responsiveness, video buffering and upload stability. If a route that leads in a speed test performs worse in the app you care about, rely on repeated tests in that app.

At a minimum, log the date and time, local network, device, client mode, route name, exit region, test target, results for each metric and real-world experience. Don't expose subscription links, account credentials or full connection settings in screenshots. Test conditions are more useful than configuration details when sharing results.

How to investigate inconsistent results

Good bandwidth, but pages take ages to load

Start by checking DNS resolution and connection setup. Slow DNS lookups, an unsuitable content delivery network (CDN) location, or separate encrypted DNS settings in your browser can all delay the initial page load. Check browser, system and client DNS policies together; changing the resolver alone doesn't prove the issue is fixed.

A DNS leak concerns whether DNS requests follow the expected route; it's not a download-speed metric. A different DNS provider or region from your exit location doesn't by itself prove a leak. Check your routing policy and the actual query path. Don't disable necessary DNS protection or change rules you don't understand just to improve a speed test result.

Downloads are fine, but calls lag during uploads

Check latency under load, then retest with uploads paused. If the problem appears during uploads, possible causes include local upstream congestion, router queueing or a link bottleneck. Switching routes may not resolve a local bottleneck. Limiting background sync speeds and reviewing your router's queue management settings are usually more targeted than repeatedly changing test servers.

Only one route or website performs poorly

If the same target consistently differs across routes, compare exit routing and congestion. If only one website is slow, also consider the site's load, its content delivery path and platform restrictions. Direct, relayed and dedicated routes describe how a connection is organized; their names alone don't predict speed. Test the complete path to the target app under the same conditions.

Protocol names aren't a speed ranking, either. Performance depends on each protocol's transport mechanism, client implementation and how your local network handles its traffic. When comparing protocols, keep the region and target as consistent as possible. Don't change your device, exit and rules at the same time and attribute every difference to the protocol.

How to write a credible comparison

Keep conclusions within what your tests can support. For example, “On my current network in the evening, this route had less variation when accessing the test target” is more accurate than “This route is always the fastest.” Report the test conditions, typical performance, anomalies and intended use so others can repeat the test.

When choosing a route, first rule out options that repeatedly fail to connect or are clearly unstable, then compare them for your needs. File transfers depend more on sustained throughput, while calls and remote work depend more on responsiveness and consistency. For websites and AI tools, also check whether access works, how quickly the first response arrives and whether the session stays stable. Speed test results can't resolve a platform's regional policies or account status.

If you're still unsure, share redacted test notes with the Help Center for further troubleshooting. Describing when the issue occurs, what network you're on and which tasks are affected is usually more helpful than simply saying “it's slow.”