A useful VPN speed comparison starts with testing the same conditions. Keep the device, network connection, client mode, and test server consistent, then compare latency and throughput at different times. Finally, check the websites or apps you actually use. A peak-speed screenshot alone says little about everyday performance.
This guide offers a repeatable testing method, not a ranking of VPN routes or unverified speed claims. Use it to compare routes you’re considering and work out whether an issue is more likely with your local network, proxy path, or destination service.
Choose your speed test goal: downloads, browsing, or video
For large downloads, focus on sustained throughput. When browsing, you’re more likely to notice connection setup, DNS lookup, and request-response delays. Video calls also depend on jitter, packet loss, and upload performance. Write down what you use the connection for first, so you know which metrics matter most.
A common mistake is using a speed test app’s download peak to judge every use case. Test tools may open several connections at once to use as much available bandwidth as possible. Real apps may use fewer connections or be limited by the server. A high test result alongside average download speeds doesn’t necessarily mean the test is fake; the workloads may simply differ.
Another common mistake is treating the region in a server name as a complete picture of the route. Region labels can help identify the exit location, but they don’t reveal the entry point, ISP peering, return path, or congestion. When comparing routes, note the full name shown in the client and the test server—not just “Japan route.”
Tools and metrics: latency isn’t download speed
Choose a speed test tool that reports the test server, download speed, upload speed, and latency. If you can select a server manually, keep it fixed. If the tool chooses automatically, note which server it assigns. Results from different servers can help with troubleshooting, but shouldn’t be combined into a route ranking.
| Metric | What it measures | Best used for | Common misconception |
|---|---|---|---|
| Idle latency | Round-trip time to a specified destination under low load | Getting an initial sense of interaction delays | Low latency always means fast downloads |
| Loaded latency | Round-trip time while uploading or downloading | Checking for noticeable lag while the connection is busy | Overlooking queuing on the local router |
| Jitter | How much latency varies across test samples | Real-time apps such as calls and voice chat | Looking only at average latency and ignoring variation |
| Packet loss | When a response isn’t received using a particular probing method | Investigating instability alongside real app performance | Mistaking rate-limited probes for lost application traffic |
| Download and upload throughput | The rate at which data is transferred during the test | File transfers, cloud sync, and video uploads | Treating a momentary peak as sustained performance |
Check what your client means by “latency test.” It may measure the connection to the entry point, request a URL through the proxy, or simply check whether a connection can be established. Results from different clients or probe destinations aren’t directly comparable. System ping usually uses ICMP and may not follow the same path as app traffic through a proxy.
Keep the units shown by the tool. Bandwidth tests often use Mbps, while download apps may show MB/s; these are different units. Copy the original units into your notes rather than comparing the numbers by sight. If you can’t confirm how a tool calculates jitter or packet loss, compare results within that tool instead.
Keep test conditions fixed for a route comparison
Check your local network first, then test the routes you’re considering. Testing without the service connected can help identify access network issues, but it shouldn’t be treated as the route’s “maximum performance.” Direct and proxied traffic may take different paths, and content may come from different CDN servers.
- Pause background traffic. Stop cloud sync, system updates, and other downloads, and make sure nobody else on the shared network is using a lot of bandwidth. Don’t leave system security features disabled just to run a test.
- Keep the connection method consistent. Use a wired connection if possible. If you’re on Wi-Fi, keep your location and access point the same. Don’t compare wired results with Wi-Fi results taken when the signal was unstable.
- Record the client setup. Note the operating system, client version, selected route, routing mode, and whether network-level features such as TUN are enabled. Keep the configuration unchanged and switch only the route.
- Keep the test destination fixed. Use the same speed test server and confirm that test traffic is actually going through the selected route. After switching routes, wait for the connection to stabilize before testing.
- Repeat tests and keep the raw results. Vary the order in which you test candidate routes to reduce timing bias. Keep low results and failures instead of recording only the best-looking outcome.
- Check real-world use. Open a website you use regularly, play the content you care about, or transfer a file. Note initial load time, sustained transfer, and interruptions.
Speed tests use real data and may saturate your connection while running. If your service has a data limit, check your remaining allowance first. Don’t run automated tests in a long loop or start a full-speed test during an important call.
Before sharing test notes, remove subscription URLs, access tokens, and account details. A speed test screenshot only needs to show the test conditions and results—not your entire client configuration. Subscription links may grant direct access to configuration details, so don’t post them in public documents or discussion forums.
Timing and destinations: include peak-hour tests
Test at the times when you actually use the service. A smooth result during the day doesn’t mean evenings will be the same, and one poor evening on a weekday doesn’t prove a route is consistently unusable. Add the date, local time, and time zone to each entry so you can make meaningful comparisons across time periods.
Try to test candidate routes at similar times, then repeat on different days. If your access network changes during testing, start a separate record instead of grouping the results together. You can summarize with the median and range, but keep the original samples too—averages can hide repeated interruptions.
The test server can also change the outcome. It may be busy, the connection between it and your exit may be congested, and automatic server selection may change with the exit region. A fixed target is useful for controlled comparisons; automatic selection is closer to the tool’s default experience. Both approaches are valid, but record them separately.
Websites may assign content servers based on your exit IP and DNS results. So the “same URL” doesn’t always mean the “same server.” For deeper troubleshooting, note the destination server or connection details reported by the app. If that information isn’t available, limit your conclusion to that visit rather than making claims about the entire international route.
High speed test scores, but still laggy? Check routing, DNS, and the network path
First, check whether test traffic and app traffic use the same route. In rule-based mode, a speed test site may connect directly while your target app uses the proxy—or the other way around. System proxy settings usually affect only apps that follow them, so they don’t prove that all programs are routed through the service. TUN coverage also depends on the client, routing setup, and exclusion rules.
DNS affects domain lookups and which content server you reach. If DNS requests take an unexpected path, they may be exposed to an unintended resolver or return a server that’s a poor fit for your current exit. Check the client’s DNS settings, rule logs, and any encrypted DNS configured in your browser. Changing DNS isn’t guaranteed to make a connection faster.
Public DNS test pages can offer clues, but the resolver’s apparent location alone doesn’t prove a leak. DNS providers may use distributed servers, and IP geolocation data can be inaccurate. Compare the results with your expected setup to see which resolver handled the request and whether that matches your privacy needs. After making changes, check that neither IPv4 nor IPv6 traffic is taking an unintended path.
Protocol names aren’t a substitute for testing. The performance of Shadowsocks, VMess, Trojan, and VLESS also depends on the transport, encryption settings, client implementation, and network path. Hysteria2 and TUIC are based on QUIC, so performance may differ when UDP is restricted or network policies change. When comparing protocols, keep the exit and destination fixed if possible; otherwise, you’re comparing entire configurations.
IEPL, relay, and direct routes describe how traffic is routed, not how fast it is. Even beyond a dedicated segment, performance depends on the local connection and the path from the exit to the destination; a relay isn’t automatically slow. For specific VPNGot route details, refer to the servers page and the dashboard. Don’t infer unpublished bandwidth guarantees from route labels.
Test log template and route selection takeaways
You don’t need a complex setup to compare routes. Plain text or a local spreadsheet is enough; the key is recording whether conditions were consistent. The template below has no prefilled results, so example figures can’t be mistaken for service performance.
Test date, local time, and time zone:
Device OS, client, and version:
Access network and connection type:
Full route name:
Routing mode, DNS, and TUN status:
Speed test tool and server:
Idle latency, loaded latency, and jitter:
Packet loss result and probe method:
Download, upload, and original units:
Real-world app performance:
Errors, failures, and changes in test conditions:- ✅ Compare results in the same group only when the tool, destination, and access conditions match.
- ✅ Include performance during the hours you usually use the service. Focus on consistency and variation, not just the peak.
- ✅ Make sure both the speed test and real apps use the intended route, and note any changes to rules or modes.
- ❌ Don’t label a route unusable based on one timeout, or treat a client’s probe latency as the latency for every app.
- ❌ Don’t share subscription links or use a full configuration containing credentials as proof of speed.
Choosing a route: Under consistent conditions, favor routes that perform reliably during your usual hours and keep delays in real apps low. Download peaks can be useful context, but shouldn’t be the only basis for ranking. If all candidate routes get worse at once, check your local network and the destination service before changing your configuration.
Route performance can vary with your access network, destination, and time of day. Keeping a repeatable test method is more useful than saving a single speed test screenshot. If you need help, submit sanitized test conditions, the time of the issue, and relevant client log excerpts through the dashboard support ticket, so troubleshooting can start with a reproducible issue.