VPN Protocol and Routing Technology Reference

A protocol is not a speed tier

A protocol determines how data is encapsulated, how sessions are established, how connection state is confirmed, and how loss is recovered. It affects handshakes, CPU use, memory allocation, reconnection timing, and recovery after network changes, but its name is not a speed rating. The same protocol can perform very differently across routes, while different protocols may all handle everyday access well on one stable route. Ranking protocols by speed usually overlooks the path quality that actually shapes the experience.

Start by identifying the workload. Web pages and text messages use many short connections, so users notice whether the first load feels immediate. File transfers and high-resolution video generate sustained traffic and depend more on steady throughput and long-running loss recovery. Voice, meetings, and remote desktops are more sensitive to jitter; a high average speed cannot hide sudden pauses in audio or video. The protocol should serve the workload, not force the workload to fit a popular name.

The route determines where data actually travels

Route topology describes the relationship between the entry point, forwarding points, and exit. With a direct route, the current network reaches the exit directly, keeping the path simple, although routing can change with carrier policies and network conditions. A relay route first connects to a nearby or well-peered entry point, which then forwards traffic to the target exit, reducing exposure to unpredictable public-network segments. A dedicated route adds emphasis on managing the intermediate link, focusing on path stability and congestion isolation rather than promising identical low latency for every device.

When a connection is slow, do not switch protocols immediately. If several protocols perform similarly through the same exit, first suspect the entry point, path, or exit load. If only one protocol reconnects repeatedly while others remain stable, then check its compatibility with the current network. This order reduces pointless switching and prevents route problems from being misattributed to the client.

The device environment changes the final result

Desktop systems generally allow connection processes to keep running, with relatively permissive power policies. Mobile systems may freeze background tasks, switch between Wi-Fi and cellular networks, and reschedule network activity after the screen turns off. A route that is stable on a desktop may not remain in the same state after a mobile device is locked. Client implementation, system network extensions, background permissions, and battery policies all shape the connection lifecycle.

When establishing a baseline, keep the node, protocol, and workload fixed and change only one condition at a time. For example, compare protocols on the same network, then compare routes with the protocol fixed, and finally test foreground/background switching. Changing the protocol, node, network, and client all at once may test many combinations, but it cannot show what caused the improvement. Technical selection should be reproducible rather than based on one lucky result.

Shadowsocks: Simple structure, dependent on route quality

Shadowsocks is best understood as lightweight encrypted forwarding. Its structure is relatively direct, implementations are widely available, and resource use is usually easy to control, making it a practical baseline for web browsing, messaging, developer tools, and ordinary downloads. It cannot repair congestion in the underlying route or eliminate jitter on the public network. When the underlying link is stable, its simple design can reduce extra processing; when loss persists, applications will still experience pauses.

With Shadowsocks, check whether the client correctly handles the system proxy, DNS, and connection reuse rather than focusing only on the cipher name. Some applications do not follow system proxy settings, while others cache DNS results independently, which can explain why a browser works but an app does not. Switching nodes again may not help; first confirm that traffic is actually entering the client.

VMess: Rich session state, more configuration points

VMess carries relatively complete session and identity information, and common implementations support different transport layers. Its strength is a broad range of deployment combinations, useful when compatibility with an existing service structure matters. The trade-off is a wider configuration surface, requiring client and server parameters to match. A mismatch in transport, encryption, security layer, or path can cause a handshake failure rather than simply reducing speed.

When troubleshooting VMess, verify identity, transport, and outer security separately. Subscription imports usually fill in these parameters automatically, so manually rewriting them and mixing them with the original configuration is not recommended. If the connection fails after import, refresh the subscription, confirm that the correct entry is selected, then check system time, DNS, and network permissions. More configuration does not guarantee better performance; VMess is better viewed as a toolkit for compatible deployments.

Trojan: Standard secure sessions with clear boundaries

Trojan typically runs over a TLS session, making its authentication and encryption boundaries easy to understand. It suits scenarios that need a standard security layer and mature networking libraries. Establishing a connection involves a secure handshake, so first-connection performance depends on DNS resolution, certificate validation, and network round trips. Once the session is stable, sustained transfer is still mainly determined by route capacity, congestion, and the exit.

It works well for desktop work, browser access, and persistent connections, and is often useful where application compatibility matters. If a network handles long-lived connections poorly, compare other protocols on the same node. If all TCP-based protocols pause in similar ways, packet-loss recovery or route congestion is more likely than Trojan itself to be the cause.

VLESS: Less protocol overhead, dependent on the right combination

VLESS separates authentication from the specific security transport, keeping the protocol itself deliberately minimal and commonly pairing it with TLS or another security layer. Its performance cannot be discussed independently of that transport: the same VLESS label can produce entirely different connection and resource behavior across transports and routes. Treat a VLESS entry in a subscription as a combination point, not a standalone speed guarantee.

This separation makes deployment-specific combinations easier, but it also requires the client to fully understand the subscription parameters. Updating the client or re-importing the subscription is often more reliable than copying individual fields by hand. If a connection establishes but applications receive no traffic, continue by checking routing rules, DNS, and the system network extension rather than repeatedly clicking Connect.

Hysteria2 and TUIC: UDP options for unstable links

Hysteria2 and TUIC both build on QUIC and UDP transport capabilities. Their focus is not unconditional speed, but different congestion-control and multiplexing behavior from traditional TCP when facing jitter, packet loss, and network changes. They suit environments where UDP is available, path quality fluctuates noticeably, and applications need sustained transfers. If the network restricts UDP or the device tightly limits background UDP activity, the connection may degrade or fail to establish.

Both depend heavily on client implementation quality. Congestion control, connection migration, task scheduling, and system API calls all affect the real-world experience. On mobile devices, also watch standby recovery and battery use rather than running one foreground download. A protocol may handle fluctuations well, but it cannot overcome insufficient exit capacity. When the exit is saturated at peak hours, switching to UDP changes the recovery method, not the amount of available bandwidth.

Separate cold-start speed from connection reuse

What users perceive as a fast connection includes several stages: DNS resolution, establishing the network path to the entry point, protocol authentication, the outer security handshake, system network takeover, and the application issuing a new request. A cold start goes through the full process, while a reused connection may skip some steps. Seeing the client switch to Connected does not prove that application traffic is flowing through it. Open a new page or issue a fresh request to confirm that DNS and routing have changed.

Short tests tend to favor connection reuse. If a protocol connects much faster the second time, the difference may come from DNS caching, session caching, or a system network interface that has not yet been released. For a fair comparison, use the same network, entry point, and exit, and record whether the test is a first connection or a recovery. Millisecond-level rankings are unnecessary; stability and whether the process repeatedly stalls at one stage matter more.

Resource use comes from encryption, copying, and scheduling

CPU use is not determined by the encryption algorithm alone. Copying data between the application, system network extension, and client core, increasing connection counts, growing multiplexing queues, and overly detailed logging can all add work. Memory use is also affected by buffers, concurrent connections, and cache policies. Lightweight protocols are usually easier to predict, but a client that wakes frequently or maintains many connections can still consume significant power despite a simple protocol structure.

Do not judge resources only by momentary peaks. Brief computation after opening a web page is normal; more important questions are whether the client keeps waking without active traffic, remains busy long after the screen is locked, or leaves duplicate connections after a network change. On desktops, use Task Manager or a system activity monitor. On mobile devices, compare the system battery page, background-activity records, and actual standby behavior.

Loss recovery is more than retransmission speed

Traditional TCP maintains an ordered byte stream per connection; lost data must be recovered before later content can be delivered to the application in order. QUIC uses different mechanisms for stream organization and recovery, which can reduce some cross-request waiting, but underlying bandwidth and exit load remain hard limits. When a path stays congested, every protocol must slow its sending rate or create more retransmissions.

When choosing a protocol, ask what kind of wait is causing the problem. A slow first page may involve DNS and handshakes; periodic video buffering may reflect throughput variation; choppy meeting audio may result from jitter and lost real-time packets; a download that gradually slows may indicate congestion control shrinking its window. The clearer the problem definition, the more useful the protocol comparison.

Direct: Shorter path, but more exposed to public routing changes

A direct route means the network where the device is located reaches the exit node directly. The path still crosses carriers and interconnected networks; it simply does not add a service-side relay entry point. Its advantage is a simple structure with no extra forwarding step, and when interconnection is good, both setup and sustained transfer can be direct. Its weakness is limited control over the path: carrier routing changes, inter-network congestion, and long-distance public-network fluctuations are reflected directly in the connection.

Direct routes suit cases where the current location already has a good path to the target exit. Do not judge by map distance. Observe whether sustained connections remain stable, whether the same issue appears at different times, and whether multiple protocols are affected together. A geographically closer exit may have more network hops, while a slightly farther exit with clearer interconnection may be more stable.

Relay: Use a controlled entry point to shorten unpredictable segments

A relay route first connects the device to a suitable entry point, which then forwards traffic to the exit. The goal is to replace the most variable public-network segment with a service-managed link. This can help with cross-carrier paths, distant exits, and peak-hour fluctuations, but the relay adds processing steps, so entry location, entry capacity, forwarding policy, and exit quality all matter.

A relay does not guarantee lower latency in every situation. If the device takes a detour to the entry point or the entry is congested, the extra forwarding step can add delay. Choose an entry point for the current network rather than assuming one label is always faster. H5VPN covers 120+ countries / 190+ routes; visit the global nodes page to review regions, cities, and route types before matching one to your workload.

Dedicated: Focus on intermediate-link stability and isolation

The main value of a dedicated-line topology is a more manageable intermediate path, reducing competition with ordinary public traffic on links outside your control. Labels such as IEPL describe how the route is organized; they do not mean the entire path from the device to the entry point is fixed. The local access network, wireless quality, home router, and final carrier segment still affect results.

Dedicated lines suit workloads that are sensitive to sustained stability, such as meetings, remote desktops, long file transfers, and consistent-bitrate playback. Judge whether variation converges, not whether one speed test reaches a high peak. A route with a high peak that frequently drops may be worse for real-time work than one with a modest but steady peak.

Locate the entry, exit, and target service separately

The entry point receives the device connection, the exit handles external access, and the target service has its own access policies and content regions. A Connected status only proves that the device-to-service path is established; it does not guarantee that every target service will respond normally. If several sites work but one service fails, check the target service, DNS, or exit compatibility. If all workloads pause at once, suspect the entry point, device network, or connection core.

Keep alternative paths available when choosing routes. A frequently used exit can have both direct and relay options, while work and entertainment can use different exits. The goal is not constant switching, but faster fault isolation: if the alternative works, the device's basic configuration is probably sound; if every path fails, return to system permissions, client status, and the local network.

Packet loss produces different symptoms in different workloads

After a packet is lost, reliable transport retransmits it, while real-time transport may discard content that is already outdated. On the web, a resource may wait for a long time before the page suddenly completes. Video may show the buffer running down, followed by lower quality or a pause. Meetings are more likely to show gaps in audio, frozen video, and delayed controls. Remote desktops may show input sent first, with the screen catching up later.

These symptoms cannot all be summarized as slow speed. Downloads can hide brief loss through buffering and retransmission, while real-time workloads cannot wait for stale data. To judge whether a route suits meetings, observe a continuous conversation and interactive response rather than running one large download. Conversely, a smooth web page does not prove that the route has enough capacity for sustained transfer.

Jitter is latency that varies over time

Two routes can have the same average latency, yet the one that alternates between very fast responses and noticeable pauses will feel worse. Applications add buffers to smooth playback, but larger buffers reduce real-time responsiveness. Voice and remote control cannot buffer indefinitely, so they are especially sensitive to jitter. A protocol can adjust sending and recovery behavior, but it cannot fully remove the delay caused by a suddenly growing queue underneath.

Wireless conditions can create jitter on their own. Signal contention, roaming, router queues, and uploads from other devices can destabilize the first segment between the device and the entry point. Changing the remote exit will not fix a local queue. Pause upload-heavy tasks, move closer to the access point, or use a wired connection first; then compare routes after the local segment is stable.

Peak-hour problems usually come from shared-resource contention

During peak hours, usage rises across multiple paths at once. Home access, carrier interconnection, entry points, relays, and exits can all develop queues. Short queues add latency; sustained queues cause packet loss and shrinking congestion windows, eventually reducing throughput and triggering repeated buffering. A single speed-test peak cannot describe stability over the full period, because a short task may simply avoid the congestion window.

To locate a peak-hour problem, keep the workload the same and change, in order, routes in the same region, different topologies, and nearby exits. If only one entry is affected, try another entry to the same exit. If exits in the same region all degrade, compare nearby regions. If every remote route worsens at once, check local access and the carrier path. The goal is to narrow the fault domain, not to scan every node at random.

Bandwidth, latency, and stability are not interchangeable

Bandwidth describes how much data can be transferred per unit of time; latency describes round-trip waiting; stability describes whether these metrics remain predictable. Large files depend more on bandwidth, interactive apps more on latency, and meetings and video on stability as well. Choose a route by first identifying the failure your workload can least tolerate: a slow first page, reduced video quality, broken audio, or a longer download.

If streaming quality keeps dropping automatically, read Which VPN is best for 4K streaming? Why quality falls to 480p and what testing shows. The article breaks down quality changes through bitrate, buffering, and packet loss. This page focuses on the general network layer and does not generalize one streaming service's results to every workload.

Windows and macOS: Easier to observe continuous operation

Desktop systems generally allow network extensions and client cores to keep running, making them suitable for long file transfers, meetings, and development environments. On Windows, distinguish system proxy settings from virtual-network modes: some applications read only the system proxy, while others require a virtual interface to take over traffic. On macOS, grant the network extension the required permission. Until permission is complete, the client may appear usable while system traffic still bypasses the connection.

Desktop troubleshooting can use Task Manager, Activity Monitor, and system network settings. Focus less on chasing momentary CPU numbers and more on whether usage persists while idle, duplicate connections appear after a network change, or manual reconnection is needed after sleep. For macOS installation and permissions, see macOS VPN from scratch: the complete guide to installation, permissions, and subscription import.

iOS and Android: Background freezing and network changes matter more

Mobile operating systems schedule apps according to foreground/background state, battery policies, and network conditions. After the screen turns off, a client may not continue running as it would on a desktop. When Wi-Fi switches to a cellular network, the local address and path of the existing connection change. Protocols that support connection migration may recover faster, but the outcome still depends on whether the client handles system events correctly and whether the system allows the required background work.

When assessing battery use, distinguish normal transfer from abnormal wakeups. Watching video or syncing files necessarily consumes resources for encryption and data transfer. The real warning signs are frequent activity with no workload, heat that continues after the screen is locked, and repeated retries after a network change. Update the subscription, stop verbose logging, and disable unnecessary concurrent tasks before comparing another protocol. If only one route causes persistent reconnects, reachability is more suspicious than protocol computation.

Linux: Make transparent routing and permission boundaries explicit

Linux environments vary widely; desktop distributions, servers, and containers use different network-management approaches. With a system proxy, only applications that follow proxy settings enter the connection. With a virtual interface or transparent routing, permissions, routing tables, and DNS must be correct. If only command-line tools fail after connection, check whether they read environment variables. If the whole system fails, check the default route and resolution path.

Do not write conflicting rules simultaneously through multiple network-management tools. After temporary testing, confirm that old routes and DNS settings have been restored. On devices that run for long periods, also observe recovery after sleep, network-interface reconnects, and service restarts. A healthy protocol core does not guarantee that system startup order and permissions are correct.

Multiple devices do not mean copying one configuration everywhere

H5VPN supports Windows / macOS / iOS / Android / Linux with unlimited devices. The same subscription can be used across devices, but the connection method should match each platform's capabilities. On desktops, prioritize stable long-running connections; on mobile, also watch lock-screen recovery and battery use; on Linux, define the boundary between system proxying and transparent routing. Copying complex desktop rules directly to mobile usually increases troubleshooting work.

Subscription links are account credentials. Import them only into trusted clients and keep them secure. No email address is required for registration; a username and password are enough. If you need to download a client or retrieve a subscription again, use the user panel instead of repeatedly forwarding the link through chat. Start all client downloads from the user panel.

Web browsing, research, and AI Tools

These workloads include many short requests and may also maintain streaming responses. The first load depends on DNS and the handshake, while ongoing conversations require a stable connection. Start with Shadowsocks or Trojan for their simple structure and mature compatibility, paired with a clearly routed relay or dedicated line. If TCP jitter is noticeable on the current network, compare Hysteria2 or TUIC and see whether streaming responses suffer fewer interruptions.

Do not test only whether the home page opens. Log in, issue fresh requests, keep a continuous response running for a while, and switch browser tabs before returning. If pages open but streaming responses stop frequently, check long-lived connections and route jitter. If only one tool fails while other sites work, check the exit region, DNS, and the service's own status. Change protocols only after these checks.

Video, live streaming, and large-file transfers

Sustained transfers need enough throughput and graceful recovery under congestion. When route capacity is sufficient and loss is low, several protocols may work normally. When the path fluctuates, QUIC-based options may handle changes better, provided UDP is available and the client is stable. If a direct route remains stable over time, there is no need to switch to a more complex combination simply because its label sounds more advanced.

During validation, watch continuous playback, seek behavior, and quality recovery rather than startup alone. For downloads, check whether speed stays steady, whether transfers resume after pausing, and whether other apps cause noticeable contention. Streaming access also depends on exit compatibility; a stable network layer does not mean every content library will be identical. The node page marks route types and streaming support, so review the global nodes before choosing.

Meetings, voice, and remote desktops

Real-time workloads are most affected by jitter and sustained packet loss. Start with a stable relay or dedicated route, then compare protocols. TCP-based combinations such as Trojan and VLESS can perform well on stable routes. If the local network switches often or the path has clear loss, test TUIC or Hysteria2, but verify the microphone, screen sharing, and remote input in practice rather than substituting download speed.

Before a meeting, avoid updating the client or changing rules extensively at the last minute. Keep a verified alternative route ready for a quick switch if the current path fails. If audio breaks up while video continues, real-time packets may be affected by jitter. If everything freezes together, check the local network and entry point. If only remote-desktop input lags, check the target host and application. Different symptoms point to different layers.

Short business trips and hotel networks

Hotel, coworking, and public Wi-Fi networks use different access policies. Some require web authentication, while others reauthenticate after the device sleeps. Complete the network's own authentication before starting the client. If the portal does not appear, temporarily disconnect, open an ordinary web page again to trigger it, complete authentication, and then restore the connection.

Business travel calls for recovery options and a backup path. Prepare desktop and mobile clients, import the subscription in advance, and verify access before departure. If a hotel network handles UDP poorly, switch to a suitable Shadowsocks, Trojan, or VLESS entry. If the TCP path is congested, compare relay and QUIC options. See Which VPN works for business trips? A hands-on comparison of short-term plans and hotel networks for more scenarios.

Match the plan to your usage pattern

Protocols and routes determine how you connect; plans determine available traffic. Monthly plans include ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB. Traffic resets monthly on the activation date, and mid-cycle upgrades are prorated by remaining days. Traffic packs are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB; they last until used and never expire.

Monthly billing is easier to assess for continuous video and large-file transfers, while occasional trips or low-frequency backup use can be compared with traffic packs. Base the choice on actual workloads; you do not need different device slots for different protocols. This service supports unlimited devices and offers 14-day no-questions-asked refunds. See the plans page for full rules and payment methods: Alipay / WeChat Pay / USDT.

Confirm the scope of the failure first

The first step is not to change every setting, but to identify the scope. Determine whether the issue affects one website, one app, one type of workload, or all traffic. If the browser works but a desktop app fails, suspect system proxying or application routing. If several apps fail together, check the connection core, network interface, and entry point. If only one target fails, first check the target service, exit region, and DNS.

Then determine whether the issue is tied to time, network, or device. If the same device recovers on another network, investigate the original access environment. If several devices on one network fail, the local router or upstream path may be the common factor. If only a mobile device disconnects after screen lock, check background policies. Narrowing the scope prevents every incident from being blamed on an unavailable node.

Create a reproducible test baseline

Choose a regular device, a stable access network, a known-good node, and a clearly defined workload as the baseline. Record the protocol, route type, exit region, client mode, and symptoms. Then change only one of the protocol, route, or network per round. If the issue clears, switch back and retest the original condition to confirm that the improvement was not caused by caching or a temporary fluctuation.

A short text log is enough; complex monitoring is not required. Records make different rounds comparable and help when submitting a support ticket. The example below contains no subscription credentials or real addresses:

Environment: macOS
Workload: Video meeting
Protocol: Trojan
Topology: Relay
Symptom: Connection establishes, but the ongoing call pauses intermittently
Comparison: Recovered after switching to a dedicated line with the same exit
Retest: The issue returned after switching back to the original route

Apply changes by layer

First change the protocol while keeping the same exit to assess transport compatibility. Then keep the protocol fixed and change to a route in the same region to assess the entry and path. Only afterward change the exit region to rule out exit load or target compatibility. If every combination fails, check client permissions, subscription updates, system time, DNS, the local network, and security-software rules.

For Hysteria2 and TUIC, if the connection cannot be established, first test a TCP-based protocol on the same node. If the TCP option works while the UDP option keeps failing, investigate whether UDP is available on the current network. If UDP connects but recovery is frequent after the mobile screen locks, focus on background policies and client implementation. Do not infer a server failure from the protocol label alone.

Separate connection status from service usability

A Connected status means that the tunnel or proxy session is established, but requests still pass through DNS, routing, the exit, and the target service. Issue a fresh request during testing rather than refreshing a page that still uses an old connection. Browsers may reuse existing connections, and apps may cache DNS results. Fully close and reopen the relevant app to verify more clearly whether the new route has taken over.

If a new page works but an old tab fails, the old connection may not have migrated. If the domain cannot resolve but a direct service connection works, check DNS. If only some page resources load, check packet loss, rules, and the target's distribution domains. If the connection stops only after some time, check network changes, session persistence, and background freezing. Breaking “not working” into stages makes troubleshooting much faster.

When to submit a support ticket

If the issue remains unclear after basic comparisons, open the user panel and submit a support ticket. Include the device platform, client mode, protocol, route type, exit region, access-network type, time of occurrence, and reproducible steps. Do not submit passwords, subscription links, or any access credentials. Clear comparison results are easier to diagnose than a vague report that the connection is slow.

The ticket entry is in the user panel. If the basic setup is incomplete, return to the Getting Started Guide and check installation, permissions, subscription import, and connection verification step by step. To compare routes, see the global nodes page. To review monthly plans, traffic packs, upgrade rules, and refund details, see the plans page.