VPN speedtest comparison: start with consistent test conditions
Don't judge a VPN by its peak download speed alone. For a fair comparison, keep your device, network, test server, and client mode consistent, then compare latency, jitter, packet loss, and sustained download performance. Finally, test the sites you actually use to find the connection that works best for you.
A speed test involves several links in the chain: your local Wi-Fi, ISP connection, proxy route, exit network, and test server. Congestion at any point can affect the results. A slowdown only shows that the complete route performed poorly at that moment; it doesn't prove the server lacks bandwidth.
Pause cloud sync, system updates, and other downloads before testing, and use the same connection method each time. If possible, establish a baseline over a wired connection. If you can only use Wi-Fi, keep your device in the same place and connect to the same access point. Don't rank VPN routes by comparing results from home Wi-Fi with results from a network you're using elsewhere.
First test a server you can reach without a VPN, then connect to a route and test again. If the server isn't reachable before connecting, choose another accessible target to check your local network. Don't treat an unreachable server as having zero speed.
What different speed test tools can tell you
Use separate tools for overall speed tests, connectivity diagnostics, and real-world checks. They can complement each other, but don't rank results from different tools side by side. Test server locations, connection counts, and measurement methods vary, so results can differ.
| Tool or method | What it measures | What to watch for |
|---|---|---|
| Speedtest | Download, upload, and latency | Manually select the same test server each time, and note the app or web version |
| FAST.com | Connection performance to Netflix's test infrastructure | Doesn't predict speeds on every site or verify access to region-specific content |
| ping | Target response times, variation, and ICMP packet loss | Usually doesn't use a system proxy that only routes web traffic; the target may also limit responses |
| Browser developer tools | Connection, waiting, and resource download times for page requests | Caching, connection reuse, extensions, and the site's server can all affect results |
| Real-world video, calls, or file transfers | Buffering, call quality, and sustained transfer speed | Keep the content and quality settings consistent so platform limits aren't mistaken for connection issues |
Automatic server selection is convenient, but switching exit routes may cause the tool to choose a test server in a different region. That means you're comparing two different paths. Once you choose a server, note its name and region. If you can't keep it fixed, flag that in your results and give the comparison less weight.
Don't install untrusted tools just to collect every metric. Download clients from trusted sources. Online speed tests transfer real data, and repeated tests can quickly use up your plan allowance, so check your account usage before and after testing.
How to read latency, jitter, packet loss, and bandwidth
Latency: the basis of responsive connections
Latency is generally the time it takes data to travel to a target and back. It affects web connections, remote desktop sessions, and live calls, but it isn't the time it takes a page to fully load. Pages also run scripts, load images, and wait for the site's response, so low latency doesn't guarantee every page will open quickly.
Check latency both when the connection is idle and while downloading. If interaction becomes noticeably sluggish as soon as a download starts, the cause may be queue congestion or a saturated local upload connection. Looking only at idle latency can hide problems you'll encounter in actual use.
Jitter and packet loss: connection consistency
Jitter describes how latency changes over time, and different tools may calculate it differently. For comparisons over time, use the same tool. Two routes may have similar average latency, but the one that frequently slows down can still make calls and remote sessions noticeably worse.
Packet loss means some probe or transmission data didn't arrive as expected. However, routers may give ICMP responses lower priority, and a silent intermediate hop doesn't necessarily mean application traffic is being lost there. Check the final target and real-world app performance, and repeat the test. Don't draw conclusions from a single ping.
Download and upload: sustained performance
Download bandwidth affects large file transfers and video buffering; upload bandwidth matters for call quality, file uploads, and backups. Check whether the tool reports Mbps or MB/s: these are different units, so their numbers aren't directly comparable. Also distinguish a brief peak from sustained throughput. A fast start followed by a long slowdown doesn't mean the connection can maintain its peak speed.
How to compare and log results throughout the day
Testing in the morning, afternoon, and evening isn't about collecting more numbers; it's about seeing how your connection performs when you actually use it. Test during the hours that matter to you, under similar conditions, and don't treat an unusually high result on one day as the norm.
- Note your setup. Record your device, operating system, client version, network, wired or Wi-Fi connection, and whether other devices were transferring data.
- Check the traffic route. Record the route name, proxy mode, and test target. Confirm that test requests use the selected route before measuring.
- Use the same test order. Check idle response first, then run download and upload tests, and finally open the sites or apps you use. Don't run multiple speed tests at once and have them compete for bandwidth.
- Retest at different times. Use the same target and settings in the morning, afternoon, and evening. After switching routes, wait for the connection to stabilize before starting the next test.
- Keep the outliers. Record disconnects, reconnects, video buffering, and page failures—not just your best scores. Note any background tasks or network changes when an issue occurs.
A simple spreadsheet works well. Include the time, network, route, target, mode, latency, jitter, packet loss, download, upload, and real-world experience. Mark unavailable metrics as “not measured” instead of filling them in with results from another test. Recheck unusual results; keeping them is more useful than deleting them to show only the best scores.
Look at typical performance before judging variation. A route that's reliable during the hours you use it may suit you better even if its peak speed isn't impressive. If results fluctuate, first make sure your local setup and test target haven't changed, then consider route congestion.
Check split tunneling and DNS to make sure you're testing the right route
System proxy, rule-based routing, and TUN mode aren't the same thing. A system proxy usually affects only apps that honor its settings. Rule-based routing chooses a path based on conditions such as domain or address. TUN mode uses a virtual network interface to capture matching traffic, but routing and exclusion rules still apply.
So, traffic from your browser may use a proxy while ping traffic from your terminal does not. Check the client's connection log or rule-match records to confirm that the test domain uses the expected exit route. Network extensions and app behavior vary across platforms, so record cross-platform results separately rather than attributing every difference to the route.
DNS resolution maps domain names to IP addresses and can affect how a content delivery network routes requests. Your browser's secure DNS, system resolver, and client DNS settings may all be active. If your rules expect DNS requests to use a particular route but they take another, check the configuration instead of repeatedly switching routes.
- ✅ Check the client connection log to see which rule and exit route matched the test request.
- ✅ Use the site's network check to verify exit details, then compare them with the client logs.
- ✅ Check whether your browser's secure DNS conflicts with the client's DNS policy.
- ❌ A changed exit IP alone doesn't prove that all apps and DNS requests are being routed as expected.
DNS test pages typically show information about the resolver. An unfamiliar region or provider isn't, by itself, proof of a leak. Check the expected configuration and client logs, and repeat the test.
How dedicated lines, relays, direct connections, and protocols affect results
A direct connection generally means the client connects straight to a server outside your local network; a relay typically routes traffic through an access or forwarding server first. IEPL describes how a route is carried, not a client protocol. These labels tell you about the route design, but they can't replace measurements from your location to the entry point and from the exit point to the target. They also don't mean every destination will be equally fast.
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are different proxy protocols or implementations. Performance can depend on the transport method, encryption settings, client support, and server configuration. A protocol's name alone doesn't predict its speed, so don't assume one is always faster.
If your subscription offers multiple configurations, start with one your client explicitly supports, then keep other conditions consistent as you compare them. A subscription link is a way to retrieve configuration, not proof of speed. It may also contain access credentials, so don't post it in public test reports or paste it into unfamiliar online conversion tools.
When comparing protocols, record the client and transport settings too. Otherwise, differences may come from the client implementation, device performance, or local network support for the transport—not just the route itself.
Why a speed test looks fast but browsing is still slow
Start by checking how widespread the problem is. If every target is slow, check your local network, background activity, client mode, and current route first. If only one site is slow, check its service status, DNS results, regional routing, and app-specific limits. A fast test server only shows that the route to that particular target is performing well.
For video, keep the content and quality settings fixed and watch for buffering and playback interruptions. If a speed test shows plenty of bandwidth but a video won't play, the cause may involve your account, content region, or how the platform evaluates your exit route. A higher download peak won't necessarily fix it. For calls, check for audio dropouts, frozen video, and upload congestion during an actual call.
If web pages are slow but file downloads are fine, use your browser's developer tools to break down DNS lookup, connection setup, response wait, and resource download times. Caching and connection reuse can change the results, so keep conditions consistent. When reporting an issue, include the time, route, target, and mode. Hide your subscription link and account details in screenshots.