A VPN speed comparison is not as simple as opening a speed-test site, recording the peak bandwidth, and judging the entire route from that number. Each result is affected by the local access network, test server, exit region, protocol implementation, client load, and time of day. A useful test keeps controllable variables consistent and examines interactive response, transfer stability, and real performance with the target service.
“Fast” is not a single metric. Snappy page loads depend largely on round-trip latency, DNS resolution, and connection setup; voice calls, meetings, and real-time actions are more sensitive to jitter and packet loss; downloads, cloud sync, and high-bitrate video depend on sustained throughput. A route may show a high short-term peak yet slow down repeatedly during a long connection. Conversely, a route with an ordinary peak and little variation may deliver a more stable viewing and transfer experience.
Separate latency, jitter, packet loss, and bandwidth
Latency is the time data takes to travel from a device to its destination and back. It is affected by physical distance, carrier routing, and route topology, and usually cannot be offset by higher bandwidth. When testing a Japan exit, a test server in another region measures the path beyond the exit—not the performance between the device and the Japan node itself. The test server should therefore be as close as possible to the actual target.
Jitter describes how much the latency of consecutive packets varies. Routes with similar average latency can provide completely different real-time experiences because of jitter. Remote desktops that alternate between fast and slow, occasional breaks in voice calls, and inconsistent game controls may all be related to jitter. Recording only average latency hides these issues; observe the continuous sampling curve rather than just the final summary.
Packet loss means packets do not arrive as expected. Small, occasional losses may result from wireless interference, local congestion, or changes in intermediate routing, so a single test cannot directly attribute them to a VPN node. A more reliable approach is to repeat tests before and after connecting, using the same network and destination. If the underlying connection already loses packets, changing the protocol or exit may not address the root cause.
Bandwidth tests usually cover both download and upload, but the short-term throughput shown by a speed-test tool is not the speed an application can sustain over time. The transfer window, concurrent connections, server load, and local device performance all affect the result. Keep the complete curve and look for clear drops during startup, the stable phase, or just before completion.
| Metric | Question it answers | Best scenarios to observe | Common misreading |
|---|---|---|---|
| Latency | How long does an interactive response take? | Web browsing, remote control, real-time apps | Blaming the route for distance added by a cross-region test server |
| Jitter | How stable is the response time? | Meetings, voice calls, continuous interaction | Looking only at the average and ignoring variation over time |
| Packet loss | Are packets missing and being retransmitted? | Real-time communication, long-lived connections, sustained transfers | Ignoring local wireless and underlying route problems |
| Sustained throughput | Can the connection maintain speed over a long transfer? | Downloads, sync, streaming | Using a short-term peak as a substitute for complete transfer performance |
Build a reproducible VPN speed-testing process
Record the underlying connection for comparison
Disconnect the proxy or VPN first, then record the current access method, network environment, and test target. Stop background tasks that sync files, update software, or play video, and avoid switching wireless access points during the test. The baseline test is not meant to produce an ideal result; it establishes the ceiling and stability the local network can provide at that moment.
Before testing, also make sure the device is not in power-saving mode. Some mobile devices restrict background network activity, while desktop devices may be affected by high load, heat, or network-adapter settings. If the same node performs very differently across devices, check the client version, system networking stack, and hardware load before attributing the difference to route instability.
Fix the exit, protocol, and test server
After connecting, lock the test to one route instead of allowing the client to switch nodes automatically. Keep the test server fixed and match it to the use case: choose a target in the same region when evaluating access to services in Japan; use the actual deployment region when evaluating an international work system. Change only one variable at a time—for example, keep the exit unchanged and switch only between Shadowsocks and Trojan—to determine whether a difference comes from the protocol or the route.
After importing a subscription link into the client, the node name usually offers clues about region and route type, but it cannot replace an actual test. Subscription updates may also change node parameters, so confirm that the client has refreshed the subscription and record the node, protocol, and routing mode used for comparison. If the client supports connection logs, retain handshake failures, reconnects, and timeout details, but remove the subscription URL, authentication data, and node credentials before sharing logs.
Cover both quiet and busy periods
A result from one time window describes only that moment. Cross-border routes change with the local access network, international exits, and target-service load, so repeat the same process during the times you normally use the service. If the route is stable during quiet periods but fluctuates continuously when busy, shared-link congestion or route scheduling is more likely. If it performs poorly at all times, continue checking the protocol, device, and local network.
Keep the execution order similar in every round: baseline connection, VPN connection, latency and packet loss, short-term throughput, sustained transfer, and target-application verification. A fixed order reduces interference from temporary test-server changes and makes logs easier to compare. Do not keep only the best run or only the worst; record typical conditions and the context surrounding any anomaly.
- Keep the access network, device, exit region, and test server consistent.
- Pause background downloads, system updates, cloud sync, and other sustained activity.
- Record the protocol, client, routing mode, and test window.
- Keep results for both the baseline and VPN connections.
- Observe the full curve, retransmissions, interruptions, and recovery.
- Finish by verifying the real target service rather than stopping at a speed-test page.
How to compare direct, relay, and IEPL dedicated routes
A direct route means the user's network establishes a connection with an overseas entry point, while still traversing public carrier routing. Its structure is simpler and can have lower overhead when the path is suitable, but it is more sensitive to the local carrier's international routing quality. The same exit may follow entirely different paths depending on the user's region or access network, so a conclusion from one city or carrier should not be generalized to everyone.
A relay route first connects to an entry point in the user's region or nearby, then uses the relay network to reach the exit. Its value is in reorganizing the cross-border path and avoiding some unstable public-network routes. The trade-off is an extra link and scheduling step, so the theoretical path is not necessarily shorter. Judge whether a relay is suitable by jitter, packet loss, and sustained throughput during busy periods—not by a single latency comparison.
An IEPL dedicated line generally refers to a network path connecting regions through carrier-provided dedicated resources, with a different transport model from ordinary public-network direct access and conventional relays. Its focus is often controllable routing and congestion isolation, not a guarantee of the lowest latency from every location to every target. The user's local access still comes before the dedicated-line entry, and the network hosting the target service still comes after the exit, so wireless interference, entry congestion, and target-server limits remain visible in the results.
| Route type | Path characteristics | What to test | How to evaluate it |
|---|---|---|---|
| Direct | Relies on public international routing | Route detours, time-of-day variation, local carrier differences | Repeat tests at different times on the actual access network |
| Relay | Reaches the exit through an entry point and relay path | Entry quality, cross-border stability, sustained throughput | Compare it with a direct route in the same region using the same target |
| IEPL dedicated line | Uses dedicated transport across the regional backbone | Real bottlenecks before the entry and after the exit | Combine long-connection tests with real-service verification |
How protocol differences affect speed-test results
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC differ in encapsulation, transport, and congestion handling. However, there is no permanent speed ranking independent of the client implementation, server configuration, and network conditions. Compare protocols using the same exit, target, and similar time windows, and make sure encryption, transport layer, and routing rules are not changing at the same time.
Shadowsocks has a relatively direct design and broad client support, making it useful for observing baseline proxy-route performance. VMess and VLESS are common in clients that support more complex transport configurations; VLESS emphasizes a streamlined combination of authentication and transport, while its actual overhead still depends on the outer transport and security settings. Trojan commonly carries traffic in a TLS-like form, so connection setup and certificate configuration can affect the first visit, while sustained transfer still depends on the complete path.
Hysteria2 and TUIC use QUIC-based transport designs for networks with high latency or packet loss. On some unstable paths, they may sustain throughput more aggressively, but they also depend more on UDP reachability, client parameters, and network-device processing. If the access network restricts UDP, testing may show handshake failures, frequent fallback, or abnormal speeds. First confirm that the transport is established correctly instead of interpreting the failure as insufficient node bandwidth.
Protocol testing must also distinguish between “a speed-test tool can saturate the connection” and “the protocol works well with everyday applications.” A protocol that excels in multi-connection tests may not lead for single-connection browser downloads, meeting apps, or segmented streaming requests. A sound conclusion should include peak speed, consistency, errors, and the target application's experience.
Client behavior, subscription imports, and platform differences
Windows and macOS clients commonly offer system proxy, virtual network adapter, and rule-based routing modes, but their implementations are not identical. System proxy mode mainly affects apps that follow proxy settings, while virtual adapter mode can take over more system traffic. If two devices use different modes, their test paths may differ even with the same imported subscription and node.
Mobile platforms are affected by system background policies and VPN-interface limits; app switching, screen locking, and power-saving policies may pause or rebuild a connection. Keep the app in the foreground during mobile testing and test while the network type is stable. Do not mistake reconnects caused by mobile-network changes or wireless roaming for protocol instability.
When importing a subscription link, use a client supported by the service provider and verify the subscription source. After copying the link, add and update it in the client's subscription manager, then select a clearly identified node for testing. Do not paste the subscription URL into public speed-test sites, screenshots, or support posts, as it may contain access credentials. If the node list does not change after an update, check the cache, update time, and the client's subscription-format support.
Clients may use different defaults for DNS, routing rules, and UDP forwarding. When moving to another client, compare each setting rather than relying only on the node name. This is especially important when comparing UDP-dependent protocols such as Hysteria2 and TUIC: whether the client enables the relevant forwarding and whether the system firewall permits communication can both affect the result.
Why DNS leaks and routing rules can distort testing
DNS queries resolve domain names to addresses. After connecting to a VPN, if queries are still handled by the resolver on the original network, a DNS leak may occur; this affects both privacy and path consistency, and can also distort speed tests. Content delivery services may return servers in different regions based on the resolver's origin, so the same domain can connect to different targets under different configurations. What looks like a route difference may actually be a comparison of different servers.
When checking DNS, confirm that queries follow the expected resolution path and compare results before and after connecting. Visiting a single test page is not enough to explain everything, because browser secure DNS, system caches, and client-built-in DNS may all be involved. During troubleshooting, clear the resolution cache, temporarily disable browser-specific DNS settings, and confirm that the client's rules take control of DNS.
Routing rules determine which traffic uses the proxy and which remains direct. If a speed-test site is classified as direct, the result may resemble the baseline network and create the illusion of an unusually fast route. If the page itself uses the proxy while its test resources use a direct path, the result becomes even harder to interpret. Before testing, check client connection logs or rule-hit information and confirm that the test domain, test server, and related resources use the same path.
Global mode is useful for eliminating rule interference, but it does not mean global mode should be used indefinitely. After the baseline test, switch back to the routing configuration used in daily work and verify the target application again. If global mode works but rule-based mode does not, focus on domain classification, address rules, DNS resolution, and application bypass settings instead of repeatedly changing nodes.
How to read results and locate bottlenecks
If latency rises overall after connecting but remains stable, first consider exit distance and path length. If average latency changes little but frequent spikes appear, check wireless interference, congestion, and the relay entry. If short-term download speed is high but sustained transfer gradually falls, possible causes include server throttling, target-side limits, device heat and frequency reduction, or route congestion.
Normal upload with abnormal download—or the reverse—should not simply be labeled a “slow node.” Upload and download may use different queues, and the access network may apply asymmetric policies. Try another test server in the same region, compare the baseline connection, and check whether the issue appears only in a particular app. If only one website is slow, the cause is more likely its peering, content-delivery node, or account policy.
The first visit after switching routes is also affected by DNS caches, TLS sessions, and application connection pools. To prevent old connections from contaminating the result, have the target application establish a new connection and confirm that the exit address has changed. Refreshing a browser page may not close existing connections, so application-level verification should focus on a new session rather than repeatedly refreshing the same page.
A credible speed-test record should answer which device and client were used, which region was connected, which protocol and routing mode were selected, where the target server was located, how the baseline connection performed, and whether the anomaly can be reproduced under the same conditions.
From speed-test numbers back to real-world use
Speed-test tools are useful for establishing a baseline, but they cannot replace service-level verification. For video, observe startup, quality changes, buffering, and long playback. For remote work, check sign-in, file sync, meetings, and remote-desktop continuity. For downloads, record the complete transfer rather than only the opening phase. Different use cases call for different conclusions; there is no need to maximize every metric at once.
When choosing a route, filter by exit region first, then compare topology and protocol. If the target service is in Japan, prioritize Japan exits and nearby exits with good connectivity to that service. When accessing multiple regions, create separate results for each target instead of using one route to summarize every experience. Routing rules can also assign more suitable exits to different services and reduce unnecessary detours.
The final report should preserve the test conditions, typical results, observed anomalies, and real-application conclusions. For intermittent issues, record the time and test again; for persistent issues, change the test server, protocol, route, and access network in sequence. Adjust one variable at a time to narrow the scope of the problem.