VPNHO Protocols and Network Routes

Connection metrics: Break down a cross-border connection

A connected client doesn't mean the app can access its destination

A connection involves several handoffs: an app sends a request, the client decides whether to proxy it, traffic reaches a node, and an exit server connects to the destination. A connected status usually means only that the proxy tunnel is ready. You still need to check whether the destination accepts the exit, whether the domain resolves correctly and whether the app uses the system proxy. Conflating these steps can make account errors, DNS failures or app routing issues look like protocol performance problems.

When you first open a page, DNS lookup, transport setup, the encryption handshake and server processing can all add delay. Later requests may reuse an existing connection and feel very different. When comparing protocols, separate first-time access from continued use: the first request better reflects connection setup costs, while repeated page loads or long playback reveal connection reuse and sustained throughput. Comparing a client that has just started with one whose connection is already warm usually leads to unreliable conclusions.

Latency is the round-trip wait; bandwidth is the capacity of the connection; throughput is the rate at which an app actually receives data. They are related, but not interchangeable. A route with fast downloads may still feel sluggish for interactive tasks, while a low-latency route may struggle to sustain video when congested. Before choosing, define the goal—responsive browsing, file transfers, smooth live streams or stable sessions—so you know what to measure.

Assess connection setup, resource use and stability separately

A protocol's handshake is only one part of setting up a connection. Using TCP or QUIC underneath, adding TLS or applying extra transport encapsulation can all change the exchange. Node authentication, client implementation and connection reuse matter too. So you can't rank protocols by speed based on their names alone. Differences between implementations of the same protocol can be greater than differences between protocols.

Resource use includes encryption, memory buffering, connection management and network activity. Desktop devices typically have more processing headroom, so route quality may matter more. On mobile, also consider keeping the wireless interface active, background wake-ups and reconnects. If the client uses more battery, don't immediately blame encryption. Weak signal, frequent network changes, continuous uploads and overly frequent keepalives can all affect battery life.

Stability also needs to be tracked by symptom. A dropped tunnel, app request timeout, video buffering and lost login session point to different layers. Note the network, route name, protocol, target app and symptoms, and keep a brief client error summary. Don't copy subscription links or authentication details into your notes. This makes it easier to tell what changed after switching routes instead of simply labelling one as “unstable.”

Set a baseline you can reproduce

Keep the device, access network and task the same when comparing. Pause background transfers, and avoid changing the exit region and protocol at the same time. If the panel doesn't offer different protocols over the same route, you're comparing complete route setups—not protocols in isolation. Record first requests separately from ongoing requests, and account for cached content, existing sessions and destination server load when interpreting results.

Shadowsocks and VMess: trade-offs in encapsulation and authentication

Shadowsocks: a straightforward proxy transport

Shadowsocks routes app traffic through an encrypted proxy tunnel, which then accesses the destination remotely. It typically doesn't expose a complete network interface directly to apps. Whether it covers all device traffic depends on the client's system proxy, tunnel mode and routing rules. Seeing Shadowsocks in a subscription tells you the node uses this proxy protocol; it doesn't mean all apps are using the tunnel or reveal which encryption method is configured.

Its transport model is relatively straightforward, so start troubleshooting by checking the address, port, encryption method and authentication parameters. Implementations using modern authenticated encryption protect confidentiality and verify integrity, but the actual security properties depend on the algorithm, key management and ongoing maintenance. Protocol support alone doesn't prove that encryption is configured correctly. Don't replace the subscription's encryption method with a setting recommended online; a mismatch with the server will prevent the connection.

Less encapsulation can reduce processing overhead, but actual resource use also depends on hardware acceleration, the client core, connection count and traffic patterns. Browsing differs from sustained file transfers, and keeping a tunnel active in the background has different costs from foreground encryption. When using Shadowsocks, check that apps match the intended routing rules, UDP is forwarded correctly and the route suits the task.

VMess: combining authentication and transport layers

VMess defines authentication and data handling for proxy sessions and is often paired with different underlying transports. A node list may show VMess without specifying transport encapsulation, TLS or other connection options. These combinations affect the handshake and how intermediate devices handle the connection. For troubleshooting, check the node details actually imported into the client rather than relying on the protocol label in the list.

Incorrect authentication parameters, client incompatibility or an incorrect system clock can prevent a session from connecting. Clock issues are easy to miss: being able to open regular websites doesn't mean proxy authentication that relies on time checks will work. If logs show repeated authentication failures, check that the subscription is valid and the device clock is syncing normally, then refresh the subscription and verify the configuration. Don't assume the problem is peak-time congestion.

Extra transport encapsulation can add processing steps, but may also suit a particular deployment. Whether it's useful depends on the network and server configuration. More layers don't automatically mean more stability: each has its own timeouts, buffering and connection lifecycle, making troubleshooting more complex. Keep the configuration supplied by the panel to avoid mismatches between the client and server in routing, host fields or transport settings.

How to compare them and troubleshoot compatibility

Before choosing between them, confirm that the client fully recognizes the subscription—not just the node name. If a node has unsupported fields or an unrecognized transport, get a supported client from the user panel or choose a compatible node listed there. Don't delete unfamiliar fields just to make a configuration “pass validation”; they may contain authentication or transport settings required by the server.

If the same task performs differently on the two types of nodes, first check whether they use the same exit and route type. A relayed route versus a private line can produce different results regardless of protocol. Discuss protocol and implementation overhead only when other conditions are broadly the same. If they aren't, record the result as a comparison of node setups. For everyday use, a compatible setup that reliably completes the task is more useful than an abstract protocol ranking.

Apps that use UDP need additional checks. Client support for a protocol doesn't guarantee that every part of the current route forwards UDP correctly; a system proxy may not cover an app's UDP traffic either. If browsing works but a real-time app doesn't, first check the client mode, routing rules and node UDP support, then investigate the exit route. Compare the technical details with the route-type descriptions in the route list so you don't change protocols while leaving the underlying route problem untouched.

Trojan and VLESS: authentication and encryption are separate layers

Trojan: understanding TLS in the connection

Trojan often uses TLS to establish a protected transport channel, then handles proxy authentication and requests within it. TLS protects data in transit and verifies the server's identity; proxy authentication determines whether a user can access the node. These are separate steps. A failed certificate check and an incorrect proxy password call for different troubleshooting. Treating both as “node unavailable” can obscure a configuration issue you can fix directly.

Certificate validation involves the server name, trust chain and validity period. The server name in the subscription should match the server configuration; don't change it to the node address or enter an arbitrary domain. If you see a certificate error, check the system clock, make sure the subscription is current and confirm that the client is supported, then ask support to verify the node configuration through a ticket. Disabling certificate verification may change the error, but it also disables server identity checks and isn't a suitable long-term fix.

The TLS handshake adds exchanges and processing when a connection is first established, but that cost can be spread across a persistent connection. Connection reuse in the browser and client, and how often a task creates short-lived connections, affect the experience. For long transfers, route congestion and exit capacity are often more important. The presence of a TLS handshake doesn't mean Trojan must be slower over time, and a fast first page load doesn't guarantee overall stability.

VLESS: lightweight authentication doesn't provide full encryption

VLESS focuses on lightweight proxy authentication and request handling; the protocol layer itself doesn't provide full data encryption. A suitable secure transport must be configured before you can assess how well the connection protects data. Knowing that a node uses VLESS isn't enough to determine its security, connection setup or resource use. Check the underlying transport and the related server requirements too.

That's why VLESS nodes can behave differently across clients. A client needs to understand the full configuration, not just recognize the protocol name. The server name, transport options and authentication fields supplied by the panel may be interdependent. If you copy only the address and user ID and omit other fields, the node may appear in the list but still fail to connect. Import the complete subscription rather than recreating the configuration from memory.

When discussing lightweight design, distinguish protocol header overhead, encryption work and client scheduling. Less work at the protocol layer doesn't eliminate secure transport costs or shorten the physical route. For many short requests, connection reuse may matter more than header size; for long video sessions, steady data delivery often matters more than handshake differences. Choose based on the task, not on “lightweight” as a universal advantage.

Choose the next step based on where the error occurs

If the connection fails during certificate validation, check identity verification and configuration consistency first. If it reaches proxy authentication, check the subscription and authentication fields. If the tunnel connects but only certain sites fail, investigate app routing, DNS and whether the destination accepts the exit. This sequence helps avoid unnecessary route changes. Error messages vary between client implementations, so interpret them in context and at the stage where they occur rather than relying on a single line of log output.

VPNHO describes its encryption as bank-grade, but technical checks still come down to using a supported client, importing all subscription parameters and keeping security verification enabled. Encryption protects data in transit; it doesn't replace account security on destination sites or device maintenance. Don't send authentication details to unfamiliar online configuration tools when troubleshooting. If you need help, use a panel support ticket and include a redacted error summary and the steps to reproduce it.

Hysteria2 and TUIC: transport over QUIC

How UDP, QUIC and app data work together

UDP transports datagrams; unlike TCP, it doesn't provide an ordered, reliable byte stream by itself. QUIC builds secure connections, reliable delivery and stream management on top of UDP, so “UDP-based” doesn't mean app data can be lost without consequence. Hysteria2 and TUIC use QUIC-related mechanisms to carry proxy traffic, but their authentication, congestion control and forwarding strategies differ. They're not the same protocol with different names.

QUIC can carry multiple logical streams over one connection, reducing the direct impact of lost data in one stream on ordered delivery in others. However, streams still share route capacity and congestion state. If the access network keeps losing packets or the exit is saturated, other requests can still slow down. Multiple streams improve how transport is organized; they don't create extra bandwidth or guarantee the same performance for every app at peak times.

Before choosing a protocol, check whether the access network allows reliable UDP communication. Some office, campus and guest networks handle UDP differently, and other network tools on the device may change the datagram route. If TCP-based nodes work but QUIC-based nodes won't connect, suspect UDP reachability or client support first rather than increasing transport parameters. Keeping a compatible backup route is usually more effective than forcing configuration changes.

Hysteria2: match throughput targets to the actual route

Hysteria2 is designed to organize traffic over routes with latency or packet loss, and includes configuration options related to bandwidth estimation and congestion control. The implementation and server settings determine which options take effect. Don't copy bandwidth values from online guides into the client: an overly aggressive sending target can create queues on the access link and affect other apps, while an overly conservative estimate may underuse available capacity.

Treat these parameters as inputs to transport policy, not proof of ISP bandwidth or a speed guarantee from the service. A protocol label in a node name doesn't reveal the server's specific strategy. Start with the configuration provided through the subscription and test it on a real task. If something goes wrong, check the panel documentation and settings in a supported client. Increasing values without monitoring queues, packet loss and app response can make a faster download look like an overall improvement when it isn't.

Long downloads alongside web browsing are a useful way to observe these limitations. If files progress quickly but web pages and real-time sessions lag, the local access link or route queue may be saturated. Pause the download and check interactive response, then look for a full upload queue or background sync. Adjust the workload and route selection rather than immediately blaming a Hysteria2 protocol flaw.

TUIC: stream management, authentication and connection lifecycle

TUIC also uses QUIC to organize proxy connections, with mechanisms for authentication, reliable streams and datagram forwarding. Its performance depends on client-server compatibility, successful negotiation and the congestion control strategy in use. Some implementations may offer options related to early data or connection reuse, but check the actual configuration to see whether they're enabled and supported. The protocol name alone can't guarantee a faster first connection, and test results from one implementation don't automatically apply to another.

During mobile network changes, QUIC connection IDs and path validation provide a basis for connection migration. Whether a session actually survives also depends on implementation support, address changes, network policy and the proxy route. The system may pause an app in the background, the server may time out a session, or the new network may restrict UDP—all of which can force a new connection. Using QUIC doesn't guarantee that every app session will survive a switch between wireless and mobile networks.

When evaluating these protocols, check connection setup, ongoing interaction, sustained transfer and recovery after network changes separately. First confirm the tunnel connects, then test the target app; don't rely only on the node test in the client. For uploads or live meetings, successful delivery and session continuity matter most; for video, focus on buffering and recovery. General comparisons can help frame a hypothesis, but you still need to test on the actual access network.

Direct, relayed and private routes: how routes connect

Direct routes: a simple path, with quality determined by actual routing

A direct route usually means your device connects straight to a remote entry point without an additional relay configured by the service provider. “Direct” describes the service topology; it doesn't mean there are no ISP routers or that the physical path is shortest. Internet traffic follows ISP peering and routing policies, so a node that looks geographically close may still take a longer route. Map distance is only a rough starting point, not a reliable way to predict latency.

Direct routes have fewer handoffs, which can make it easier to distinguish local access problems from remote node issues. But they're more directly affected by public peering, inter-network congestion and routing changes. If a route works during the day but slows down consistently at peak times, shared path capacity may have changed. Switching protocols while keeping the same entry and exit may not resolve the bottleneck, because it lies outside the proxy protocol.

Also distinguish the proxy entry from the final exit. Apps see the exit identity when accessing a destination, while the client connects to the entry address; they may be in different locations. Node names are labels to help users choose, not a full network topology. To check whether a platform accepts access, verify the actual exit and account requirements. To troubleshoot connection setup, focus on the route from your device to the entry.

Relay routes: add a handoff for more routing options

A relay route sends traffic from your device to an entry or relay node, then on to a remote exit. An extra handoff doesn't necessarily mean a slower experience: if the public route otherwise takes a long detour, a relay may provide a better path overall. But it adds components to maintain. Congestion at the entry, forwarding queues or the relay-to-exit connection can become bottlenecks, so the route type alone doesn't guarantee an advantage.

When a relay route has problems, compare nodes with the same entry but different exits, and nodes with different entries in the same region. If several exits behind the same entry fail at once, check the entry or shared relay segment first. If only one exit is affected, the cause may be exit load, remote peering or whether the destination accepts access. If the panel doesn't show the full topology, don't guess which data center is involved. Share a comparison of symptoms with support to help identify a shared route.

For users, the entry location and exit location serve different purposes. The entry affects the initial handoff; the exit affects access to the destination and how your region is identified. For streaming or AI tools, choose based on whether the exit meets the platform's requirements—not the relay entry's name. Read region labels in the route list alongside the panel notes. If a label is unclear, confirm what it means before choosing.

Private lines: check exactly which segments are dedicated

An IEPL private line typically refers to a dedicated Ethernet transport segment connecting network endpoints in different locations. Its resource model differs from public internet relaying and can give the provider control over handoffs on that segment. But your device's route to the access point and the exit's route to the destination may still use other networks. A private-line label doesn't mean every end-to-end segment is dedicated, nor does it override a destination platform's account, licensing region or access rules.

VPNHO covers 120+ countries and offers 210+ routes. For available nodes, regions and route types, check the route list and the options currently shown in the panel. Coverage doesn't mean every region has the same topology or can access the same services. Start by identifying the exit you need, then compare entry access and peak-time performance. For regular use, keep a proven primary route and a backup that takes a different path, avoiding a backup that shares the same bottleneck.

Packet loss and peak-time slowdowns: locate the queue

Congestion isn't just “slower speeds”

Congestion occurs when a segment of the route receives more data than it can handle at that moment. Data may wait in a queue; as the queue grows, packets may be dropped. You might notice slow-loading web pages, video buffering or stalled uploads. Peak times are a common opportunity to observe changes in shared resources, not a diagnosis. The bottleneck could be your home router, access network, ISP peering, relay entry, exit or destination service.

A saturated upload is especially easy to misdiagnose. File sync, photo backups or sending documents can fill the local upstream queue, delaying small packets and acknowledgements needed by other connections. Downloads and web browsing may slow down even though the exit route hasn't changed. Pause background transfers and test again on the same access network. If things improve, address local network load instead of repeatedly switching remote nodes.

Weak wireless signal, interference and a crowded access point can also cause retransmissions and delays. A proxy client can't fix wireless link problems. If possible, move closer to the access point or try a more stable connection while keeping the exit and task the same. If every node has problems on one access network but works on another, investigate the local link before blaming protocol differences. This comparison is more informative than simply running another speed test.

Packet loss, retransmissions and head-of-line blocking

Packet loss can come from congestion, wireless errors, device processing or network policy. Reliable transports try to recover missing data, but recovery takes time and may change the sending rate. TCP delivers a byte stream in order, so missing earlier data can temporarily hold up later bytes from the app. If multiple app requests share a connection through client multiplexing, the effect depends on the client's reuse strategy. A single slow page can't tell you which layer is losing packets.

QUIC organizes delivery across streams more independently, but those streams still share congestion control and route capacity. Sustained loss can slow the overall transfer and increase device processing and network activity. A QUIC-based option is worth testing, but it won't fix every kind of packet loss. Confirm that the UDP route is stable before comparing real tasks. If you also change the exit, acknowledge that the route change contributed to the result.

Tunnel encapsulation also takes up packet space. If the path's supported packet size doesn't match the client's encapsulation, small requests may work while larger ones stall. The issue can be worse if fragmentation or related control messages are handled differently. Check the supported client's default settings and your access network first; don't copy MTU values from online guides. Changing packet size is a targeted troubleshooting step: save the original value and retest your task.

Narrow down the cause with cross-checks

Start by comparing regular internet access with proxy access, then try a different exit and finally another access network. If regular access is also affected, investigate the device or access network first. If multiple exits through the same entry fail, check the shared entry segment. If only one destination fails, focus on the destination and app routing. This isn't a definitive diagnosis, but it helps control variables and turns “everything is slow” into a clear, comparable report for support.

When comparing different times of day, keep the task the same. Opening a cached page during the day and watching a live stream at night doesn't prove the route degrades at peak time. Repeat the same steps and record first response, sustained transfer and the stage where a failure occurs. A node test's round-trip result reflects its test target and method, not necessarily the path used by a real app. Don't present a small change in one test as a change in overall service quality, especially if the tasks differ.

If the problem persists, submit a redacted client error, access network type, node label, target app and reproduction steps through a panel support ticket. Results after changing routes and access networks are usually more useful than a screenshot without context. For live sports, see the guide to choosing routes for live sports and consider player behavior alongside buffering.

Platforms and battery use: background behavior affects connections too

Mobile battery use depends on computing and network activity

Mobile battery life isn't determined by protocol encryption alone. Keeping the wireless interface active, background keepalives, repeated reconnects, sustained transfers and signal strength all play a part. A protocol that performs well during a foreground download may not be more efficient while the screen is locked. Before comparing, define the task—extended playback, frequent short requests or background standby. Their different workloads don't fit into a single battery-efficiency ranking.

Keepalives maintain connections or let network devices know a session is still active, but sending them too often can increase wake-ups and wireless activity. If the interval is too long, an intermediate device may expire an idle connection and the next request will need to reconnect. Use the settings supported by the client and server rather than copying values from another network. If the connection often drops when the screen is locked, check system background policies and network changes before investigating protocol keepalives.

Switching between mobile and wireless networks changes the address, route and interface state. Even after the proxy tunnel reconnects, an app may need to re-establish its existing connection, and an upload may need to be submitted again. Distinguish a successful client reconnect from continuity of the app session. Before important tasks, make sure the network is stable; avoid switching networks during an upload, payment confirmation or live meeting. A protocol can't replace the app's own recovery behavior.

Background limitations on Android and iOS

Background and battery management vary across Android versions and device settings. If the client works in the foreground but disconnects when the screen is locked, check its background permissions, battery restrictions and network access. Also check whether another network tool is competing for the same tunnel. Adjust restrictions only as needed for your connection; you don't have to exempt every app. See the guide to Android background connections and per-app proxy settings for more details.

Per-app proxying can keep unnecessary traffic off the route while letting local apps use their usual connection, but the rules need to cover the full workflow. An app may use an external browser to sign in or call a system component to upload a file. Proxying only the main app and missing those components can break the login redirect. After changing rules, test the complete task rather than just confirming the app's home page loads.

On iOS, the system manages network extensions and background behavior, and the available client settings may differ from desktop. The screen locking, network changes and system resource scheduling can all affect a connection's lifecycle. If something goes wrong, check the supported client's connection status and system network permissions rather than applying Android background settings. A tunnel indicator in the system interface also doesn't prove that every app's traffic is being proxied.

Verify the actual app route on desktop too

On Windows, macOS and Linux, the system proxy typically affects only apps that follow the relevant setting. Command-line tools and standalone network components may use their own proxy options. Tunnel mode can cover more traffic but requires appropriate permissions and routing. If a browser works but a terminal doesn't, check whether both use the same route before switching nodes. New Windows users can start with the guide to setting up the client and starting it with Windows.

VPNHO supports Windows, macOS, iOS, Android and Linux, with unlimited simultaneous devices. Each device still needs a compatible client and its rules checked individually. Get clients through the user panel. Results on one device don't necessarily apply to every platform. Test foreground tasks, recovery after locking the screen and network changes before settling on a protocol and backup setup.

Choosing for your use case: make a recommendation you can verify

Set priorities based on the task

Browsing and online learning platforms usually need reliable short requests, sign-ins and resource loading, so start by checking the first response and whether ongoing use feels smooth. File transfers depend more on sustained throughput and connection recovery; live meetings need a reliable datagram path and resilience to jitter and network changes. There's no single protocol that wins in every case. Start with a supported default, complete your task and change the protocol or route topology only when you find a clear bottleneck.

AI tools may use different interfaces for sign-in, generation requests, streaming responses and file uploads. Opening the home page doesn't mean the full workflow works; whether the platform accepts an exit also depends on its policies and account requirements. Test the actual task and note whether it fails at sign-in, submission or during the response. See the AI acceleration guide for the topic overview; this page focuses on distinguishing protocol, route and app-level issues.

For streaming, separately verify platform access, account sign-in, content availability and sustained playback. Being able to open a platform through one exit doesn't mean all content will be available; region, account and licensing requirements are set by the platform. If playback stalls, check buffering and recovery, then compare the time and route. If it fails only when playback starts, check whether the platform accepts the exit. See the streaming access guide; a route label isn't a permanent guarantee.

Keep a primary setup and a genuinely different backup

Your primary setup should be a combination you've verified on your actual network, not the one with the most complicated name. Record the client mode, protocol, exit region, route type and tasks it suits. Choose a backup that differs at a likely bottleneck, such as a different entry or transport path. Two nodes with different names but the same entry may fail together. If the panel doesn't explain shared routes, don't invent a topology claim.

When comparing protocols, keep the route as consistent as possible; when comparing route topology, keep the task the same. After switching, first confirm basic connectivity, then test the target app and observe sustained use. An app may retain an old connection or cached state after a route change. Restart the task normally and, if needed, the app—but don't force quit it before saving your work. Keep records detailed enough for someone else to repeat the test, not just a note about how it felt.

Checking the exit and DNS is a separate line of investigation. Where a domain is resolved, whether an app uses its own encrypted DNS and whether the client routing rules match can all affect the result. One lookup page can't prove that every app follows the same route, and a single DNS result doesn't describe your overall privacy. See the guide to checking your exit IP, DNS and per-app routing, and evaluate connectivity separately from routing.

Handle technical and plan choices separately

A protocol doesn't replace plan data management, and its name alone doesn't determine data usage. Streaming video, file transfers and repeated uploads all use data; retries and encapsulation can affect metering too. Refer to the panel for how usage is counted. VPNHO monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Data resets monthly on the activation date, and mid-cycle upgrades are prorated by the remaining days. Don't interpret a data tier as a protocol entitlement or speed tier.

For occasional use, compare the data packages: ¥158/300GB, ¥358/1000GB and ¥658/3000GB. Data doesn't expire and remains available until used. See all options on the Plans and pricing page. Payment methods: Alipay, WeChat Pay and USDT. All plans come with a 30-day money-back guarantee; check the refund policy for full terms. No email address is required. Create an account with a username and password; account management and subscription delivery are handled in the panel.

To wrap up, record your choice in a short handoff note: device and access network, client mode, node label, task steps, observable results, backup route and open questions. If the problem persists, attach a redacted log summary to a support ticket. This makes it easy to reuse the same checks after changing networks or devices, or updating a subscription. The best evidence for long-term use is repeating the task successfully—not a one-off test result or protocol name.