How to compare VPN speed tests: tools, timing and metrics

Keep test conditions consistent for VPN speed tests

For a useful VPN comparison, first record your local network performance without a VPN. Then keep your device, client, test target, and testing times consistent while checking latency, packet loss, download speeds, and real-world app performance. A single speed test screenshot only reflects the route at that moment; it cannot prove that a server is faster over time.

Start by identifying what you want to fix: slow-loading pages, video that keeps buffering, or unreliable downloads. Different tasks depend on different metrics. Web browsing is sensitive to request round trips and connection setup, sustained downloads depend more on throughput, and live streams need a steady connection without frequent interruptions. Match your test to your use case instead of chasing the biggest number.

Compare results on the same device and type of connection whenever possible. Use a wired connection if you can; on Wi-Fi, keep the device in the same spot and use the same band. Pause cloud backups, system updates, and other large transfers, and check that no one else on the network is downloading heavily. Otherwise, changes may be caused by local wireless interference or competition for your home bandwidth.

• ✅ Note your local ISP, connection type, device, and client version.
• ✅ Use the same speed test server or download source, and note its region.
• ✅ Record the selected server, client mode, and actual exit region.
• ✅ Keep a baseline without the VPN, and retest your local network if results look unusual.
• ❌ Don’t rank screenshots taken on different devices, servers, or at different times.

Choosing speed test tools and metrics

Browser-based speed tests are useful for checking throughput and latency when idle and under load, but their automatically selected server may change with your exit location. To compare routes, keep the target server the same. If the tool won’t let you select a server, record its name and region so you don’t treat results from different routes as a like-for-like comparison.

Built-in server tests in VPN clients are usually better for shortlisting servers than drawing final conclusions. Some measure connection setup, others check a web response, and some only test the server port. First check how the tool defines “latency.” A response time shown in the client may not match the round-trip time for a game, video, or website you actually use.

What latency, packet loss, and speed tell you

Low latency doesn’t guarantee fast downloads

Latency usually measures how long data takes to make a round trip. Distance, routing, and queueing all affect it. Jitter describes how much latency varies: two routes with similar averages can feel very different if one fluctuates more. Record the median as well as slower samples, and don’t keep only the fastest result.

When bandwidth is saturated, a router or other device along the route may queue data, increasing latency. That’s why a connection can look fast while idle but feel sluggish during a download. If your test tool reports latency under load, check it alongside idle latency. Also retest without the VPN to see whether congestion is already present on your local connection.

Interpret packet loss in light of how you tested

Missing responses in system ping don’t necessarily mean app traffic is being lost. Some devices prioritize forwarding regular traffic while limiting ICMP responses. Standard system proxies typically don’t route ping either; whether TUN mode handles it depends on the client. Results are comparable only when you’ve confirmed that probes use the route being tested.

Download speed reflects the entire connection: your local access network, proxy entry point, international route, exit, and destination server can each become a bottleneck. Check the units, too: megabits per second and megabytes per second are not the same. Multi-connection tests can mask a single-connection bottleneck and don’t replace a real browser download or in-app transfer.

Run repeatable tests at different times

Peak hours don’t just mean evenings where you are. The route’s entry or exit region, or the destination service, may also have busy periods. Record the local time and time zone, test when you normally use the service, and keep a quieter period as a comparison. Don’t test only when the network is idle and assume performance will be the same at peak times.

1. Establish a baseline. Disconnect from the proxy and record a local speed test and reference sites you can access normally. Don’t force inaccessible destinations into the disconnected baseline; that could confuse access restrictions with bandwidth differences.
2. Confirm the route. Connect to the server you’re testing, check the client’s connection log, and verify your exit with What’s my IP. A changed exit only confirms that the lookup request took a different route. Make sure the speed test target also matches a proxy rule.
3. Use the same tools. Stick to the same speed test server, file source, or webpage. Don’t run multiple speed tests at once, and keep cache and login state as consistent as possible.
4. Alternate between routes. Rotate through candidate servers instead of testing one completely and waiting a long time to test another. Repeat the checks and record typical results and clear outliers; don’t cherry-pick the best-looking samples.
5. Test your use case. Open the app you actually use and note loading, buffering, and reconnects. If the speed test looks fine but the app doesn’t, check your rules, account region, and the service’s status.
6. Recheck unusual results. Return to your local baseline, then try another destination or candidate server. Use the changes to narrow down the cause instead of immediately blaming the provider for every problem.

Copy the fields below into a local note and fill them in for each test. Record only the subscription name, not the full subscription URL. Before sharing screenshots, hide tokens, account details, and other access credentials.

Test date, local time, and time zone:
Local ISP and connection type:
Device, client, and version:
Server name, protocol, and exit region:
Proxy mode and matching rules:
Tool, target server, or file source:
Idle latency, latency under load, and jitter:
Missing responses and probe method:
Download, upload, and displayed units:
Page load, video buffering, or reconnects:
Disconnected baseline and results of follow-up checks:

Route types and client variables

Direct connections, relays, and IEPL describe different things. A direct connection generally means the client connects straight to the service’s entry point. A relay adds a forwarding hop to adjust the entry point and route. IEPL refers to a dedicated-line transport method, but the label alone doesn’t mean every segment between your device and the destination website uses a dedicated line—especially your local connection and the route from the exit to the destination.

You can’t conclude that relays are always slower or dedicated lines always faster. An extra forwarding hop may avoid congestion, while a dedicated line can still be affected by entry capacity, shared resources, and the exit route. Note the route type provided by the service, but base your conclusions on performance under consistent test conditions. A nearby server region doesn’t guarantee a shorter route, either.

Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are different proxy protocols or approaches, not speed tiers. Transport settings, client implementations, how the network handles UDP, and device performance can all change the results. When comparing protocols, keep other conditions as consistent as possible; don’t attribute differences between routes in different regions or with different exits to the protocol itself.

Windows and macOS clients often offer modes such as system proxy and TUN. On iOS and Android, clients typically use the system VPN interface to route selected traffic, but the actual scope still depends on client settings. The same subscription may use different rules, DNS settings, or protocol support in different clients. Sign in to get your subscription, then import and update it according to the client’s documentation. VPNIW clients are provided according to your account plan; don’t look for installation packages from unknown sources.

Troubleshooting routing rules and DNS issues

In rule-based mode, a speed test site may connect directly while your target app uses the proxy. In that case, the “VPN speed” you’re measuring is actually your local network speed. Check the client’s connection log to confirm which policy matched the test domain and request. If you temporarily switch to global mode to verify, restore your original settings afterward and note the mode change in your test log.

DNS controls how domain names are resolved and can also affect which server a content delivery network selects. Slow resolution can delay the first page load without reducing sustained download speeds afterward. Keep DNS settings consistent when comparing routes. Browser secure DNS, system resolution, and client-side resolution may overlap; check the client documentation to confirm the actual route.

A DNS leak usually means queries that should use the expected protected route are still going to another resolver. Resolver names shown by a test page are clues, not proof of a leak based on region or name alone; check routing rules, browser settings, and connection logs together. Keep IPv6 in mind, too: some requests may take a different route than IPv4, causing exit checks and app behavior to disagree.

Use your results to choose a route

When reviewing results, group them by test target and time of day, then compare medians, variability, and failures. A route with a high peak speed but frequent interruptions may not suit continuous streaming. Another route with a lower peak that reliably meets the app’s needs may be better for everyday use. Smooth performance in real tasks matters more than a single peak-speed ranking.

If every route and your disconnected baseline are slow, start by checking your local connection. If only one destination is affected, check the service and the route to it. If one route repeatedly has problems, consider switching and share the test time, server name, client version, and redacted logs with support. This information is more useful for diagnosing the issue than “the speed is slow.”

Keep your data usage in mind when testing. VPNIW monthly subscriptions reset each month on the activation date, and data packages remain valid until used with no expiration. Repeated speed tests use data from the same account, and unlimited devices don’t eliminate competition for bandwidth during simultaneous transfers. Check your allowance on the Plans page, or use the Troubleshooting guide to investigate connection issues.