When comparing VPN speeds, the goal isn't to find the highest download figure—it's to make the test repeatable. Keep the device, local network, and test server consistent, then compare routes and time slots. Only then are the results useful. This guide covers tools, record-keeping, and troubleshooting without assuming any route will achieve a particular speed.
Speed Test Metrics: Download Speed Isn't Everything
A speed test measures an end-to-end path: your device, local connection, proxy entry point, exit point, and test server. A bottleneck anywhere along the way can lower the result. The number shown by a speed test site doesn't automatically reflect the standalone capacity of a provider's network.
| Metric | What it measures | Useful for assessing | Common misinterpretations |
|---|---|---|---|
| Download throughput | Amount of data received per unit of time | Large downloads and video buffering | Tests using multiple connections may be faster than a real single-connection download |
| Upload throughput | Amount of data sent per unit of time | Video call uploads and file syncing | Your local broadband upload speed may also be a bottleneck |
| Round-trip latency | Time for a request to reach its destination and return | Interactive response and remote access | Client-side probes and app traffic may not follow the same route |
| Jitter | Variation in consecutive latency measurements | Audio and video call consistency | Different tools may calculate it differently |
| Packet loss | When test packets fail to reach their destination as expected | Stuttering, retransmissions, and unstable connections | Probe packets may be rate-limited; this doesn't necessarily mean regular traffic is being lost too |
| Loaded latency | Round-trip latency while uploading or downloading | Whether calls are affected during downloads | Don't look only at latency when the network is idle |
File downloads depend more on sustained throughput, while calls are more sensitive to latency, jitter, and packet loss. Page load times also depend on DNS resolution, connection setup, server response, and the number of page resources. So a fast download test doesn't mean every website will feel fast.
Choosing Tools: Combine General Speed Tests with Real-World Checks
Speed Test Sites: Keep the Test Server Consistent
Tools such as Speedtest and Cloudflare Speed Test can provide a general benchmark, but they differ in test procedures, concurrent connections, and server locations. To compare routes, use the same tool and, where possible, the same test server. Note the server operator and location. Automatic server selection may change with your exit point, meaning the test target changes too.
If a tool doesn't let you select a test server, record the server it chooses automatically and treat the result as “how this route performs to that server.” Results from different sites are useful for cross-checking, but shouldn't be combined into a single route ranking. Browser extensions, background sync, and security software scanning traffic can also affect results.
Client Latency: Check What It Measures
The latency figure in a client may come from a TCP handshake, an HTTP request, or another kind of probe. It may measure the entry point or access a specific URL through the proxy. Don't infer what it means from the word “latency” alone. Check the client documentation and keep the probe address consistent.
System ping usually uses ICMP. When a browser accesses a site through the system proxy, command-line ping may not follow the same route. Even in virtual network adapter mode, the route depends on how the client handles that traffic. Don't treat ping results as proxy exit latency, and don't assume a route is unusable just because a target doesn't respond to probes.
Real-World Checks: See How Your Tasks Perform
After a download test, also visit the sites you use day to day, try a video call, or download a file from a trusted source. Keep each task as consistent as possible: use the same resource, video quality settings, and call setup. Adaptive bitrate and browser caching can change the experience, so note these factors in your records.
Before You Test: Control Variables and Record a Direct-Connection Baseline
A direct-connection baseline is how your local network performs around the same time with the proxy turned off. It helps identify fluctuations in your internet connection; it doesn't mean every test target must be reachable directly. If a target can't be accessed directly, note “direct comparison unavailable” instead of guessing.
- ✅ Use the same device and connection method. If possible, use a wired connection; on Wi-Fi, keep your location and frequency band consistent.
- ✅ Pause system updates, cloud sync, large downloads, and other network-intensive tasks. Keep an eye on traffic from other users sharing the connection.
- ✅ Keep the client version, node, routing mode, and test server consistent. Avoid changing several variables at once.
- ✅ Check the client's connection records or routing logs to confirm that test traffic uses the selected node rather than matching a direct-connection rule.
- ✅ Note your remaining plan data. Throughput tests use data, and frequent repeats can reduce what's available for everyday use.
The traffic covered by global and rule-based modes depends on the client. Enabling the system proxy alone doesn't mean every app will use it; browsers, command-line tools, and in-app network components may use different settings. Confirm the traffic route before testing to avoid comparing a speed test over a direct connection with an app using the proxy.
Don't leave your firewall or security software disabled just to rule out variables. First pause unrelated tasks, check routing records, and retest with a trusted tool. Any necessary security changes should follow your device management requirements.
Comparing Time Slots: Testing During Peak Hours and Overnight
The difference between peak hours and overnight is network load—not that overnight results are inherently more accurate. Test during the hours you actually use the service, then compare with a quieter time. Testing only when the network is quiet won't tell you whether performance is good enough during busy work or leisure hours.
- Set a baseline. Turn off the proxy, test a fixed target that is directly reachable, and record your local network, time slot, and background activity.
- Connect to a route. Confirm the node and routing path. Once the connection is stable, test against the same server.
- Repeat the test. Run multiple tests in the same time slot and keep all valid results, not just the highest. Look at typical performance and the range of variation.
- Check real-world tasks. After the throughput test, try a call, browse a website, or download a file. This avoids letting the speed test itself saturate the network and skew your assessment.
- Repeat at another time. Use the same settings during peak and quieter hours. When switching routes, check again that the test server hasn't changed.
- Compare the results. Compare how the same route performs across time slots, then compare different routes tested during the same time slot.
Don't discard an unusual result right away. First check for a Wi-Fi reconnect, node switch, resumed background task, or change in test server. Note the cause before deciding whether to exclude it. If you can't explain it, keep it and flag it as an outlier rather than cherry-picking a smoother result.
Record Your Tests So Results Can Be Verified
Screenshots preserve raw readings, but they're hard to verify without context. For each test, record at least the date and time, connection type, device, client and mode, node name, tool, and test target, then save the download, upload, and latency results. If a tool doesn't provide a metric, mark it “not measured”; don't assume a blank means there was no issue.
When recording a route, include both its entry point or route identifier and its exit region. IEPL, relay, and direct connection describe how a route is organized; they aren't performance grades. Routes with similar names can perform differently because of variations in entry and exit points, shared load, and connectivity to the destination network.
IEPL generally refers to an Ethernet private line service provided by a carrier. In proxy services, an “IEPL route” usually means that this type of resource is used for part of the transmission path; it doesn't mean the entire connection from your device to any website uses a private line. A relay means traffic is forwarded to a subsequent route. A direct connection usually means the client connects straight to the proxy server, not that internet routers are bypassed.
Protocol names are no substitute for testing. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC differ in transport design, client support, and configuration requirements, but their names alone don't predict throughput rankings. When comparing clients, also note their versions and transport settings; don't attribute every difference to the route.
Troubleshooting: From Your Local Network to the Destination Website
Both Direct and Proxy Connections Are Slow
Start by checking your local connection, wireless interference, router load, and background uploads. If the direct-connection baseline also drops noticeably at the same time, the issue is more likely to be local or with your upstream connection. You can retest on a different connection, but record it separately as a new test condition.
Speed Test Looks Fine, but Websites Still Load Slowly
Check whether the speed test and web traffic use the same route, then use your browser's developer tools Network panel to inspect timings. Slow DNS resolution, slow connection setup, slow server response, and slow page resource loading are different issues. Browser cache, extensions, and load on the destination website should also be considered.
A DNS leak means domain lookups aren't handled through the expected route, which can affect privacy and routing consistency—but it doesn't mean speed tests will necessarily be slow. Check system DNS, encrypted DNS in the browser, client DNS, and routing rules together. A different resolver location alone doesn't prove a leak, and settings shouldn't be changed blindly just to make the displayed location match.
Downloads Are Fast, but Calls Still Stutter
Check upload throughput, jitter, packet loss, and loaded latency instead of chasing a higher download peak. A cloud drive using all available upload capacity can hurt call quality; a large speed test running at the same time can cause similar symptoms. Video call apps often include a call-quality panel, whose stats are more relevant than probes to unrelated targets.
Slower During Peak Hours, Better When It's Quiet
If your local baseline is stable, the target stays fixed, and you can reproduce the same change, congestion is one possible explanation. But congestion can occur at the entry point, across network connections, at the exit point, or on the destination side; throughput changes alone can't pinpoint the cause. When contacting support, share the time, node, connection type, and target instead of sending only a screenshot showing low speed.
Choosing a Route: Keep Options That Work for Your Needs
Speed tests should help you choose a route, not produce a leaderboard based on peak speeds alone. For everyday downloads, focus on sustained throughput; for remote meetings, check stability during busy hours; for websites and collaboration tools, consider the actual traffic route. Keep a primary and backup route, and retest when your connection or client settings change.
VPNDream monthly plan data resets each month on the activation date. Data add-ons remain available until used and never expire. Check your remaining data before testing and repeat tests as needed; there's no need to keep the connection running at full capacity. See the guides for client downloads and setup instructions, and the server locations page for route information. The nodes actually available to you are shown in the client.