Connection Layers: Protocols vs. Routes
What happens when you connect
When you open an international website, your app makes a request based on the destination domain. Your operating system or client then decides whether to send it over your local network or through the selected route. Traffic handled by this service is sent from the client to a server using a protocol from your subscription, then forwarded from an egress point to the destination website. The response follows the connection back to your app. This involves the app request, DNS resolution, proxy transport and network path. A problem at any stage can make a page appear unavailable, but each calls for a different fix.
A protocol defines how the client and server exchange information, authenticate, encapsulate data and pass along the destination address. A route defines the entry point, backbone path and egress arrangement. The same protocol can run over different routes, and different entry points can lead to the same egress region. Seeing Trojan does not mean a route is dedicated, and seeing Hong Kong does not guarantee low latency. Protocol, region and route type are separate dimensions in a client list; assess them separately rather than treating them as a single quality score.
Measure DNS, connection setup and app response separately
DNS resolution maps a website name to an address and can also affect which content delivery node the site selects. Next come connection setup, any required security handshake and the app request. A page that takes a long time to show content may be waiting on DNS, retrying a handshake, or waiting for the website to process the request. Slow image loading on an already-open page may point to ongoing transfer or the location of the site's resources. Separate slow startup from slow transfer to work out whether to change the protocol or route, or investigate the destination service.
TCP provides an ordered, reliable byte stream. UDP delivers datagrams but does not guarantee in-order delivery. Using UDP does not mean an app must accept data loss, or that it will be faster: higher-level protocols can implement acknowledgements, retransmission and congestion control themselves. QUIC, for example, provides secure connections and reliable streams over UDP. TCP's reliable delivery does not mean there can be no delays either; it may have to wait for missing data to be retransmitted. When comparing protocols, consider which layer provides reliability and whether its mechanisms suit the network you're using.
| Layer | What it does | Check first |
|---|---|---|
| DNS resolution | Destination address and resolution path | Client DNS mode, cache and resolution errors |
| Proxy protocol | Authentication, encapsulation and transport | Subscription fields and client compatibility |
| Network route | Entry point, path and egress | Access network, route type and time of day |
| Destination app | Account, content and app response | Service status, account region and app messages |
Record connectivity and usability separately
A successful connection status in the client usually means one connection step completed; it does not verify every website or service. The destination app may still require you to sign in again, verify your account region or follow its own access rules for a particular egress location. First check that a regular webpage loads, then test the specific action in the app. A green icon alone is not enough. Conversely, an account restriction message from a website does not necessarily mean the protocol is broken. Keep the original message and investigate at the app layer.
Classic Protocols: Authentication, Encryption and Compatibility
What to consider with Shadowsocks and VMess
Shadowsocks lets a client and server exchange proxied data using an agreed encryption method, typically with a relatively straightforward forwarding setup. Its actual security depends on the cipher suite, credential management and implementation—not just the name. Suites can differ in key handling and data formats, and clients may not support all of them. If an imported configuration reports an unsupported cipher, update to a compatible client or use another available option from your subscription. Don't guess at a similar-sounding replacement.
VMess defines its own structure for authentication and data transport and is often combined with different transport encapsulations. Its performance depends on more than VMess itself: the underlying transport, encryption settings and implementation all matter. Some authentication modes rely on valid time information, so a device clock that's significantly off can cause puzzling authentication failures. Check the system time, refresh the subscription and confirm client support rather than changing server parameters at random. A wide range of configuration options offers deployment flexibility, but also makes it easier to miss a field when setting things up manually.
Security Considerations for Trojan and VLESS
Trojan typically uses TLS to establish a protected transport, then handles proxy authentication and forwarding within it. TLS must verify the server's identity: certificate validity, the server name and system trust settings can all affect the connection. If a node cannot complete a handshake, disabling certificate verification is not a general fix. First check the system clock, confirm the subscription is complete and verify that the route is available. Correct credentials do not make a connection safe if the server's identity cannot be trusted.
VLESS uses a streamlined proxy protocol structure and does not provide complete data encryption simply by virtue of its name. Secure transport depends on the protection configured alongside it. The transport method, server name and related subscription parameters together determine how the connection works. Calling VLESS “lightweight, therefore always fast” overlooks handshake and underlying network costs. It is equally inaccurate to assume every VLESS connection uses the same outer protection. For most users, keeping the full configuration provided by the service matters more than chasing options that merely sound more advanced.
| Protocol | Design focus | What to check in practice |
|---|---|---|
| Shadowsocks | Encapsulation of encrypted proxy data | Cipher support and credential integrity |
| VMess | Authentication and composable transports | Clock settings, transport fields and implementation compatibility |
| Trojan | Authentication and forwarding over TLS | Certificate validation and server name |
| VLESS | Streamlined proxy structure with external transport protection | Secure transport and related settings |
You can't rank connection costs by protocol name alone
Connection setup time depends on the underlying connection, security handshake, proxy authentication and destination website response. The experience differs when an existing connection can be reused versus when each connection must be established from scratch. Whether the client keeps a session alive in the background matters too. Resource use depends on encryption implementation, hardware acceleration, concurrent connections and rule-set size. A setup that feels light on a computer may use more battery on a mobile device. This guide does not offer a fixed ranking independent of device and route, or equate protocol age with performance.
When choosing, first make sure the subscription imports correctly and the client can maintain the connection. Then compare how your apps perform on the same network. If webpages work but long-lived connections are unreliable, check idle timeouts and network changes. If no app can complete a handshake, check whether the entry point is reachable and whether the settings are correct. Protocols are transport tools for particular needs, not names to collect. Check your subscription for VPNCross's current support; coverage in this technical guide is not a promise that every route offers every protocol.
QUIC Protocols: Hysteria2 and TUIC
Why carry reliable transport over UDP?
Hysteria2 and TUIC both use QUIC-related capabilities for proxy transport, but their authentication, forwarding and congestion-handling details differ. QUIC runs over UDP, integrates a secure handshake and supports independent streams within a connection. If packets for one stream need to be recovered, other streams do not have to wait for in-order delivery at the transport layer. However, shared link congestion and congestion control still affect overall throughput. QUIC does not eliminate the effects of packet loss or increase network capacity.
A useful starting point for understanding these protocols is to ask which layer handles reliable delivery. Traditional setups often rely on TCP in the operating system kernel; QUIC handles much of this in user space. That can make protocol updates and connection management more flexible, but it also has different processing costs. Resource use depends on the client implementation, device performance, system scheduling and traffic volume. UDP does not automatically mean lower battery use, and user-space processing does not automatically mean worse performance. The implementation and workload matter.
Understanding Hysteria2 Bandwidth and Congestion
Hysteria2 is designed for proxy transport in less-than-ideal network conditions, and its congestion-handling choices affect how data is sent. Some modes require bandwidth-related information from the user or operator; a higher value is not always better. Overestimating available capacity can push more traffic onto the access link than it can handle, causing queues, packet loss and degraded performance for other apps. Subscription users should not change parameters to values unrelated to their local connection just to chase speed. Prefer the settings already coordinated by the subscription and client.
Good Hysteria2 performance under certain packet-loss conditions does not fix poor Wi-Fi coverage, a congested egress or a busy destination server. If packet loss occurs on the home Wi-Fi segment, competition between the device and router remains. If the egress lacks capacity, a protocol cannot create more. To judge whether it's a good fit, check whether your app works consistently, whether other devices are noticeably affected and whether the client gets unusually warm. A single burst during a large file transfer is not evidence of sustained performance.
TUIC Connection Multiplexing and Persistence
TUIC uses QUIC connections to forward traffic and provides connection management for proxy use. Multiplexing can reduce the need to establish underlying connections repeatedly, but it does not benefit every app in the same way. Short webpage requests, continuous video and interactive traffic have different latency needs, and the client must manage streams and keep the connection alive. QUIC has mechanisms related to path changes, but whether a particular client and proxy deployment fully support them—and whether apps keep working after a network switch—must be tested. A capability in the underlying protocol does not guarantee that an app will stay connected.
| What to observe | Potential benefit | What to keep in mind |
|---|---|---|
| Multiplexed streams | Less in-order blocking between streams | Shared capacity still has limits |
| Connection reuse | Can reduce some repeated setup costs | Client and server implementations must be compatible |
| Mobile networks | May take advantage of path-change capabilities | Does not replace testing an actual network switch |
| Restricted UDP networks | Potential benefits may not materialize | Keep a compatible alternative route available |
If your current network handles UDP unreliably, these protocols may struggle to establish a connection, while available TCP-based options continue to work. In that case, keeping a compatible alternative route is more practical than repeatedly changing the same setting. For a fair comparison, keep the region, access network and app consistent. Record whether the connection succeeds and whether the task completes before comparing protocols. Don't combine results from different regions, times and clients; you won't be able to tell whether any improvement came from the protocol or the route.
Route Topologies: Direct, Relayed and Dedicated
A region identifies egress, not the full network path
The region shown in a client usually helps identify the egress location, but the point where data enters the service network may be elsewhere. A request may reach an entry point first, travel along a forwarding path to egress and then connect to the destination website. An egress near the destination may shorten the final leg, while an entry point near the user may improve reachability over the first leg. Consider both. Geographic distance alone is not a reliable way to predict latency: carrier interconnections, routing policies and congestion can make traffic take a detour. A short distance on a map does not necessarily mean a short network path.
A direct route usually connects the client straight to an overseas server entry point. The path is relatively straightforward, but performance depends more on the local carrier's international connectivity. Fewer forwarding steps and a simpler path may help, but they do not guarantee reliability. A direct route may work well on one access network and perform quite differently on another. Choose based on how your apps actually work, not on the assumption that “one less relay” must mean faster. Direct routing is one path option to compare, not an automatic quality tier.
How Relays and IEPL Dedicated Links Affect Performance
A relay adds a forwarding step between the client and the final egress to combine paths across different networks. A well-chosen entry point and onward route can avoid poor interconnection paths and deliver more consistent performance. But extra steps also require capacity, maintenance and failover planning. Relaying is not simply about making the distance longer or shorter; what matters is which network segment is used. If a problem occurs, check whether other egresses using the same entry point are affected too. This can help distinguish an entry-point issue from a forwarding issue or a problem with one particular egress.
An IEPL dedicated link means that dedicated connection resources are used as part of the route. This can reduce uncertainty on some shared paths. However, traffic from the user to the entry point still uses the local access network, and traffic from egress to the destination website may still use the public internet. So the dedicated-link label does not describe the entire path. Dedicated links are also subject to capacity planning, entry-point quality, maintenance and destination-site conditions. Think of a dedicated link as one part of the route's resource allocation, not a promise that every website will always load at the same speed.
| Type | What the topology affects | What to check |
|---|---|---|
| Direct | The interconnection path from the local network to the server | Access carrier and international link performance |
| Relayed | The combination of entry point and onward path | Related failures at the same entry point; egress differences |
| IEPL dedicated link | How dedicated connection resources work with the public access segment | Entry-point reachability, sustained transfer and egress |
Balancing latency and reliability
Interactive apps depend on consistent response times, while large downloads and video need enough capacity for sustained transfer. A route may have a lower idle latency reading but develop long queues when busy, making it worse for a video call than a route with a slightly higher but steadier reading. First rule out failed connections and obvious interruptions, then compare how your apps perform. If an app requires a particular region for account or content rules, don't switch egress locations repeatedly just to chase a lower test result. That can introduce new app-side variables before the network issue is resolved.
VPNCross offers 90+ countries / 190+ routes. Check the route list and available options after signing in for specific regions and route types. The list shows the range of options, not that every region has the same path structure. When comparing routes in the same region, first distinguish direct, relayed and IEPL dedicated routes, then consider the protocol and access network. If possible, keep your usual route and a backup with a different topology. Switching paths can reveal more than changing protocol names within the same entry point.
Packet Loss and Congestion: Why Connections Slow Down at Peak Times
Latency, Jitter and Throughput Are Different Metrics
Latency is the time between a request and response. Jitter describes how that time varies. Throughput measures how much data is transferred over a period. These metrics are related but not interchangeable. A quick response when the network is idle does not guarantee the same responsiveness during a large transfer. Video can use buffering to tolerate some delays, while voice calls are more sensitive to sudden jitter. Understanding the difference helps explain why a speed test can look good even when everyday interactions feel sluggish.
Packet loss can result from wireless interference, overloaded devices, full queues, path changes or a problem along one link. Reliable transport usually recovers missing data through acknowledgements and retransmissions, but recovery takes time and may trigger a reduction in sending rate. Apps may show this as a stalled webpage, video buffering or a request timeout. A protocol can change how recovery works, but cannot guarantee that users never notice packet loss. In sustained congestion, simply retrying more often uses even more of an already strained link.
Peak-time bottlenecks can occur at different points
Slower connections at peak times indicate pressure on one or more shared resources, but do not identify the service egress as the cause. Your home network may be handling video and backups at the same time; the access carrier may have queues on an aggregation segment; the route entry point or international link may be busy; or the destination site may be throttling traffic. Compare across a few boundaries: are local websites slow too? Are other routes also affected? Do different destinations on the same route show the same problem? Each comparison helps narrow down a different part of the path.
Long queues can increase interactive delays even more noticeably than they reduce average throughput. Background uploads, cloud sync and system updates can keep your home network's outbound queue busy, delaying acknowledgements and interactive requests. Pause nonessential, high-volume tasks and check whether the problem improves. It's a simple, low-cost test. If performance returns, investigate local traffic contention and router queue management rather than immediately blaming a particular protocol.
How to read network test results without jumping to conclusions
Basic diagnostic tools may not send traffic the same way as real apps. Intermediate devices may give probe packets a lower response priority, so a nonresponsive hop does not mean the same proportion of data is being lost by your end-to-end traffic. A timeout in a traceroute can also mean only that a device does not reply to probes. Check whether the final destination is reachable, how the app request performs and whether transfers stay stable. Don't declare a route broken based on one blank hop, and don't treat test results as a service availability guarantee.
Keep test conditions consistent when comparing routes. Don't judge one route's interactive performance while a background download is running on another. Use the same destination and perform the same action. Record whether the first connection is slow, ongoing loading is slow or the connection drops mid-session. Then see whether the issue changes after switching route types. If only one app has a problem, keep its error message and note the circumstances. If several apps are affected, broaden the check to the access network, entry point and system. Narrowing down the scope this way is more useful than repeatedly refreshing a speed test.
If a problem consistently occurs at certain times, note the access network, selected region, route type, client status and affected app, then share those details through a support ticket. Never share your subscription URL or account credentials publicly. “Webpages work on the same network, but continuous video stops; switching to a different entry point fixes it” is more useful than “it's really slow at night.” Reproducible details help us investigate and reduce the need for follow-up questions.
Platforms and Battery Life: The Cost of Keeping a Connection Alive
Power use comes from processing—and from wake-ups
Mobile battery use comes not just from encryption, but also from wireless communication, background wake-ups, connection keep-alives and app activity. A protocol that uses few resources on a computer may generate more heat on a mobile device if it reconnects frequently or transfers data continuously. Hardware acceleration, system networking interfaces and client implementation also affect the result. “Lighter protocol means better battery life” is an oversimplification. Compare battery use during standby, ordinary browsing, video and sustained downloads rather than attributing differences across workloads to the protocol alone.
Keep-alive traffic helps prevent session state along the path from expiring too soon, but more frequent keep-alives are not always better. They can wake the wireless radio more often, while less frequent keep-alives may allow some networks to close idle connections. The right balance depends on the access network and client design. Most users should keep the default settings. Adjust them only when you see a specific issue, such as the first request failing after a period of inactivity, and follow the client documentation rather than copying settings for a different device and network.
Background system policies can change test results
Mobile operating systems limit app activity through background management and battery-saving features, and behavior varies between systems and devices. If the connection changes when the screen turns off, the cause could be system scheduling, a network switch or an idle-session timeout. Test separately with the app in the foreground, in the background, with the screen off and after returning to the app. If the problem occurs only in the background, first check the system's background activity settings and the client documentation rather than assuming the egress is unavailable.
When switching from Wi-Fi to mobile data, the device's address, routes and network state may change. Even if the underlying protocol supports connection migration, the app may not be able to keep its existing session. An upload, meeting or long-running response may still need to reconnect. If a task must continue uninterrupted, avoid switching networks in the middle of it. If you have to switch, wait until the client reconnects before continuing. A reconnect indicator does not mean an unfinished task in an app will automatically resume.
| Platform | What to check | Where to get it |
|---|---|---|
| Windows | System proxy, virtual network interfaces and other networking software | Get the client from the account panel |
| macOS | Network permissions, system proxy and recovery from sleep | Get the client from the account panel |
| iOS | Network configuration permissions, background behavior and network switching | An active plan is required to download |
| Android | Background management, battery settings and network permissions | Get the client from the account panel |
| Linux | Desktop proxy settings, environment variables and per-app settings | Get the client from the account panel |
Routing rules, split tunneling and logs also have a performance cost
Smart routing evaluates which path each request should use. Rule-set size, matching methods and DNS configuration can all affect processing. More rules do not automatically mean greater accuracy, and sending all traffic through one route is not always simpler. Some desktop apps ignore the system proxy and need the client to use an appropriate traffic-capture method. Multiple tools that change the system proxy or network interfaces can also conflict. When troubleshooting, make sure only the intended client is handling traffic so you don't mistake a conflict between apps for protocol behavior.
Local diagnostic logs in your client are not the same thing as VPNCross's no-logs service policy. If you enable local logging to troubleshoot, remember that logs may contain domains, subscription identifiers and connection details. Don't share the entire file publicly. Return the logging level to its normal setting when you're done to avoid accumulating unnecessary information and extra processing. VPNCross supports Windows / macOS / iOS / Android / Linux. Get clients from the download section of the account panel; sign in to access your subscription.
Choosing for Your Needs: Start with the App, Then Consider the Protocol
Web browsing, development and AI requests
Everyday web browsing involves many short requests, so connection setup, DNS resolution and content delivery location often shape the experience. Start by checking whether your usual sites load smoothly, then compare response consistency across routes in the same region. There's no need to keep switching just to chase a protocol name. Development tools may have their own proxy settings, so a working browser does not mean your terminal, code editor or package manager is using the same route. Test in the tools you actually use rather than assuming your development setup is connected because one webpage loads.
Treat AI websites and API calls as separate use cases. The web interface depends on login state, browser sessions and page assets. API calls depend on authentication, request timeouts, streaming output and the app's retry behavior. A network drop may interrupt the response even if the server has already processed the request, so consider whether repeating an operation is safe before retrying automatically. A consistent egress requirement also depends on the route and app policies; you can't infer it from the protocol name. For more development use cases, see our guide to choosing a VPN for AI APIs.
Streaming, Video Calls and Large Files
Streaming depends on sustained transfer and content availability. Playback may start quickly but buffer repeatedly if capacity is insufficient or the content delivery path changes. Platforms may also determine what's available based on the account, licensing region and detected egress location, so a successful connection does not guarantee access to a particular catalog. For a useful comparison, keep the account, content and playback settings the same and observe continuous playback instead of changing both the title and egress repeatedly. If only a content-permission message changes, handle it separately from a network transport problem.
Voice and video calls and remote collaboration are more sensitive to latency variation. Even when they use little data, uploads and queuing can disrupt them. Before a call, pause nonessential high-volume sync, choose a consistently performing route and avoid switching regions mid-call. For large file transfers, check whether the connection stays up, whether transfers can resume and whether local storage is the bottleneck. Protocols provide transport mechanisms, but the app determines whether transfers can recover. Not every failed download is caused by insufficient route bandwidth.
| Use case | What to check first | Avoid this assumption |
|---|---|---|
| Web browsing and research | Initial load and subsequent resource loading | Judging by idle latency alone |
| AI and development | Long responses, app proxy settings and timeouts | Assuming a working webpage means the API works too |
| Streaming | Continuous playback and content availability | Mistaking a regional content message for a protocol problem |
| Calls and collaboration | Jitter, network switching and upload contention | Comparing download throughput alone |
| File transfers | Sustained transfers, resuming and local resources | Treating a short burst as sustained performance |
Usage allowance and technical choices are separate considerations
The right route for a task still needs to fit your actual data needs. VPNCross monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Data resets monthly on the activation date; mid-cycle upgrades are prorated based on the remaining days. Data add-ons are ¥158/300GB, ¥358/1000GB and ¥658/3000GB, valid until used and with no expiration. See the plans page for details. Avoid repeatedly transferring large files for protocol testing. Test data counts toward your actual usage, and a different protocol does not guarantee lower data use for the same task.
VPNCross allows unlimited simultaneous devices, but you'll still need to manage your home network and plan data across them. No email address is required; you can create an account with a username and password. Payment methods: Alipay / WeChat Pay / USDT. A 60-day no-questions-asked refund is available. These service details have no direct bearing on protocol performance, and a larger data plan does not make the client automatically switch protocols. Check your needs, access network and client compatibility before choosing a plan to avoid confusing billing questions with technical issues.
Testing and Troubleshooting: Narrow Down the Point of Failure
Capture the current setup before changing anything
At the start of troubleshooting, note the client, access network, route region, protocol and app message, and check whether you can reproduce the issue. Don't update the client, change protocols, alter DNS settings and switch egress all at once. Even if that fixes things, you won't know why. Instead, keep the other conditions unchanged, modify one suspected factor and repeat the same action. Each test should answer a specific question, such as “Does the handshake complete?” or “Does the long response get interrupted?” rather than just “Does it feel faster?”
If no routes work, first confirm that your device can access ordinary websites over its local network. Then check that the client is enabled, the subscription imported successfully, and system time and permissions are correct. If only one node has a problem, compare it with an available option that uses a different path or entry point. If only one app is affected, check whether it uses the system proxy or its own network settings, and whether the message comes from the account or service. This helps narrow the problem from the whole device to a particular route or app, without piling on unrelated changes.
Subscription Integrity and Certificate Issues
A subscription link lets the client retrieve route configuration; it is not an ordinary webpage URL and should not be shared publicly. If importing fails, first determine whether the subscription could not be downloaded, the format could not be parsed, or the route could not connect. The first points to network or link status, the second to client format support, and only the last to a specific server connection. Don't delete unfamiliar fields to force an import; missing fields can turn an obvious import error into a harder-to-diagnose handshake problem. For the basics, see our guide to getting, importing and updating a subscription link.
If you see a certificate or identity verification error, keep the original message, check the system clock and subscription status, and use the standard verification method supported by the client. Don't disable verification as a permanent setting or post your subscription in a public forum for someone else to test. If you need to submit diagnostic details, share only the relevant error excerpt and hide account identifiers, subscription URLs and credentials. A no-logs service policy does not mean screenshots or diagnostic files on your device are safe to share without checking them first. You remain responsible for controlling where they go.
Write diagnostics so someone else can reproduce the issue
A useful report should say whether the problem happened in the foreground or background, whether you had just switched networks, whether ordinary websites worked, whether other routes in the same region worked and what the destination app reported. If the problem returned after recovery, note what changed just beforehand. Don't paste your full configuration or guess which network segment is at fault. Submit these details through a support ticket; an organized report is usually more useful than a stream of speed-test screenshots. This page does not provide public subscription URLs or direct installer links.
Once the connection is back, test it again using your normal workflow: web users should confirm page resources load; developers should make a request in their actual tools; streaming users should watch continuous playback; and people on calls should check for steady audio and interaction. Then remove any temporary troubleshooting rules, restore the normal log level and keep only settings that proved useful. Avoid piling on extra “optimization” settings after recovery, as new variables can destabilize a working setup. Settings that are easy to explain and revert are easier to maintain than complex ones with unclear effects.
For step-by-step setup, go back to the Guides. To compare paths, see the route list. For prices and data reset rules, see the plans page. Protocols, routes, clients and apps each have different roles; no single toggle replaces them all. With this layered approach, you can evaluate any new protocol by asking the same questions: What transport does it use? How does it protect the connection? Does your platform support it? Does it make your actual apps more reliable?