This is a technical handbook to come back to: it covers everything from protocol encapsulation and route topology to packet loss, congestion, and device battery use. If you just want to set up your account, get a client, and connect, start with the Getting Started Guide. If you can connect but aren't sure whether to change protocols, regions, or route types, jump to the relevant section in this guide. The protocols discussed here are general technical comparisons; they don't mean every VPNZU route supports every protocol mentioned. Check the user panel and client for the options currently available.
The mental model
Distinguish protocols, transports, and routes
What protocol names tell you
When discussing connection quality, people often lump “protocol,” “node,” and “network” together, which can lead to changing the wrong thing during troubleshooting. A protocol mainly defines how a client and server establish a session, specify the destination address, and encapsulate data. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC can all be used for proxy connections, but they differ in handshake methods, transport mechanisms, and client support. A protocol is not a physical route: changing protocols may still send data over the same local access network and remote exit.
The transport layer describes how data moves across the network. Common foundations include TCP and UDP; mechanisms such as TLS and QUIC add encryption, session management, or multiplexing. Some protocol names refer to a fairly specific combination, while others need transport options to fully describe a connection. VLESS, in particular, doesn't tell you how a connection will behave on its own—you also need to know which transport carries it. When comparing protocols, consider these settings together instead of inferring speed from the name.
Routes determine where your data goes
A route is the actual path from your device to an entry point and then to an exit. Direct, relayed, and dedicated describe how that path is organized, not a separate set of protocols. The same protocol can perform differently depending on the region, entry point, or exit. Distance affects latency, peering between carriers can cause detours, and the exit region affects the location services see. So two connections with similar node names aren't necessarily using the same network path.
A practical way to break things down is to record, in order: your device's network, the protocol and transport selected in the client, the entry region, route type, exit region, and destination. That makes it easier to tell whether a slow page is caused by connection setup, ongoing data transfer, or the destination service itself. If the client can't establish a session with the entry point, check account status, client settings, and entry-point reachability first. If the connection comes up normally but only certain sites are slow, look at the route between the exit region and those sites.
When choosing a route, first fix the use case and exit region, then compare route types, and adjust the protocol last. Change one setting at a time so you can tell what made a difference.
A successful connection is only the starting point. When the client says it's connected, that means it completed the necessary negotiation with the selected entry point—not that every destination will respond normally. A destination may have its own regional restrictions, account rules, and service status. Browser cache, system proxy scope, and an app's own connection settings can also affect what you see. To verify a connection, check the exit details, then try the service you actually want to use and note whether only certain requests fail. Don't judge an entire route by how one page loads.
The rest of this guide follows the same model: first, how protocols handle sessions; then, how TCP and UDP behave; followed by route topology and peak-time congestion; and finally, practical use cases. Newcomers may find it helpful to read our guide to choosing a route by use case alongside this page. That article focuses on quick decisions; this guide explains the reasoning behind them so you can choose again when network conditions change.
Protocol profiles
Shadowsocks and VMess: encapsulation trade-offs
Shadowsocks: a simpler protocol stack
Shadowsocks lets a client send requests for a destination through a proxy server and encrypts data between the client and server using the configured method. Its configuration is relatively straightforward: the destination connection, authentication details, and encryption method must match the server. Use the secure settings provided by the server in modern clients. Don't switch to outdated or incompatible options just because they seem to use fewer resources. A mismatch can cause a failed handshake or request timeout—or leave you connected but unable to access anything.
A simpler protocol stack can make it easier to identify where a problem occurs, but that doesn't mean every Shadowsocks connection is lightweight. Client implementation, encryption, device hardware, and network path all affect resource use. For web browsing and everyday apps, first check whether the client can maintain a stable session, then see how the route performs for your destination. If an app opens many connections at once, how the client manages them matters too. Judging resource use or app compatibility by protocol name alone overlooks implementation differences.
VMess: session handling built into the protocol
VMess has its own conventions for establishing sessions and representing data. Deployments need the client and server to agree on transport settings as well as authentication details. That allows for more combinations, but also more troubleshooting branches: connections using the same VMess label may use different underlying transports. When comparing two VMess routes, differences in entry point, transport, and exit mean you can't attribute the experience to VMess alone.
When device resources are limited or the network changes often, pay more attention to how connections are re-established than to the protocol label. For example, switching from one access network to another may break the current session, requiring the client to reconnect and the app to retry its request. If a page just keeps loading, check whether the client has re-established its session before repeatedly changing the exit. Frequent changes can make a brief network handoff look like a configuration problem.
| What to check | Shadowsocks | VMess |
|---|---|---|
| Configuration | Check the server, authentication details, and encryption method | Also check that the selected transport settings match |
| Resource use | Depends on encryption implementation and client connection management | Depends on the session, transport combination, and client implementation |
| Common misdiagnosis | Mistaking a configuration mismatch for route congestion | Looking only at the protocol name and ignoring transport settings |
Use this table to start troubleshooting, not to rank performance. Both protocols still rely on the route to reach the destination. If a connection is smooth when idle but slow when busy, check for congestion on a shared path first. If it can't establish a session at any time, check the configuration and client compatibility. It's more useful to classify the issue as “connection fails,” “no response after connecting,” or “unstable during transfer” than to change several protocol settings at once.
Don't manually piece together client settings for a protocol the server hasn't explicitly made available. Get current subscriptions and client details from the user panel, then follow the options shown there. If your client doesn't support a setting, don't assume a similarly named option in another client behaves the same way. Protocol knowledge helps you understand your choices; it doesn't replace the connection parameters provided by the server.
Protocol profiles
Trojan and VLESS: understand the handshake and transport combination
Trojan: pay attention to the TLS session
Trojan typically organizes communication between the client and server over a TLS connection. TLS isn't just a toggle in the settings: the domain, certificate validation, and server configuration must match. If the connection fails during setup, check these first before assuming the route is congested. Skipping validation or swapping in a random domain may seem to fix the issue, but it can also change the connection's trust boundaries. Use the options provided in the server configuration.
The TLS handshake is part of connection setup, so distinguish initial connection time from transfer speed once connected. A slow first page load doesn't necessarily mean the entire transfer will be slow. Conversely, a quick handshake doesn't guarantee smooth video playback. Browsers often reuse connections, and apps make requests in different ways. For a useful comparison, keep the destination and steps consistent, and note whether the first load is slow, navigation is slow, or interruptions continue after the connection is established.
VLESS: the protocol alone doesn't define the full route
VLESS handles identity and destination details within a proxy session, but the transport must be specified separately. When you see a VLESS route, check which transport it uses, how the secure connection is established, and whether your client supports that combination. Equating VLESS with one fixed transport can send troubleshooting in the wrong direction: the protocol field may be correct while another setting is mismatched, preventing the connection. When moving a subscription between clients, verify each imported setting rather than just checking whether the route name appears in the list.
Some clients put protocol, transport, and security settings in separate menus; others show only a summary. The interface doesn't change the need for the underlying settings to match. If a route imports successfully but won't connect, check that its details are complete, then verify the system time, current network, and reachability of the destination entry point. Don't replace one transport with another just because their names look similar. Negotiation between a client and server can't be “close enough.”
For TLS-related issues, check the domain and validation settings first. For VLESS, check the protocol and its underlying transport separately. Neither can be assessed independently of the entry and exit routes.
TLS and transport implementations use processing and connection-management resources, but that doesn't mean one protocol always drains more battery on every device. Hardware acceleration, client background behavior, signal quality, and app request frequency can all change the result. On an unstable network, repeated reconnections are more likely to keep a device awake than a connection that stays up. For mobile use, it's usually more practical to find a combination that maintains a stable connection before comparing small differences in protocol overhead.
If you need to access a service with region-specific availability, the protocol only carries requests to the exit; it doesn't choose the exit for you. A service may consider exit location, account history, and its own rules. Check regions and route types on the global nodes page, then choose a protocol supported by your client. Keeping region and protocol factors separate can prevent needless switching and help distinguish a destination's response issue from a protocol failure.
Protocol profiles
Hysteria2 and TUIC: understanding changes on UDP routes in practice
Why QUIC matters
Hysteria2 and TUIC are both closely associated with QUIC over UDP. QUIC combines secure sessions with transport controls and manages connections and concurrent data streams differently from traditional TCP. So when considering these protocols, don't just ask whether there's enough bandwidth; ask whether the current network can reliably deliver UDP packets. If the local network, upstream path, or destination entry point handles UDP poorly, the protocols' design advantages may not show up in real-world connections.
UDP itself doesn't provide applications with the reliable, in-order byte stream that TCP does; QUIC handles acknowledgments and retransmissions at its own layer. So “UDP-based” doesn't mean packet loss can't happen, or that every lost packet is handled automatically and without a cost. Missing data may still need to be sent again, and changes in the route can still cause delays. The actual results depend on the protocol implementation, client, server, and network path.
Judge both implementations by the actual connection
Hysteria2 and TUIC differ in configuration and congestion-control behavior; they're not interchangeable settings with different names. For users, the priorities are to confirm that the client and server support the protocol and configuration, then check connection stability, interruptions during ongoing transfers, and recovery after switching access networks. Good performance on one network doesn't guarantee the same results on another.
When troubleshooting these connections, start by checking the client's connection status to see whether the handshake completed. If it remains stuck during setup, check whether the current network supports the UDP path reliably and compare against other routes offered by the server. If the connection comes up but transfers keep stalling, look for packet loss or congestion between the entry and exit. Keep the exit region and use case as consistent as possible during comparisons; otherwise, changing protocols also changes the geographic path, making the results hard to interpret.
| What you're seeing | Check first | Avoid this assumption |
|---|---|---|
| Connection never comes up | Client support, matching settings, UDP path | Assuming the exit doesn't have enough bandwidth |
| Intermittent stalls after connecting | Packet loss, retransmissions, and route congestion | Assuming a brief successful handshake means the connection is stable |
| Stops working after switching networks | The new access network's path and the client's reconnection status | Assuming results from the previous network still apply |
On mobile devices, switching networks also changes the address and path between the device and the entry point. An app may keep waiting on the old connection or start a new one. Give the client time to reconnect, check that the exit details have updated, then see whether the app needs to retry its request. Repeatedly toggling the connection creates more incomplete attempts and obscures the original issue. If UDP remains unstable on a particular access network, trying another connection method actually offered by the service is more practical than fixating on a protocol name.
There's no universal ranking for video, file transfers, and interactive apps based solely on the names Hysteria2 or TUIC. Video depends on sustained throughput and interruptions; interactive apps are more sensitive to response fluctuations; file transfers also depend on the server and destination's capacity. Match what you observe to the task you actually need to do, then consider the protocol—don't treat one download test as a verdict for every use case.
Devices and clients
Connection setup, resource use, and mobile battery life
Break “speed” into stages
Connection setup time, the wait for the first response from a web page, and transfer speed over an established connection are different things. The client first resolves the entry address and connects to it, then completes the protocol's handshake. Once the proxy connection is up, the destination still has to handle its own connection and request. A delay at any stage can feel like “slow loading.” If only the first visit is slow, check for frequent reconnects or a slow initial response from the destination. If an established connection remains slow, check route congestion and the destination service.
Protocol implementation affects the handshake, but round-trip time along the route matters too. A distant entry point or an unstable access network can amplify any step that waits for a response. Don't guess how long a particular connection will take based on a protocol description. Instead, use the same device, network, and similar actions while testing each connection option actually offered by the service. Note whether a failure happens before the client connects, during setup, or while the app loads; that helps separate protocol effects from geographic routing.
Battery drain often comes from repeated wakeups
Mobile battery life can't be reduced to “one protocol uses less power.” Ongoing network activity, retransmissions caused by a weak signal, frequent session restarts, and apps making constant background requests can all wake a device more often. Even if the protocol itself requires little processing, repeated interruptions along the entry route can force the client to perform the handshake again and again. In everyday use, a slightly more complex connection that stays stable for a long time may use less power than an unstable one.
To compare battery use, don't play video on one device while leaving another test device idle. Look for patterns with the same app, similar network conditions, and similar usage, keeping system background limits and power-saving settings consistent. Battery reports often group usage by app, but a proxy client also relays data for other apps; its reported consumption doesn't mean it initiated all that traffic. More useful clues include whether the connection keeps restarting while the device is idle and which apps are making frequent background requests.
| Platform | What to check first | Easy-to-miss factors |
|---|---|---|
| Windows / macOS / Linux | System proxy scope, client connection logs, recovery after sleep | Browsers and standalone apps may use different proxy settings |
| iOS / Android | Network changes, background reconnections, battery-use trends | System power-saving settings and background requests from other apps |
VPNZU supports Windows / macOS / iOS / Android / Linux, with unlimited devices. That doesn't mean every platform uses the same interface labels or offers the same protocol options. When using multiple devices, check that the subscription is up to date and that the route names and settings match in each client before comparing results. If one device works and another doesn't, check the platform's client and local network before assuming the entire exit is down. See the Getting Started Guide for client downloads and subscription setup.
On devices with limited resources, keep an eye on apps running at the same time. Loading many pages, syncing in the background, and playing video all compete for the device's processing, memory, and network resources. Close high-traffic tasks unrelated to your test and check the connection again. If it works normally, local resource contention may be the issue, not route capacity. Recording test conditions is more useful than chasing an isolated “fastest protocol,” because the real goal is handling your everyday workload.
Route structure
How direct, relayed, and dedicated routes affect stability
Direct routes: a simple path, not necessarily the shortest
A direct route generally means there are no additional relay arrangements between the entry point your device connects to and the final exit. It's easy to understand, but “direct” doesn't guarantee the actual network path is short. Data still travels through your local carrier, inter-carrier connections, and the exit network; the route it takes may not match a straight line on a map. Direct routes may be a good starting point between nearby regions with strong peering. If traffic takes a detour or congestion builds at peak times, see whether another topology offers a more stable path.
Relayed routes: add a hop to change the access path
A relayed route adds a forwarding hop between access and the final exit, usually to change the path from your device to that exit. An extra hop doesn't automatically mean slower performance: if the new entry point is easier to reach and the rest of the path is more stable, the overall experience may improve. But relaying adds another component to maintain, and congestion at any point can affect the result. To decide whether a relay helps, check connection setup and ongoing transfers across the entire path rather than counting hops.
Dedicated routes: consider how traffic is carried
An IEPL dedicated route describes how the connection is organized and carried, not an encryption protocol. Dedicated routes may use more controlled paths and capacity planning than ordinary internet routes, but the real-world experience still depends on local access, server processing, and the destination site. A “dedicated” label is no guarantee of a fixed latency, zero congestion, or performance with every destination. Decide which exit region you need, then compare the available route topologies there.
Think of a route as consecutive segments: device to entry, entry to exit, and exit to destination. Connection failures often occur on the first segment; if only one destination is slow, the final segment may be involved; if all destinations slow down around the same time, check for a shared middle segment. This model can reduce unnecessary protocol changes. Even when the client shows the same region, the entry and exit arrangements may differ, so review the route type before comparing connections.
| Route type | What to check | When to test it first |
|---|---|---|
| Direct | The network path between local access and the exit | The destination region is clear; check both connection setup and ongoing transfers |
| Relayed | Entry-point quality and intermediate forwarding hops | The current access path is unstable and you want to compare another access method |
| IEPL dedicated | The dedicated route segment and access at both ends | You need a stable path and a corresponding route is available in the target region |
The destination service's regional rules matter when choosing an exit. Streaming services may offer different content in different regions; AI tools may also handle requests based on exit location and account details. A route provides a connection; it doesn't change the destination service's own rules. First choose the region you need, then check the available routes on the global nodes list. For a quick decision-making framework, read How to Choose a VPN Route.
VPNZU covers 100+ countries and offers 160+ routes. That means there are regions and routes to choose from; it doesn't mean every region offers direct, relayed, and dedicated routes. Nor does the total number of regions guarantee performance for a particular destination. Check the node page and user panel for current route options, then test them on your own access network.
Troubleshooting
Packet loss and peak-time congestion: trace the symptoms to the route
Packet loss has more than one cause
Packets can be lost on the local wireless connection, the access path between your device and carrier, inter-carrier links, relay hops, or the route from the exit to the destination. An app sees the resulting delays and retries, but a single pause while a page loads can't tell you where the loss occurred. TCP retransmits lost data and adjusts its sending rate according to its own mechanisms. QUIC-based connections also handle acknowledgments and loss. Though the mechanisms differ, both aim to keep data flowing; retransmitting still costs time and capacity.
Distinguish packet loss from consistently high latency. A stable but long-distance route may feel slow to respond without frequent interruptions. A route with intermittent packet loss may respond normally most of the time, then suddenly stall during loading. Ongoing transfers can expose another issue: if the app has to wait for missing data, later data may not be delivered immediately even after it arrives. Video buffering can absorb some fluctuations, while real-time interactions are more sensitive to them. Test with the app you actually want to use rather than relying on a connection-status label.
Why congestion is more noticeable at peak times
Peak times are when multiple users increase network demand at once. Bottlenecks can occur on home connections, carrier links, shared relays, exits, or destination services. As a link approaches capacity, queueing delays grow; if the queues can't keep up, packets may be dropped. Switching protocols may change how a connection responds to fluctuations, but it can't add capacity to a congested physical route. If several protocols slow down in much the same way at the same time each day, compare entry points and route types first.
Narrow down the problem step by step: first, check whether common services are also slow on your local network without the proxy. Next, see whether different destinations have issues through the same entry point. Then compare other available routes to the same destination and exit region. If only one destination is affected, check whether the service itself is working normally. Keeping track of these distinctions is more useful than saying “everything is slow,” and can prevent blaming the route for an app server issue.
When comparing connections at the same time, change one variable at a time: try another route in the same region first, then consider changing the protocol. Don't change the network, region, client, and app all at once.
Read client logs in context. A handshake timeout points to the connection setup stage. Repeated disconnections after connecting warrant checking local network changes and entry-point stability. If only some webpage resources fail to load, the issue may involve requests to the destination site. Log wording isn't standardized, so different clients may describe the same issue differently. If you're unsure, note the steps that triggered the problem, the selected route name, and what happened. Don't post subscription details or authentication data publicly.
If the issue occurs on just one device, check whether its system proxy covers the app in question and whether the subscription is up to date. If multiple devices on the same access network show similar symptoms, look at the network and entry route. If results vary across access networks, compare local access conditions first. Organizing observations by device, network, region, and app is more likely to reveal a pattern than trying random routes. To report a specific issue, describe what happened through the support ticket option in the user panel.
How to choose
Choose for your use case, then verify the result
Choose a region, then a route
Start with what you need to do. For web browsing and file work, identify where the service you need is available; don't choose a distant exit just because the route name sounds appealing. For streaming, first choose the region you want and then check whether playback stays smooth. With AI tools, consider the destination service's regional and account rules too. Interactive apps make stable response times and route consistency more important. Region isn't another word for speed—it determines where your requests enter the destination service.
Once you've picked an exit, compare direct, relayed, and dedicated routes. Choose based on which one reliably gets the job done on your current access network, not on the order of the route labels. If a route opens the destination reliably and works without noticeable interruptions, there's no need to keep switching just because another topology is available. If issues occur only at certain times, record what happens during both normal and affected periods and check for congestion on a shared path instead of resetting every client setting.
Finally, compare the protocols your client actually offers
Your protocol choices depend on client support, server settings, and the current network. For TCP-based connections, check that the handshake completes and transfers remain stable. For UDP-based connections, check whether the access network can reliably carry those packets. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC can't be ranked independently of transport settings, entry points, and exits. There's no need to add protocol options the user panel doesn't offer, and don't guess at connection parameters for an existing route.
Use a consistent order when testing: check the client status and exit region, then open a service you use regularly. See whether the initial load, later interactions, and ongoing transfers each work normally. If something goes wrong, classify it as a connection setup, transfer, or destination response issue. After one round of testing, change a single setting and repeat the same steps. It may feel slower than switching through a lot of routes, but the results are more reliable and easier to reuse when network conditions change.
For subscription details, the pricing page lists the actual billing terms for monthly plans and data packs. Monthly plans are ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB; data resets monthly on the activation date, and mid-cycle upgrades are prorated for the remaining days. Data packs are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB; they don't expire and remain available until used. VPNZU supports Alipay / WeChat Pay / USDT. No email address is required to create an account—just a username and password. Plan selection and protocol selection are separate decisions: choose a billing option based on your usage, then pick a route for your needs and network.
If you use a mix of Windows / macOS / iOS / Android / Linux devices, check the routes shown in each client and confirm that they're imported correctly. VPNZU allows unlimited devices, but settings still need to be checked separately on each platform. For help getting and importing a subscription link, read the beginner's guide to subscription links. For services such as Netflix, keep regional differences in the destination service separate from your choice of exit. Our Netflix route comparison covers this in more detail.
Keep a conclusion you can revisit instead of looking for a protocol ranking that lasts forever: note your use case, exit region, route type, protocol shown in the client, network, and observed symptoms. When the route or local access conditions change, repeat the same checks. For service assurance, VPNZU offers a 60-day money-back guarantee. For technical choices, the best evidence is whether the connection reliably gets the job done on your own device and destination.