Protocol and Route Selection

Understanding the Layers: Protocol, Route, and Client

A request passes through several stages. The app selects a destination, the operating system hands the connection to the network stack, and the client uses its rules to decide whether to proxy it. The client then sends data to a server using a specified protocol. The server connects to the destination site, and its response returns to your device along the corresponding route. A delay at any stage can make a page feel slow, but the causes differ. Don't start by looking for a universally fastest protocol. First identify which layer is causing the problem and which setting can affect it.

A protocol name doesn't describe the whole transport

Protocols typically define authentication, data encapsulation, and forwarding, but they don't necessarily determine the underlying transport. A VLESS connection, for example, can use different transport and security settings; the encryption method used by Shadowsocks also affects implementation requirements. TLS is a security mechanism that provides authentication and encryption for a transport. TCP and UDP are different transport foundations, while QUIC runs over UDP and provides connection management, encryption, and reliable streams. Treating all these terms as mutually exclusive options obscures the real differences. When comparing connections, note the full combination shown in the client—not just the abbreviation in a node name.

Routes are a separate layer. They involve the entry point, backbone transit, exit point, and interconnections between network operators. The same protocol on different routes can produce very different connection and recovery behavior; changing the protocol on the same route doesn't necessarily change the physical path. The client turns subscription data into actual connections and handles rule matching, DNS, virtual network interfaces, and background operation. A client misconfiguration can make a healthy route unusable or send some apps through an unexpected exit, so don't attribute every problem to the node.

Start with observations you can reproduce

When something goes wrong, describe the app behavior as a specific event: did the connection button fail, or did the connection succeed but domain names fail to resolve? Did the page load but its images stall, or did the connection drop only after a long transfer? Then note your network, client mode, selected route, and destination service. Avoid changing rules, DNS, and nodes at the same time during troubleshooting. Even if the problem disappears, you won't know which change helped. A reproducible issue is more useful than a one-off speed test screenshot because you can compare it across routes and networks.

Keep service facts separate from technical assumptions. ZaiVPN supports 120+ countries / 220+ routes, unlimited devices, and Windows / macOS / iOS / Android / Linux. These facts don't guarantee that a particular site will always be available or that every protocol works the same way on every platform. To check exit and route details, see the route list. For billing details, see the plans page. This technical guide explains how to choose; it doesn't replace the service configuration and options actually provided in your account.

Check in this order: confirm the request reaches the client, then check whether the protocol connection is established, and finally inspect the route and destination service. A successful connection is one link in the chain, not proof that every request completed as expected.

Trade-offs in Stream-Based Protocols

Shadowsocks, VMess, Trojan, and VLESS often appear together in client lists, but they have different design boundaries. Compare the protocol, underlying transport, security layer, and client implementation separately. Stream-based connections handle common web, file, and app requests, but a protocol name doesn't guarantee fast setup or high throughput. On modern devices, encryption may not be the main bottleneck; route latency, DNS resolution, and destination response time often matter more. The comparisons below explain the differences—they aren't a fixed speed ranking.

Shadowsocks and VMess

Shadowsocks uses an encrypted proxy model in which the client and server forward traffic using matching parameters. Check the specific encryption method, server address, port, and client support. Implementations using authenticated encryption can protect data integrity, but mismatched settings will still prevent a connection. Its relatively direct structure makes it a useful starting point for understanding proxy connections. Actual resource use depends on the implementation, hardware acceleration, concurrent connections, and traffic volume; a straightforward design doesn't mean it will use the least battery on every device.

VMess includes user authentication and data encapsulation in its protocol design and can be paired with different transport methods. Some implementations and configurations require accurate system time. If the device clock is significantly off, restore automatic time synchronization before checking other settings. A user ID alone doesn't make it compatible with any server: the underlying transport, security settings, and related fields must also match. If your current setup works reliably, there's no need to migrate just because the protocol has been around longer. For a new configuration, first confirm that both your client and server still support the features you need.

Trojan and VLESS

Trojan configurations commonly rely on TLS to establish a protected transport, then handle proxy authentication and forwarding within it. That makes the certificate chain, server name, and device time important troubleshooting checks. If certificate validation fails, don't treat disabling validation as a normal fix. Check that the subscription is current, the device clock is accurate, and the connection domain is as expected. TLS can protect the relevant transport, but it can't determine whether a destination site is trustworthy or fix account permissions or an incompatible exit region.

VLESS is designed as a lightweight authentication and forwarding protocol; its name doesn't mean it provides all encryption protection on its own. Its security depends on the security layer and transport configuration used with it. If a client only shows VLESS, check which security mechanism the connection uses. It works well when both sides have clear, compatible configurations; fewer fields don't mean settings can be omitted at will. Import subscription-provided connections as supplied. Don't remove unfamiliar security parameters to make a configuration look simpler.

Compatibility matters more than how old or new a name is

When choosing an existing connection, first check whether the client reads all subscription fields correctly. Then confirm that the platform supports the same UDP forwarding, multiplexing, or transport options. A node appearing in the interface doesn't mean every field was recognized. If import shows an unknown-field warning, update the subscription and check the client's supported features rather than repeatedly retrying the same incompatible configuration. For most users, a complete, maintained configuration is easier to manage than one assembled by hand. For comparisons, keep the route and task fixed while changing the protocol combination, so route differences aren't mistaken for protocol benefits.

QUIC Protocols and Recovery on Unstable Networks

Hysteria2 and TUIC are often grouped as QUIC-based proxy solutions. QUIC runs over UDP, but that doesn't make it a simple forwarding method that ignores packet loss. QUIC handles connection security, flow control, congestion control, and reliable stream delivery. Compared with putting multiple logical requests into a single TCP byte stream, QUIC can reduce delays between separate streams caused by in-order delivery at the transport layer. Each stream still has its own delivery requirements, however, and shared bandwidth and congestion on the same route don't disappear.

When Hysteria2 may be suitable

Hysteria2 is designed with packet loss and network variability in mind, and common implementations include congestion-control options intended to use available bandwidth effectively. It may suit some unstable routes, provided UDP is reachable, the client and server are compatible, and the settings fit the actual network conditions. A bandwidth hint in the configuration doesn't reserve route capacity or make your local connection faster than its limits. Setting an overly aggressive target can increase queues and contention, making other apps less responsive. When using the defaults supplied with a subscription, don't keep raising parameters based on brief changes in download speed.

When evaluating these protocols, distinguish transport recovery from network reachability. If TCP-based connections work on the same network but QUIC connections consistently fail to establish, first consider the UDP path, local network policies, or access environment rather than assuming the entire server is down. Keep the client and destination unchanged and test on another network. If it works there, focus on the original network. If it fails on different networks too, check the subscription, certificate, and client support. This is more useful for diagnosis than repeatedly switching to exits in different countries.

TUIC: Multiple Streams and Connection Management

TUIC also uses QUIC to carry proxy connections and organizes features around stream and datagram delivery. The key distinction is between “uses UDP underneath” and “can deliver data reliably at a higher layer.” App TCP requests still require reliable delivery; app UDP traffic may use a different encapsulation path, depending on the client and server implementation. Multiple streams can isolate some delays, but they still share device processing, the wireless link, and exit capacity. If a destination service slows down, don't assume multiplexing will automatically speed things up.

Connection migration is one of QUIC's important capabilities. Whether it makes switching between Wi-Fi and cellular smoother in a particular proxy setup depends on the client, operating system background policies, address changes, and server state. The possibility of keeping a connection after a network switch doesn't mean every app session will remain valid. A destination site may recheck the exit or sign-in status, and the operating system may pause background processes. When testing mobile use, check whether the app can actually keep sending and receiving data—not just whether the client's connection icon stays lit.

Keep a working alternative

You don't have to make a permanent choice between QUIC and stream-based options. Keep a configuration that works well on a fixed network as your regular choice, and use another transport for comparison when your access environment changes. Compare whether the full task completes, recovery feels natural, and the device stays cool—not just the peak from one test. If your account subscription doesn't include Hysteria2 or TUIC, don't try to connect by changing a protocol name yourself. The server must support the protocol; changing a client label can't add that capability.

QUIC is a transport mechanism, not a speed guarantee. If UDP is restricted, test another transport for comparison. If the path is reachable but performance varies, look at congestion, settings, and device load.

Direct, Relayed, and Dedicated Route Topologies

Route types describe how a connection is organized, not which protocol it uses. Direct routing generally means the device connects to the relevant service entry point. A relay adds a forwarding node before the connection reaches its exit. A dedicated route typically means a dedicated carrier link is used for part of the journey. A service may combine these approaches—for example, local access to an entry point followed by a dedicated segment to the exit. When reading route descriptions, consider the role of each segment. “Dedicated” doesn't mean every segment between your device and the destination has the same conditions.

Direct routing: path and limits

Direct routing is relatively straightforward and avoids an explicit relay, but network operators still route data through multiple network nodes. A short distance on a map doesn't guarantee a short route; even neighboring regions may be connected through a circuitous path. Direct routing can work well when the local carrier has good interconnection with the destination entry point. Its performance is more directly affected by the access network and cross-network path. If quality varies by time of day, compare other entry points in the same region and then try a different route type. There's no need to immediately switch to a geographically more distant exit.

Relaying adds a distinct forwarding step, potentially to take advantage of a better entry point, interconnection, or backbone route. The extra segment adds processing and transmission costs, but the overall experience may still improve if it replaces a poorer public interconnection. More hops don't necessarily mean slower performance. A relay also introduces new capacity and failure boundaries: a busy entry point, a congested forwarding link, or a limited exit can all affect requests. When diagnosing an issue, distinguish difficulty establishing the entry connection from instability during an established transfer; they call for different checks.

An IEPL dedicated link doesn't cover the entire connection

IEPL generally refers to an international Ethernet private line, a dedicated carrier link between specified network endpoints. The user's local Wi-Fi, access provider, client processing, and the path from the exit to the destination service still matter. A stable dedicated segment can't compensate for a slow destination service, and replacing it may not help if local wireless interference is severe. Treat a dedicated link as one capability within the topology, not as a promise that the entire connection is unaffected by external conditions.

Entry and exit are different concepts

The entry point is where the client first connects to the service; the exit is the source network location seen by the destination site. They can be different. For content tied to a specific region, the exit matters more directly. For connection setup, the entry point and local interconnection are more relevant. Routes with the same exit city may use different entry points or transport arrangements. Use ZaiVPN's route list to review route information, then choose from the options currently available in your account. Don't infer the full path from a city name, or treat an exit-location lookup as proof of the intermediate route.

When comparing topologies, keep the exit region and task consistent. If you change the country, protocol, and route type at once, you won't know which change made a meeting run smoothly again. First compare different routes within the same region, then keep the more suitable route fixed while testing protocol compatibility. For streaming, check the region, account, and platform policies together. For work, exit consistency and long-connection recovery matter more. Changing exits can prompt an app to sign in again or run a security check. Once you've chosen a suitable route, avoid frequent changes without a clear reason so your observations remain consistent.

Connection Setup and Resource Use

“Loads quickly” and “downloads quickly” measure different things. Loading a page involves domain lookup, connection handshakes, authentication, security negotiation, and the destination's response, in sequence or partly in parallel. A sustained download depends more on available route bandwidth, congestion control, and receiver processing. A protocol may feel responsive when reusing an existing connection but take noticeably longer to start from scratch. Another may establish quickly but be limited during a sustained transfer. Evaluate connection performance by task stage; a single result can't sum up the whole experience.

Cold connections, reuse, and recovery

A cold connection is a first request made before a usable channel has been established. It may require a domain lookup, a new underlying connection, and protocol authentication. Reusing an existing connection can skip some of that setup, so repeatedly refreshing a page doesn't represent the first-load experience. Test the first client launch, a visit after idle time, and a visit during continuous use separately. Don't repeatedly clear all app data just to simulate a cold connection; that also changes sign-in state, cache, and destination behavior. Simply record the test conditions so different configurations start from similar conditions.

Connection reuse reduces the cost of setting up connections repeatedly, but it also means requests share some state and resources. If the underlying connection is impaired, recovery may affect several active tasks. Whether reuse helps depends on the protocol implementation, app request patterns, and network quality; it doesn't always make things faster. Keeping the default settings reduces variables. If you do adjust them, check whether page loads, file transfers, and interactive requests all benefit. If a download improves but chat or meeting responses get worse, the optimization doesn't match how you actually use the connection.

Encryption, encapsulation, and device load

Client processing includes encryption, encapsulation, rule lookups, DNS, interface forwarding, and log writing. Hardware acceleration can change how different encryption methods perform on a device; implementation quality and thread scheduling may matter more than the protocol structure itself. High-throughput tasks keep the processor busy, while occasional requests may mainly incur wake-up costs. Don't apply desktop test results directly to mobile devices, or infer fixed memory or processor rankings from a protocol name. Look for trends on the same device under similar tasks.

Operating mode also affects resource use. System proxy mode typically handles apps that follow the relevant proxy settings. Virtual network interface mode can handle more system traffic, while adding forwarding and DNS work. Broader traffic capture isn't a free feature, and it doesn't mean every app needs a remote route. Clear rules can keep requests that don't need a proxy on the local path, avoiding unnecessary forwarding. Before changing settings, check what the rules do. Otherwise, local network services that should be accessed directly may be sent through a remote route, disrupting device discovery or local connections.

Use logs to pinpoint the problem

To observe resource use, first pause unrelated syncs, updates, and ongoing downloads. Check that the device isn't thermally throttling or in a power-saving state. Troubleshooting logs can distinguish DNS errors, handshake failures, and remote resets, but keeping verbose logs enabled for a long time adds write activity and may expose connection details. Once you've captured enough to reproduce the issue, return to the usual log level. Remove subscription data and account identifiers before sharing logs. Focus resource checks on the problem at hand: if pages work normally, a brief processor spike alone doesn't show that a protocol is unsuitable.

Evaluate connection setup time, sustained throughput, and resource use separately. First decide which stage you want to improve, then use the relevant test rather than treating download results as a measure of responsiveness.

Packet Loss, Queues, and Peak-Time Congestion

Packet loss means data doesn't arrive as expected. It can result from wireless interference, device queue overflow, link errors, or route congestion. Higher latency can come from propagation distance, queuing, or retransmission delays; the two are related but not the same. A link with no obvious packet loss can still feel sluggish if queues are long. A few lost probe packets don't necessarily mean app data is affected in the same way. Diagnose issues using both app behavior and network measurements. A red warning from one tool doesn't prove the route is unusable.

How retransmissions affect the experience

When reliable transport detects missing data, it must retransmit it and maintain the correct delivery order. If a web resource is waiting for missing data, that can hold up the rest of the page. During a sustained download, you may see the speed fall and then recover. Voice and real-time interaction depend on data arriving on time; data that arrives too late may no longer be useful even if delivery is complete. The same network conditions affect apps differently: a completed download doesn't mean a meeting went well, and smooth video playback thanks to buffering doesn't prove interactive requests weren't delayed by queues.

QUIC can reduce some delays between streams, and TCP connections have their own congestion control and recovery strategies, but neither can remove underlying capacity limits. Transport mechanisms determine how problems are detected, how sending rates are adjusted, and how data is recovered—not the physical conditions of every route. If the local wireless link is unstable, changing the remote protocol may only change how the problem looks. First move closer to the access point, pause competing transfers, or switch networks to see if the problem persists. Stabilizing local conditions makes protocol comparisons more meaningful.

Peak-time congestion isn't always remote

Peak hours mean shared resources face more demand at certain times. Congestion can occur on a home connection, at a carrier interconnection, at a relay entry point, or at the destination service. Queues make requests wait, and senders may reduce their rates in response. If all routes worsen on the same access network but improve after switching networks, check the local or access segment first. If one route type slows down while others work normally, compare the entry point and transport arrangement. A problem happening at night alone doesn't identify which server-side segment is congested.

Bufferbloat is another reason a connection may seem slow even when the remote end isn't the problem. Heavy uploads or downloads can fill queues in the access device, forcing small interactive requests to wait. Pausing sync may immediately restore web and meeting responsiveness. Check uploads as well as downloads: backups, photo sync, and other background transfers aren't always obvious. If your router supports suitable queue management, configure it according to its documentation. If you're unfamiliar with those features, first test by pausing competing tasks rather than changing complex network settings.

Interpret route probes with care

Intermediate nodes on a probed path may limit or deprioritize responses to diagnostic packets. A hop that doesn't respond doesn't necessarily mean that later app traffic is being dropped. The probe target may also use a different network from the service you actually need, so one measurement can't represent every app. Better notes include the time, task, access network, route name, and results on alternative routes. For remote work, distinguish choppy audio, frozen video, and delays submitting documents. For more, see our remote work route comparison.

If you need to contact support, describe steps that reliably reproduce the issue rather than just saying “it's slow.” Explain what works normally, when the problem occurs, and whether switching networks or routes fixes it. Don't share your full subscription or account password. Similar symptoms can have different causes; focused notes help support avoid trying unrelated settings. The goal is to identify the affected part of the connection and keep a working alternative—not to label every problem “peak-time congestion.”

Mobile Background Activity and Battery Use

Mobile battery use depends on the protocol, client, operating system, and wireless connection. A proxy app running doesn't necessarily consume a lot of processing resources all the time. Frequent wake-ups, rebuilding short-lived connections, network switches, and background sync can use more power. To compare protocols, keep the device, access network, and task consistent. Don't attribute differences in screen brightness, signal strength, or app workload to the protocol. The system battery screen gives clues about overall usage; it isn't a standalone test of protocol power use.

Background operation and data transfer are different issues

Android background management varies by operating system and device manufacturer. If an app is suspended in the background, its interface may still show the previous state even though forwarding has stopped. Check VPN permission, background activity access, and battery optimization before deciding the route has failed. If you need to change settings, check only the relevant options for your client; don't disable the device's entire power management system. Lock the screen, then return to the app and check whether real requests still complete. This better reflects everyday use than testing only while the app stays open.

iOS manages network extensions and background tasks differently, so Android background-running tips don't directly apply. Check the system VPN status, network extension status, and destination app session separately. If there's a brief delay after resuming, first check whether the network changed, the extension restarted, or the app had to reconnect. ZaiVPN's client download links are available from the account downloads page, with the iOS option shown according to your account plan. Getting the app and configuring a subscription are separate steps. After downloading, import the details provided in your account.

The cost of keeping connections alive and waking the radio

Keepalives help maintain a connection or detect a disconnection, but sending them more often doesn't necessarily make a connection more stable. Mobile radios consume power as they move between active and sleep states. Overly frequent keepalives can prevent a device from reaching a lower-power state; overly infrequent ones may allow some network mappings to expire and make recovery take longer. The right settings depend on the access network and implementation. For everyday use, prefer the supplied configuration rather than copying keepalive values from another device. If problems occur only after a long idle period, record the recovery behavior separately before changing all protocol settings.

A QUIC-based option may reduce some recovery work through connection management, or may use more battery depending on its sending strategy, data processing, and network conditions. Stream-based options are also affected by the number of connections, reuse, and background retries. There is no fixed battery-saving ranking that applies to every device and situation. Instead, check whether the device stays warm during the same task, reconnects repeatedly while idle, or transfers substantial data in the background. If reducing concurrent tasks or pausing sync helps, address the workload first rather than assuming the protocol is the only cause.

Test with a realistic mobile workflow

Mobile testing should include foreground use, switching to the background, locking and resuming, and changing networks—not just downloading continuously from a fixed location. Change one setting at a time and have the destination app perform the same task. With per-app proxy rules, confirm that both the app and its dependent requests use the expected route. Some sign-in or content requests come from separate components, so incomplete rule coverage can make only part of a page work. For Android, see the Android setup and verification guide. For client selection and background behavior, see Android VPN considerations.

If a setup is unstable on a mobile network but works over Wi-Fi, first record signal conditions and when the network changes. Keep the working transport as a comparison. Unlimited devices is a ZaiVPN service feature, but multiple devices can still compete for bandwidth on the same access network. Other devices syncing or downloading on a shared network can affect your connection too. Track the device, network, and task separately to see whether the difference comes from protocol compatibility, background policies, or shared resources.

Choose and Test by Use Case

Start with the task, choose a route, then confirm the protocol and client combination. Are you aiming for uninterrupted meeting interaction, video buffering, a long-lived AI chat connection, or background file sync? Different tasks have different priorities. The same user can choose different configurations for a work computer and a mobile device; there's no need to sacrifice fit for matching names. The protocols and routes available in your account determine your choices. This general comparison doesn't replace the server configuration provided by the service, and we don't recommend assembling connection settings that weren't supplied.

Meetings, Collaboration, and AI Chat

For meetings, focus on continuous audio, video that keeps updating, and recovery after brief network changes. First choose an exit and route suited to your local network, then pause background uploads for comparison. Keep a familiar, compatible protocol rather than switching frequently to chase a one-off download peak. Online documents, code repositories, and meetings are all work tasks, but they combine long-lived connections, file transfers, and interactive requests differently. Test the actual workflow—opening, editing, submitting, and recovering—not just the service homepage.

AI tools often stream responses over a persistent connection, so check whether the output completes naturally, not just whether the sign-in page opens. If a response stops, first check whether the service reports a quota, permission, or session issue, then see whether the client reconnected. A change of network exit can prompt the service to verify your session again; don't attribute every such message to the protocol. Keeping the same exit during a session helps reduce unrelated variables. ZaiVPN's “quantum encryption” marketing language isn't a substitute for checking the specific protocol and security layer, and doesn't show that any given configuration uses a particular post-quantum algorithm.

Streaming and Sustained Transfers

For video, check content availability by region, playback permissions, and sustained transfer separately. A page opening doesn't mean the desired catalog is available, and seeing the catalog doesn't mean the current route can sustain the selected quality. First check the account, content, and exit region, then watch for repeated buffering during playback. Streaming platforms change their policies, so no route type should be described as permanently available. For related guidance, see streaming access information and our Netflix regional catalog comparison. During sustained downloads, also monitor how other apps respond so one transfer doesn't fill the access queue.

Choose a plan separately from a protocol

Your protocol doesn't determine which data plan to choose; base billing on your tasks and usage patterns. ZaiVPN 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 for the remaining days. Data add-ons are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB; they don't expire and remain available until used. See plans and data add-ons for details. Avoid large repeated transfers just to test protocols; completing your actual tasks is usually a better way to assess fit.

Create an account without an email address; a username and password are all you need. Payment methods include Alipay / WeChat Pay / USDT, and the refund policy offers a 30-day money-back guarantee. Before you start, note your regular route, an alternative route, and the tasks you'll use to verify them. If a problem occurs, reproduce it first, then check each layer in order. If you can't identify the cause, submit your network environment, symptoms, and comparison results through an account support ticket. Keep your password and full subscription within your account; don't share them as public troubleshooting information.

Choose a setup that completes your tasks consistently, recovers predictably, and keeps device load within acceptable limits. Keep the environment fixed while changing one variable at a time. Test the real task before drawing technical conclusions.