Routes & Protocols: Cross-border Connection Guide

Path / Fundamentals

Understand protocols, routes and exit locations

What happens when you connect

Opening a webpage looks like a single click, but several steps happen behind the scenes. The app makes a request, which passes to your device's network stack and then through the connection established by the client. It follows the selected route to an exit server, which accesses the destination service. The response travels back along the corresponding path. A protocol describes how the client and server establish, maintain and transmit data over a connection. A route describes the network path traffic takes to the exit server. The exit location is the apparent source of the request to the destination service. Treating all of this as one question—“Is this server fast?”—usually makes it harder to find the actual bottleneck.

For example, a webpage that takes a long time to open could point to slow DNS resolution, connection setup or a slow response from the destination. If the page opens but images load slowly, congestion during sustained transfer may be the issue. If a video starts but keeps buffering, check throughput and packet loss during playback. Using different protocols with the same exit server changes connection setup and transmission overhead. Using different routes with the same protocol can also produce different results because of path, distance and congestion. Before troubleshooting, work out whether the delay happens when you first connect or during ongoing use. That's more useful than repeatedly toggling settings.

A route label doesn't tell you how fast it will be

A region name tells you where an exit server is located; a route type describes how traffic is routed. Neither guarantees speed for every app. A Hong Kong exit doesn't mean every destination service will serve content from Hong Kong. The service may use your account settings, content licensing or its own location rules to decide what you see. A route labeled direct isn't always shorter than a relay route: geographic distance and the quality of network interconnections are different things. First choose an exit region that suits the destination service, then observe how it works in practice. Don't choose based on which label looks most familiar.

A subscription usually contains server details and protocol settings that a client can read. After importing it, the list of routes shows available connection configurations; they are not all active connections using bandwidth at once. When the client says “Connected,” it means the connection from your device to the selected exit server has been established. It doesn't guarantee that the destination website will respond. To verify access, check the client status, your actual exit location and whether the app can complete the task. If an app still uses its regular network path, check whether the app is covered by your per-app routing rules.

Connection quality isn't determined by maximum bandwidth alone. Short messages, searches and AI chats often depend more on how quickly the first response arrives. Large files and high-resolution video rely more on sustained transfer. Video calls need both low jitter and a stable two-way connection. Choose metrics that match the task. A successful download doesn't prove that the same route is suitable for real-time voice. Likewise, a route that works well for calls isn't necessarily the best choice for large file transfers.

For a useful comparison, keep the conditions consistent: use the same device, network, destination app and roughly the same time of day, changing only the protocol or route. If you change the device, app and exit location at once, you won't know what caused the difference. Note repeatable observations such as how long a page takes to open, whether playback stalls or whether voices break up in a call. That's more useful for everyday route selection than ranking single speed-test results from different tools.

Protocols / Design trade-offs

Choosing among common protocols

Shadowsocks, VMess and Trojan

Shadowsocks has a relatively straightforward design: the client and server encrypt and forward data according to an agreed method. There are many client implementations and configuration options, making it a good fit if you want a simple setup and broad client compatibility. But Shadowsocks is the name of a protocol family, and the experience still depends on the implementation, network path and server configuration. Two configurations using the same protocol name won't necessarily perform identically. After switching client implementations, verify the imported settings and route selection again.

VMess includes authentication and methods for organizing data transfer. Configurations are typically read by clients that support the corresponding format. It can involve more settings than simpler protocols, so the transport method, connection options and server support all need to match. More parameters don't mean better performance; they do mean you should check each setting carefully when moving to another client. If the configuration imports but won't connect, first check that the client supports the transport method in the subscription and that the device's system time and settings are correct. Don't assume the route is down based on the protocol name alone.

Trojan typically carries data over a TLS connection. TLS is a mechanism for securing connections, and actual performance depends on the certificate, connection negotiation, server setup and route. Trojan can suit client environments with mature TLS support, but the protocol name doesn't guarantee a faster or more reliable connection. If the initial connection takes noticeably longer, check whether the delay is in local DNS resolution, TLS negotiation or route transmission. If ongoing transfer is fine once connected, the fix may differ from an issue that slows down the entire session.

VLESS, Hysteria2 and TUIC

VLESS keeps the protocol layer lightweight and is often combined with different transport and security methods. When comparing VLESS with other protocols, include the underlying transport in your notes; comparing protocol names alone can mean comparing different setups. A lightweight protocol layer can reduce some processing overhead, but the end-to-end experience still depends on the network path, client implementation and destination response. For most users, a configuration that imports reliably into their current client and is actively maintained is more useful than choosing a protocol just for its name.

Hysteria2 and TUIC are both commonly used with UDP-based transport. Their performance and connection-management behavior differ from traditional TCP routes, so they may be worth trying on networks with jitter or packet loss—provided the local network, client and server can all handle that traffic properly. UDP isn't a universal replacement: if the local network handles UDP poorly, a stable TCP route may work better. If connections fail intermittently, check network conditions and protocol support before judging the route.

When choosing a protocol, first check that your client can import the configuration reliably. Then consider whether your current network supports the transport method. Finally, compare response times and resource use during actual use. A protocol performing well on someone else's network doesn't mean it'll do the same on your device. A protocol is one factor in a connection; it can't fix a destination service outage or clear congestion from a busy physical route.

Performance / Connection process

Connection setup, throughput and resource use

Why does the first response take so long?

Establishing a connection involves a sequence of dependent steps: resolving the server address, contacting the server, completing any required negotiation, sending the app's request through the established channel and waiting for the destination service to respond. Protocols and transport methods may differ in the negotiation steps they require and the transport layer they use, but there's no universally valid speed ranking independent of the network. Round-trip time along the route, retries after failed DNS lookups and the destination's response time can all outweigh small differences at the protocol layer.

If every new page takes a long time to open but scrolling and loading are fine afterward, first check connection setup, DNS resolution and the destination's initial response. If the delay happens only after switching routes in the client and things work normally once connected, the new connection may need to renegotiate. If the same site is slow across different exit locations while other sites work, consider issues with the destination service. Blaming every delay on “route speed” can lead to constant switching without fixing the actual bottleneck.

Sustained transfer and processing overhead

Throughput measures how much data can be handled during continuous transfer; it isn't the same as connection setup speed. For playback, downloads and file sync, results depend on congestion, packet loss, server capacity and the destination site's transfer policies. Protocols use device resources for encryption, encapsulation and connection-state management. Actual resource use also depends on the client implementation, other apps running at the same time and system scheduling. Protocol overhead in theory can't predict the exact battery life or playback quality on a particular device.

When checking resource use, first rule out apps doing heavy background sync. An increase in the client's traffic could simply mean an app is downloading an update, not that the protocol is sending unnecessary data. To compare protocols, keep the task consistent: open the same page repeatedly and observe the first response; play the same content and watch for buffering; transfer similar files and see whether the process stays steady. Don't treat a one-off peak as sustainable everyday bandwidth or use it to predict performance in every region.

Per-app proxy rules can also affect performance comparisons. If your browser uses the selected exit server but a speed-test tool or another app uses your regular network path, their results aren't comparable. System proxies and virtual network interfaces may cover different apps, and apps may have their own network settings. Before comparing, use the same app to confirm that the exit location is consistent. For help importing and verifying a client configuration, see our Guides, then return here to assess the protocol and route.

You don't have to use the same settings for every task. If your workflow involves frequent short page visits, focus on connection setup and time to first byte. For long transfers, look at sustained stability. Voice calls are especially sensitive to interruptions. A route with a slight advantage for one task may still be less efficient if it often needs to reconnect. Judge a configuration by whether it completes your tasks and whether issues can be reproduced, rather than by a single peak result.

Devices / Mobile use

Battery life and background connections on mobile

Battery drain comes from keeping the device active, not just encryption

On mobile devices, battery use comes from encryption, network traffic, screen time and background app activity. Frequent disconnects and reconnections mean extra network wake-ups and negotiation. In areas with weak signals, the device may also use more radio resources to maintain a connection. So “this protocol uses less battery” is only a meaningful comparison when the device, network, app activity and client implementation are similar. If you compare protocols while playing video, differences in battery use will mostly reflect the video playback, not the protocol itself.

Mobile operating systems limit background activity according to their system policies. If a connection pauses when the screen turns off and comes back only after you wake the device, that doesn't necessarily mean the server has a problem. First check that the client has the required network permissions. Then see whether battery-saving settings restrict its background activity. The settings may be named differently across manufacturers; after changing them, test by turning off the screen, switching networks and reopening the app. For more on Android background activity, battery settings and per-app proxy rules, see Android VPNs: Background Connectivity, Battery Life and Split Tunneling Tested.

Network changes and app coverage

When a device switches from Wi-Fi to mobile data, or between Wi-Fi networks, its local address and network path change. Existing connections may need to be re-established. Even if the client still shows as connected, long-running app connections may pause while they recover. If a network switch interrupts a call or file upload, give the app a chance to reconnect, then check the client's status and exit location. If the issue occurs only after switching networks but not on a stable network, focus on connection migration and background system policies rather than blaming a particular exit region.

Per-app proxy rules let you route selected apps through international routes while leaving others on their regular network path. But the more complex the rules, the easier it is to assume an app is using the exit server when it isn't. Before setting up rules, decide which apps to include, then verify the route the app actually uses. After adding an app or changing its package, check that the rule still applies. For a step-by-step walkthrough of client setup, Android VPN Setup: A Beginner's Guide covers installation, import, permissions and verification.

To reduce unnecessary background activity on mobile, first limit background transfers and repeated reconnections, then compare protocols. When checking the system's app battery usage, consider whether the measurement period included large downloads, video playback or navigation. Compare similar everyday activities and see whether the connection stays stable, rather than comparing battery percentages across different days. A stable connection and clear app rules are often a better way to balance reliability and battery life than shortening connection time indiscriminately.

VPNND supports Windows, macOS, iOS, Android and Linux. Find the client download in the user dashboard. Don't assume that battery management and proxy coverage work the same way across operating systems. After importing the same subscription, verify the exit location in the apps you actually use on each device. If only one device can't access a service, start by checking that device's permissions, network and app settings, then compare its route selection with other devices.

Path / Route structure

Direct, relay and dedicated routes

How routes affect your experience

A direct route generally means the client connects to the exit server over an available network path without an additional designated relay. Its structure is straightforward, with fewer routing steps, but the quality of interconnections along the way depends on the actual route. Even if the exit is geographically close, traffic may take a detour or pass through a congested interconnection point. Don't judge whether a direct route is suitable by map distance alone. Check connection setup, sustained transfers and performance at different times on your own network and in the apps you use.

A relay route adds a forwarding step between the entry point and the final exit. This may improve routing across part of the network, but it also adds processing and transfer time. A relay isn't automatically faster or slower. It may make the overall experience more consistent when the original route has poor interconnection quality; if the original route is already clear, the extra hop may add delay. To evaluate a relay route, check that its final exit suits your target region and observe latency fluctuations and reconnections during your task.

A dedicated route describes a particular routing arrangement; it doesn't mean the entire path from your device to the destination service uses the same network. Access quality from your device to the entry point, connectivity from the exit to the destination and the destination's own load all affect results. If the entry segment is stable but the destination platform responds slowly, switching to another dedicated route may not help. If public interconnections are repeatedly congested at certain times, routes with different routing arrangements may be worth comparing. See the server page for VPNND regions and route types.

Choose a region and topology together

Choose a region for the task first, then compare the route topologies available there. If you need content for a particular region, the exit location may affect which catalog or service settings are available. For work tools, check which regions your account and the destination service actually support. An exit that doesn't suit your task won't help, even if its connection setup is faster. See our Streaming page for more on region selection and playback.

Interpret route labels alongside the protocol. Switching routes while keeping the protocol the same helps isolate path-related factors; keeping the route fixed while changing the protocol helps reveal the effect of the connection method. If a client configuration changes both protocol and exit location, the result only shows how the full configuration performs—you can't attribute the improvement to one setting alone. When comparing, note the exit region, route type, protocol and destination app. There's no need to rely on unverifiable overall scores.

Cross-border access is an end-to-end process, and changes at any point can affect the experience. A successful connection to an exit server doesn't mean every destination service will work at the same speed. And an issue with one website doesn't mean every route in that region is bad. First use another familiar destination to check whether the connection is generally affected, then compare other routes in the same region for your original task. Assess whether the region fits your needs separately from whether the route is stable. That makes route selection clearer.

Symptoms / Network fluctuations

Packet loss, jitter and peak-hour congestion

Why a connection can work but still feel slow

Packet loss means some data doesn't arrive as expected. Depending on the transport method, the connection may retransmit data, correct errors or wait for the app to handle them—but to you, it can all feel like stuttering. Jitter means data arrives at uneven intervals. Even when average latency looks low, real-time voice can still break up. Congestion occurs when traffic on part of a network approaches its capacity, increasing queueing delays and sometimes causing packet loss. These problems can occur together or appear only on a particular route segment, at certain times or in certain apps.

Peak hours are a common time to notice congestion, but a slowdown in the evening alone doesn't prove that the service lacks capacity. Your home network, inter-network connections, relay segments, the network beyond the exit and the destination platform can all vary by time of day. First check whether different destinations slow down on the same network, then compare the same destination over other routes. If only one platform is affected, consider its service status and region settings. If several apps are affected, look at the parts of the route they have in common.

Different tasks tolerate fluctuations differently. A webpage may continue loading after a delay, and a download may be able to resume. But a pause in a call can't be recovered later. Streaming apps usually buffer some content in advance, so smooth playback at the start doesn't guarantee a stable session. For video, watch for buffering during playback and changes in picture quality. For calls, note clipped speech, delayed audio or brief video freezes. Specific symptoms are more useful for troubleshooting than a vague report of “high latency.”

Compare time periods to avoid false conclusions

To see whether congestion is involved, repeat the same task at different times you normally use the service, keeping the device, network, destination and app settings as consistent as possible. If the problem only occurs at certain times, compare direct, relay and dedicated routes in the same region. If it happens in just one app at every time, check the app's settings and the destination service first. After switching routes, don't conclude that the issue is fixed just because one page opened. Repeat the task that originally failed, such as continuous playback or submitting a work request.

The relationship between protocols and packet loss isn't as simple as saying one protocol is “loss resistant.” A transport implementation affects retransmission and congestion control, but it still has to use the actual network. If the local network is already unstable, switching exit regions may not help. If one UDP configuration is the only one that performs poorly, check how the current network handles UDP. Rather than giving a protocol a permanent label, find a combination that reliably completes your task under repeatable conditions.

To see available regions and route types, filter the server page, then compare them in the same app. If route status includes live latency or bandwidth figures, use them as clues when choosing a route—not as a guarantee for your network or destination platform. Results can vary across devices, networks and times. If an issue persists, note the symptoms, time and selected route. That's more useful for troubleshooting than a one-off speed-test screenshot.

Choosing / Use cases

Choose protocols and routes for your task

Work tools and short requests

AI chats, document searches and everyday browsing often involve many short requests. First check which exit region the destination service requires, then see whether pages open, logins work and requests receive consistent responses. If the first page loads slowly but later interactions work normally, focus on connection setup. If you repeatedly wait during interactions, also check route jitter and the destination service. Access to a tool doesn't mean the same exit will suit every account or feature. Verify the actions you actually need to perform.

For example, when using developer tools such as Cursor, the problem may affect only login, extension updates or interactions with remote services. First check whether the entire app is offline or only one feature is taking too long, then verify the per-app rules and exit location. If ChatGPT works differently during login and ongoing use, record those separately instead of assuming a successful login means it'll stay stable. For more on account access and route selection, see ChatGPT Network Requirements and Route Selection Tips.

Streaming, calls and mobile devices

For video, first check whether the content is available in the selected region, then see whether playback buffers. High-resolution video depends more on sustained transfer, but actual bandwidth needs vary with encoding, the streaming platform and device settings, so one fixed number won't apply to every setup. If you have trouble accessing a catalog in one region, check the region and content licensing first. If the catalog is available but playback is unstable, compare sustained performance across routes in that region. For more on regional catalogs and video quality, see Netflix Regional Catalogs and Playback Compared.

For calls and voice chat, focus on jitter, interruptions and reconnections. Choose a region where the service works, then compare how consistently different routes in that region perform. Don't give up a connection that reliably handles your calls just to get a slightly lower latency reading once. If you work on the go, also check how quickly the connection recovers when switching networks. If the calling app isn't using the selected exit, check its per-app rule first. If every app loses its connection, check the client and system network status.

Once you've chosen a region, use a configuration supported by your client that imports reliably as your baseline. If it completes the task, there's no need to keep switching just because another protocol sounds newer. If a specific issue occurs, change one condition at a time. For example, keep the exit fixed and change the protocol to compare connection setup and app interactions; keep the protocol fixed and compare routes in the same region to check for time-specific fluctuations. Results apply to the task and network conditions you tested, not to every service in general.

Choosing a plan and choosing a protocol are separate decisions. VPNND monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Data resets monthly on the activation date. Data packs are ¥158/300GB, ¥358/1000GB and ¥658/3000GB; they don't expire and remain available until used. Estimate your usage, then check the plans page for the available options. A price tier isn't a performance rating for any protocol or route.

Troubleshooting / Reproducible notes

Work from symptoms toward verifiable causes

First check that the target app uses the connection

Start troubleshooting with facts that are easy to verify: does the client show the current configuration as connected, is the target app actually using the selected exit, and can you reproduce the issue in that app? If the client isn't connected, check whether the subscription was imported correctly, whether the client supports the configuration and whether the device's network is working. If the client is connected but the app still uses its regular network path, check the system proxy mode and per-app rules. Don't judge the route by how a website loads until you've confirmed the app's path.

Next, narrow down the scope. A problem affecting every website is different from a login failure on one site. An issue on one device points somewhere different from issues across every device on the same network. First try a familiar destination that normally works, then repeat the task that had the problem. Don't change your browser, device, network and region all at once. Even if the problem goes away, you won't know which change fixed it.

Troubleshoot in stages with minimal changes

If the connection won't establish, first check the device's network, client permissions and configuration compatibility. If it connects but frequently drops, look at network changes, background battery settings and access quality. If the connection stays up but one app is slow, verify the target region and app route, then compare other routes in the same region. If delays happen only at peak hours, note the time and compare different topologies. Working through each layer helps distinguish destination service issues from protocol issues and avoids changing the entire setup to fix a localized problem.

You don't need complex tools to document an issue. Note the device platform, network type, protocol and region selected in the client, affected app, action that triggered the problem, whether it happens only at certain times and what changed afterward. Protect your subscription link and don't post the full link publicly. For advice on protecting subscription links and using public Wi-Fi, see VPN Safety Basics for Beginners. You can include the route name when describing an issue, but remove personal credentials.

If switching to another route in the same region doesn't fix the issue and it still occurs only in one app, check the app's account status, region requirements and service status first. If every app has problems on the same network, repeat the original task on another available network to see whether the issue is related to local access. If switching protocols changes the symptoms, note the transport methods and the features supported by each client version. Don't conclude that a protocol always suits that network based on a single successful connection.

VPNND supports unlimited simultaneous devices. You can create an account with a username and password; no email address is required. Payment methods include Alipay, WeChat Pay and USDT. VPNND offers a 30-day money-back guarantee. These are service terms, not a substitute for testing routes in your own setup. For step-by-step client setup, see our Quick Start Guide. To compare regions and topologies, visit the server page. For data options and pricing, see the plans page. Using each page for its intended purpose is more reliable than basing every decision on a single speed test.