A useful VPN speed test comparison depends on consistent conditions, not finding the highest score. First establish a baseline for your local network, then compare routes using the same device, destination, and test method. Finally, check performance in the apps you actually use. A single download-speed screenshot can't show whether video calls will be stable or whether a connection will hold up during peak hours.
Key metrics: What to look at beyond download speed
A connection path includes your local network, the route's entry point, its exit point, and the destination server. A speed test describes how that entire path performed during the test—not a fixed, permanent capability of any one server. Understand the metrics first to tell whether to switch routes or troubleshoot your Wi-Fi.
| Metric | What it means | What to look for | Common misinterpretations |
|---|---|---|---|
| Round-trip latency | The time it takes for a request to reach its destination and for the response to return, usually measured in ms. | Video call interactions, remote desktops, and web requests. | Low latency doesn't necessarily mean large files will download quickly. |
| Jitter | How much latency varies across consecutive measurements. | Whether audio cuts out or video speeds up and slows down. | Tools may calculate jitter differently, so their results aren't always directly comparable. |
| Packet loss | When a test packet doesn't receive a response according to the tool's criteria. | Whether ongoing packet loss coincides with freezes, retransmissions, or disconnections. | Devices may limit probe packets, so verify results in the apps you use. |
| Download and upload throughput | The amount of data transferred per unit of time, commonly measured in Mbps. | Downloading files, uploading attachments, and sending video during a call. | A peak speed doesn't represent the sustained speed of the entire transfer. |
| Latency under load | Response time measured while uploads or downloads are using the network. | Whether other interactive tasks slow down noticeably during a file transfer. | Latency may look normal when idle, but queues can build up under load. |
Keep the units when recording speeds. Speed test websites commonly use Mbps, while download apps may show MB/s; don't compare the numbers alone. Also, don't assume a client's listed “latency” reflects the response time of the service you're using. Some clients test their connection to a server; others send a request to a specified URL. The destinations and request paths differ.
Choosing a tool: Check which path it measures
Browser-based speed tests are useful for measuring throughput across the entire connection path. You can use Speedtest or another tool that shows its test server, but select the same server manually each time. Automatic server selection may change when your exit point changes, so switching routes could also switch the test destination—and introduce differences in distance and server load.
Your system's built-in ping is useful for checking basic round-trip connectivity, but it typically sends ICMP packets. With system proxy mode enabled, these packets generally don't pass through the application proxy. Whether TUN mode captures them depends on the client implementation. So a low latency shown in your terminal may not reflect the active proxy route. An HTTP probe in the client is closer to a web request, but check its target and routing rules too.
For sustained throughput testing, you can use iperf3, but connect only to a server you're authorized to use. Congestion and limits on public servers can skew results, so don't use them as the sole measure of a route's capacity. Most people don't need to set up a dedicated test environment: use a fixed browser speed test server, then check an actual call or file transfer for results that are easier to reproduce.
Before testing, make sure the test traffic is actually going through the selected route. Check the client's connection log, including the matched rule, exit address, and test destination; don't rely only on its connected status. Logs may include destinations you visited, so redact sensitive details before sharing them.
Set a baseline: Rule out local network issues
Pause cloud sync, system updates, and background downloads first. Keep the device in the same location and use the same connection method; use Ethernet if possible to avoid Wi-Fi fluctuations. Don't run multiple speed tests at once: they'll compete for bandwidth, and you'll measure their combined effect instead.
Turn off the proxy and test a destination your local network can access directly. Check whether baseline latency and sustained transfers are normal. If the direct connection also stalls repeatedly, troubleshoot your router, wireless interference, and internet connection first. This baseline helps identify local problems; it doesn't mean that a direct test to a domestic destination can be fairly compared with an international proxy test. They use different paths.
- ✅ Note the device, operating system, client version, and connection method. Keep them consistent for future comparisons.
- ✅ Check your plan status, remaining data, and subscription updates to avoid mistaking an account issue for a route performance problem.
- ✅ Record whether you're using system proxy or TUN mode, your routing rules, and the current server. Confirm where the test traffic is actually going.
- ✅ Close other network-intensive tasks. Finish testing one item before starting the next.
- ❌ Don't rank screenshots taken on different devices, in different Wi-Fi locations, or with different test servers.
A subscription link is a credential the client uses to retrieve configuration; it isn't a speed test URL. After importing it, update the configuration and then select a route. Don't share the full link with unfamiliar speed test sites or include it in public screenshots. See the Guides for client downloads and subscription setup.
How to test during off-peak and peak hours
Test during the hours when you usually use the service, not only when the network is quiet. Peak hours vary by region and internet provider, so use the busy times you actually experience. Follow the same steps during both off-peak and busy periods to see how the route responds to changing network load.
- Keep test conditions consistent. Note the test destination, network connection, client mode, and server. Make sure nothing is transferring data in the background.
- Check idle response first. Record latency variation and any interruptions, not just the lowest value. If the tool reports packet loss, note the probe method.
- Then test throughput. Record download speed, upload speed, and latency under load. Check whether speeds hold steady rather than spiking briefly.
- Test other candidate routes. Keep the destination unchanged and follow the same steps. Later, reverse the test order to reduce bias from changing conditions over time.
- Retest unusual results. If performance is clearly off, check your local baseline first, then repeat the same test. Keep the anomalous result in your records instead of selecting only the best-looking one.
- Check the apps you actually use. Open your usual video call, collaborative document, or streaming service and assess responsiveness, buffering, and performance over time.
Keep at least the date and time, internet provider, connection method, server, test destination, test mode, metrics, and real-world experience in your log. After repeated tests, compare typical results and their range of variation—not just the single highest value. Speed tests use data, especially high-throughput tests, so there's no need to run them repeatedly just to chase a peak.
Interpreting results: Compare by use case, not by one metric
For video calls, prioritize consistent responsiveness, stable upload speeds, and noticeable jitter during busy hours. Remote desktops depend more on interaction latency. Large downloads depend on sustained throughput and successful retries. Video playback also depends on the content server assigned by the platform, account status, and caching, so a speed test download result can't replace checking playback itself.
If downloads are fast but pages take a long time to appear, check DNS resolution, connection setup, and routing rules. DNS translates domain names into addresses; the resolver and the path DNS requests take can affect the results. A DNS leak occurs when DNS requests follow an unintended path. This can affect both privacy and the browsing experience. You can't diagnose one from slow page loads alone; check your client's DNS settings and the actual resolution path.
If a speed test looks fine but one app stalls, check whether it follows different routing rules. A browser may use the system proxy while other apps don't. TUN can capture more traffic, but behavior still depends on routing, exclusions, and client implementation. Change one setting at a time and retest; if you change DNS, protocol, and server all at once, you won't know which change made a difference.
Choosing a route: Prioritize routes that stay consistent during the hours you use them and work well in your actual apps. A high peak score with frequent interruptions shouldn't outrank a stable route based on download speed alone. State the network, destination, and test time behind your conclusion; don't present it as a ranking that applies to everyone.
Routes and protocols: What test results can tell you
A direct connection typically reaches an exit server from your local network without an intermediate relay. A relayed connection adds a forwarding step, and performance depends on the entry point, transit network, and exit. IEPL describes how a dedicated line is organized; it's not an application protocol, nor does it mean every segment between your device and the destination website uses that line. Even with stable transit, your local connection or the path from the exit to the destination can still be a bottleneck.
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC use different transport mechanisms and implementations. There's no fixed speed ranking independent of the client, server configuration, and access network. Hysteria2 and TUIC are based on QUIC and rely on UDP paths, so performance may change if your network restricts UDP. Other protocols are also affected by their specific transport settings, device capabilities, and server load.
When comparing protocols, keep the exit and destination as consistent as possible, and note the factors you couldn't control. Operating system network interfaces, background policies, and client implementations can also differ across platforms. Desktop results can help shortlist routes, but test them on mobile over the network you'll actually use; don't assume the same results will apply.
Keep useful records: Make issues reproducible
Your final notes should include test conditions, raw results, and what you experienced. For example, “During busy hours on the same connection, video calls froze while uploading; switching routes helped” is more useful for troubleshooting than “the speed is bad.” If multiple routes slow down at the same time and the direct-connection baseline is also abnormal, check the local network they have in common first.
For help, use the contact options and include your client version, when the issue occurred, the route name, and the troubleshooting steps you've tried. Redact subscription credentials, account details, and browsing activity from screenshots. See troubleshooting for more steps. The goal of an objective speed test isn't to prove one route is always the fastest; it's to find an option that suits your current network and needs, and that you can test again over time.