Protocols & Routes Technical Reference

Selection Guide

This page is NZVPN's technical reference on protocols and routes, aimed at users who are choosing a subscription plan or who already subscribe and want to understand the underlying principles. Unlike the step-by-step tutorial on setup.html, this page is more of a systematic reference: each chapter can be read independently, or you can jump to the topic you care about via the table of contents.

Before we begin, let's clarify two fundamental dimensions. The protocol determines how data is encapsulated, encrypted, and transmitted; the route topology determines the physical path the data takes. Together, they determine connection setup speed, transfer rate, stability, and mobile battery consumption. Many users encounter "can't connect," "slow speed," or "4K buffering" issues, and the root cause is often not the service itself, but a protocol-route combination that hasn't been optimized for the current network environment.

The protocol layer addresses "what form the data takes over the network." Traditional TCP proxies can be slowed down by handshake retransmission on weak networks, while UDP-based protocols maintain more stable transmission in high-packet-loss environments. The route layer addresses "which path the data takes." For the same Singapore node, direct, relay, or IEPL dedicated line can result in latency and stability differences of several times. Understanding these two layers is essential for making effective judgments when looking at route lists.

NZVPN's subscription service covers 120+ countries / 220+ routes and supports Windows, macOS, iOS, Android, and Linux, with no device limits. Subscriptions start at ¥9.9/month (60GB data) across three tiers, with optional data packs that never expire, and a 30-day money-back guarantee. All descriptions of the service in this article are consistent with the above facts and do not introduce any unverified data.

It should be noted that this page does not discuss any network regulation topics, nor does it provide specific node configuration commands. Protocols and routes are infrastructure already configured by the service provider; the user-side choices are limited to subscription plans and client settings. But understanding the principles helps you judge: why certain protocols are faster in certain network environments, why dedicated lines command a higher monthly fee, and which component to check when connection issues arise.

This page is organized in the order of "protocols → comparison → topology → scenarios." The first five chapters introduce the six protocols one by one, Chapter 6 provides a side-by-side comparison table, Chapter 7 discusses route topology, Chapter 8 explains the causes of packet loss and congestion, and Chapter 9 offers selection recommendations by use case. You can read it from start to finish, or jump directly to the chapter you care about most.

Shadowsocks: Lightweight Proxy Trade-Offs

Shadowsocks (SS) is one of the most widely used lightweight proxy protocols today. Its design goal is clear: establish an encrypted tunnel with the lowest possible resource overhead in unreliable network environments. SS's encryption is based on AEAD (authenticated encryption) stream ciphers, with common combinations including AES-256-GCM and ChaCha20-Poly1305. The former has hardware acceleration on mainstream CPUs, while the latter performs better on mobile ARM processors.

SS's transport layer defaults to TCP, with data encapsulated as standard SOCKS5 proxy traffic. Because it "looks like an ordinary proxy" at the protocol level, deployment is very lightweight, requiring no additional handshake or authentication overhead. During connection establishment, the client and server need only one TCP handshake plus one encryption handshake, with the entire process typically completing in tens to hundreds of milliseconds. For short-connection scenarios like web browsing and instant messaging, SS's response speed is ideal.

SS's limitations are also clear. First, its single-port multi-user capability is relatively weak: early SS could only serve one user per port, and while later implementations support multiple users, they require maintaining a user table on the server, which adds management complexity under large-scale concurrency. Second, the protocol's characteristics are relatively fixed, and some deep packet inspection (DPI) systems can identify SS traffic by analyzing traffic statistical features, although this requires certain computational resources. For ordinary users, SS remains the most "smooth" choice—mature client ecosystem, simple configuration, and low resource usage.

On mobile, SS's battery performance deserves special mention. Because SS is TCP-based, the system can enter low-power mode without needing to wake the radio module as frequently as UDP protocols do. On iOS and Android, SS's background keep-alive is relatively easy, and long-term idle use doesn't significantly increase power consumption. For users who mainly use their phones for social media and web browsing, SS is a battery-saving choice.

In practice, SS is suitable for the following scenarios: light to moderate cross-border access, long-term mobile idle use, applications sensitive to connection setup speed (such as instant messaging), and relatively stable network environments. If the network packet loss rate is high, SS's TCP retransmission mechanism will cause noticeable speed degradation, in which case the QUIC-based protocols discussed later are recommended.

In NZVPN's route list, most standard routes default to SS or SS-compatible transport. These routes are suitable for everyday use and, combined with relay topology, can remain basically stable during peak hours. If you're after more extreme speed, you can switch to other protocols in the client, or choose a plan that includes dedicated lines on the plans page.

VMess & VLESS: Evolution of a Full Protocol Framework

VMess is the core protocol of the V2Ray family, designed with more emphasis on "not looking like a known protocol" than SS. VMess introduces a UUID as the user identifier at the application layer and adds a timestamp to the request header, combined with an optional anti-replay mechanism, so the same request can't be easily replayed or identified on the network. VMess's encryption is also AEAD-based, but it encrypts metadata (such as the destination address and port) as well, unlike SS, which exposes the destination address in a plaintext header.

The cost of VMess is relatively slow connection setup. Each connection requires a "client initiates → server verifies UUID → returns response" handshake process, which can be prolonged by retransmission on weak networks. Additionally, VMess's header has a fixed prefix, a feature that can be identified by DPI systems. To mitigate this, later implementations introduced transport variants like mKCP, WebSocket, and gRPC, disguising VMess traffic as WebSocket or gRPC traffic.

VLESS is VMess's successor, and its core improvement is the removal of VMess's redundant encryption layer. VLESS itself doesn't encrypt data; it only transmits metadata, with actual encryption handled by the transport layer (such as TLS). The benefit is a significant improvement in connection setup speed—no need for an application-layer encryption handshake first; a secure channel can be established directly via TLS. VLESS retains the UUID user identifier and anti-replay capability, and adds support for newer transport features like XTLS.

In terms of resource usage, VLESS is lighter than VMess. By eliminating an application-layer encryption layer, CPU usage drops, which is especially noticeable on low-end devices or mobile. When VLESS is paired with TLS + WebSocket or gRPC transport, its traffic characteristics are nearly indistinguishable from normal HTTPS website visits, making it suitable for environments sensitive to traffic characteristics.

It's worth noting that VLESS itself doesn't encrypt data, so it must be used with TLS to be secure. NZVPN's client enables TLS encryption by default when configuring VLESS routes, so users don't need to intervene manually. VLESS also works better with CDNs: because VLESS's handshake process is concise, CDN origin-pull is less likely to disconnect due to timeouts.

From a selection perspective, VMess suits older clients with high compatibility requirements, or scenarios requiring special transports like mKCP; VLESS is better for users seeking connection speed and modern transport features. Both are deployed in NZVPN's routes, and the client automatically selects the appropriate protocol based on the route configuration, so ordinary users don't need to distinguish manually.

Trojan: Disguised as Normal HTTPS Traffic

Trojan's design philosophy differs from both SS and VMess. Its core idea is "make traffic look completely identical to ordinary HTTPS website visits." Trojan layers a custom protocol on top of a TLS tunnel: the client and server first complete a full TLS handshake, then pass the actual request through an HTTP-like header. From a network traffic perspective, a Trojan connection is nearly indistinguishable from a browser visiting an HTTPS-enabled website.

Because of this disguise, Trojan is highly effective in scenarios where "looking like ordinary access" matters. Its connection establishment process is the same as ordinary HTTPS: one TCP handshake plus one TLS handshake, after which data transmission begins. This process has one less application-layer handshake than VMess, so connection setup speed is comparable to VLESS, but slightly slower than SS (because the TLS handshake itself requires 1–2 RTTs).

Trojan's encryption relies entirely on TLS, so it has high requirements for certificate management. The server must hold a valid TLS certificate, otherwise the connection fails during the handshake. NZVPN's client has built-in certificate verification logic: when a route is configured with Trojan, certificate validation is completed automatically, and users only need to select the corresponding route during subscription import. If the certificate expires or the domain changes, the client will report a connection failure, and re-fetching the subscription link will update it.

In terms of resource usage, Trojan's overhead mainly comes from TLS encryption/decryption. Modern CPUs have hardware acceleration instructions like AES-NI, so TLS encryption/decryption CPU usage isn't high. On mobile, Trojan's battery performance is similar to VLESS, because both use TCP as the transport layer, allowing the system to enter low-power mode normally. However, it's worth noting that if network packet loss is severe, Trojan's TCP retransmission will also slow things down—a common trait of all TCP protocols.

Trojan's applicable scenarios: users who need to reliably pass through complex network environments, want traffic characteristics to be as inconspicuous as possible, and need to work with CDNs for domain-based routing. The combination of Trojan with TLS + WebSocket works well with CDNs, allowing traffic to be routed from CDN nodes back to the real server, further hiding the backend location.

In NZVPN's route system, Trojan is typically deployed on dedicated lines or high-quality relay routes. Because Trojan's disguise requires a stable TLS connection, if the route itself is poor quality, frequent TLS reconnections can actually degrade the experience. For users who want "connect and it works, no fuss," Trojan routes are a worry-free choice.

Hysteria2 & TUIC: QUIC-Based Next-Generation Protocols

Hysteria2 and TUIC are both proxy protocols based on QUIC (Quick UDP Internet Connections). QUIC is a transport-layer protocol developed by Google, using UDP underneath but incorporating TCP's reliable transmission, congestion control, and multiplexing capabilities. Compared to TCP, QUIC's biggest advantage is fast connection establishment—it merges the TLS handshake into the transport handshake, typically requiring only 1 RTT to establish an encrypted connection.

Hysteria2's unique feature is its use of a congestion control algorithm called Brutal. Traditional TCP congestion control (CUBIC, BBR, etc.) proactively reduces the sending rate when packet loss is detected, which leads to lower bandwidth utilization on lossy networks. Brutal does the opposite: it allows the user to set a target rate and then continuously sends at that rate, without backing off due to packet loss. This is highly effective on high-packet-loss, high-latency links, keeping video streams and large file downloads at stable speeds.

TUIC's design leans more toward "simplicity." It's also QUIC-based, but eliminates the server-side user table, using a UUID identifier similar to VLESS instead. TUIC's connection setup speed is comparable to Hysteria2, but its congestion control algorithm is closer to the standard QUIC default implementation, so in extreme high-packet-loss environments, its speed performance is less aggressive than Hysteria2. However, TUIC has lower resource usage and runs more smoothly on low-end devices.

Mobile battery life is the most important factor to weigh when choosing QUIC protocols. QUIC is UDP-based, and UDP on mobile networks requires more frequent radio module wake-ups to maintain NAT mappings and connection state. This means that, for the same usage duration, QUIC protocols typically consume 10%–20% more battery than TCP protocols. However, QUIC's fast reconnection capability also means faster recovery during network switches, reducing the extra power consumption caused by "reconnecting."

Hysteria2 and TUIC are suitable for the following scenarios: high-packet-loss environments on mobile networks (4G/5G), 4K streaming or video conferencing, and frequent network switching (such as on subways or high-speed rail). On links with packet loss rates above 5%, QUIC-based protocols are often 2–3 times faster than TCP protocols.

NZVPN's client fully supports Hysteria2 and TUIC. During subscription import, if you select a route that supports QUIC, the client automatically configures the corresponding port and transport parameters. It's worth noting that some older network equipment (such as certain enterprise firewalls) may block UDP traffic, in which case QUIC protocols won't work and you'll need to fall back to TCP protocols.

Connection Setup Speed & Resource Usage Side-by-Side Comparison

Putting all six protocols in one table makes their design trade-offs more intuitive. It should be noted that the data below is based on typical network environments (packet loss 1%–3%, RTT 40–80ms) and represents empirical values; actual performance will vary depending on route quality, device performance, and network congestion.

Several selection patterns can be drawn from the table. First, if your network environment is stable (home broadband, office network), TCP protocols (SS, VLESS, Trojan) are sufficient—they're battery-efficient and highly compatible. Second, if you frequently use mobile networks or your network has a high packet loss rate, QUIC-based protocols (especially Hysteria2) can significantly improve speed. Third, if you're concerned about traffic characteristics, Trojan and VLESS are the safer choices.

In terms of resource usage, SS and VLESS have the lowest CPU usage because they omit an additional encryption layer. VMess has slightly higher CPU usage due to its extra application-layer encryption. Hysteria2 and TUIC's CPU usage depends on the quality of the QUIC implementation—TUIC's code is more streamlined, giving it an advantage on low-end devices.

Connection setup speed is a metric many people overlook. Short-connection scenarios (web browsing, API calls) are highly sensitive to connection setup latency, and each additional RTT makes users perceive a "stutter." QUIC protocols merge the TLS handshake into the transport handshake, compressing connection setup to 1 RTT—a major advantage for mobile experience. VMess, on the other hand, requires an additional application-layer handshake, and on weak networks connection setup can exceed 1 second.

It's important to note that protocol comparison can't be separated from route quality. A high-quality IEPL dedicated line paired with an ordinary TCP protocol may be more stable than a low-quality relay route paired with a QUIC protocol. Protocols address "how data is transmitted," while routes address "which path data takes"—the two need to be evaluated together.

Route Topology: Direct, Relay, & Dedicated Lines

Route topology determines how many hops data travels from the user's device to the destination server and which physical path it takes. There are three common topologies: direct, relay, and dedicated line. Understanding their differences is key to judging whether a route is "worth it."

Direct

Direct means there's no intermediate forwarding server between the user's device and the target node; data reaches the node directly through public internet routing. The advantage of direct is low latency—the shortest path, with no extra hop overhead. The downside is that stability depends entirely on public route quality. During peak hours, public international egress bandwidth becomes congested, and direct routes may experience noticeable packet loss and jitter. Additionally, direct routes can take detours when crossing ISPs (e.g., mobile networks accessing a China Unicom egress), causing actual latency to be much higher than theoretical values.

Relay

Relay routes insert one or more forwarding servers between the user and the target node. These forwarding servers are typically deployed at key positions on the backbone network or international egress, optimizing routing paths and avoiding congested segments. The advantage of relay is good stability: even if a segment of the public internet is congested, relay servers can bypass it via backup routes, keeping the connection alive. The cost is increased latency—each hop adds about 5–15ms, depending on physical distance.

Relay is further divided into "standard relay" and "smart relay." Standard relay always goes through a fixed forwarding server, so the path is relatively fixed; smart relay dynamically selects the optimal path based on real-time network conditions, similar to BGP route selection. NZVPN's relay routes generally use smart routing, automatically switching to lower-latency paths during peak hours.

Dedicated Line (IEPL)

IEPL (International Ethernet Private Line) is a point-to-point dedicated line service provided by carriers, with physically exclusive bandwidth that doesn't traverse the public internet. Dedicated lines have extremely low latency (typically 20–40% lower than public direct connections) and virtually no packet loss—because the entire link is exclusive and unaffected by other users' traffic. The downside of dedicated lines is their high cost, so they're typically deployed only on a few popular nodes.

The selection logic for the three topologies can be summarized as: choose dedicated lines for extreme speed, relay for stability, and direct for low latency in good network environments. In NZVPN's route list, each route is labeled with a type tag—IEPL Dedicated, Relay, Direct. In the client, you can also filter by route type.

Among NZVPN's 220+ routes, dedicated, relay, and direct lines are deployed in proportion, covering 120+ countries. Popular regions (Hong Kong, Singapore, United States) typically offer all three topologies, so users can choose based on their use case. For example, choose dedicated lines for Netflix, relay for everyday browsing, and direct for gaming.

Causes & Solutions for Packet Loss & Peak-Hour Congestion

Packet loss is the most common performance killer in cross-border networking. Understanding its causes helps you judge whether a route is worth long-term use. Packet loss can be roughly divided into three categories: physical link degradation, router queue overflow, and routing detours.

Physical Link Degradation

Submarine and terrestrial fiber optic cables experience signal attenuation over long distances, and electrical or optical signals may produce bit errors when passing through repeaters. When the bit error rate is within the normal range, the link layer's error correction handles it without affecting upper-layer protocols. But when links age or are affected by weather, the bit error rate rises, and packets exceeding the error correction capability are dropped directly. This type of packet loss is usually persistent, manifesting as a route being unstable over the long term.

Router Queue Overflow

This is the main cause of peak-hour packet loss. Routers on the internet have buffers (queues). When traffic in a certain direction exceeds the link bandwidth, packets queue up waiting to be forwarded. If the queue is full, newly arriving packets are dropped. During peak hours, international egress bandwidth is shared by a large number of users, and the probability of queue overflow rises significantly, causing packet loss rates to jump from 0.1% during off-peak to 3%–10%.

The role of congestion control algorithms is to let the sender sense network congestion and proactively reduce the sending rate, avoiding sustained packet loss. TCP's CUBIC algorithm halves the congestion window after packet loss, which alleviates congestion but also causes throughput to plummet. The BBR algorithm dynamically adjusts speed by measuring bottleneck bandwidth and minimum RTT, maintaining higher throughput in lossy environments. QUIC uses congestion control similar to BBR by default, so it performs better in high-packet-loss environments.

Routing Detours

Routing detours aren't packet loss themselves, but they indirectly cause it. When public routing switches to a longer path due to failure or congestion, RTT increases significantly, packets stay longer in queues, and timeout retransmissions become more likely. Timeout retransmissions further exacerbate congestion, creating a vicious cycle. A core value of relay routes is avoiding detours: by using forwarding nodes on the backbone network, the path is "straightened out," reducing unnecessary hops.

User-side options for dealing with peak-hour congestion are limited, but there are still several effective strategies. First, prioritize IEPL dedicated lines—they have exclusive bandwidth and are unaffected by public congestion. Second, enable QUIC-based protocols (Hysteria2/TUIC) in the client, as they tolerate packet loss better. Third, avoid the busiest time periods (typically 8:00 PM–11:00 PM local time), or switch to less loaded nodes.

NZVPN's route list displays real-time latency and bandwidth for each route. If a route consistently shows high latency or low bandwidth during peak hours, try switching to another route in the same region. The client's built-in auto-route-selection feature also prompts you to switch when connection quality degrades.

Choosing Protocols & Routes by Use Case

Finally, let's apply the discussion of protocols and topology to specific scenarios. Different use cases prioritize different network characteristics, so selection should first satisfy your most core needs.

The recommendations in the table above aren't absolute; in practice, you also need to consider the real-time status of specific routes. For example, a direct route may be slower than a relay route during peak hours, in which case you should temporarily switch to a relay route. NZVPN's client supports filtering by protocol and route type, allowing flexible adjustments based on current network conditions.

For most users, a practical strategy is: default to VLESS + relay routes, a combination that strikes a good balance between stability and speed. If you notice a route slowing down significantly during peak hours, switch to Hysteria2 or a dedicated line. If device battery is tight, switch to Shadowsocks to save power.

Regarding subscription plans: if you frequently stream 4K or use AI tools, we recommend the 250GB or 500GB monthly tiers for more data; if you're just browsing daily, the 60GB basic tier is sufficient. Data packs suit users with fluctuating usage—they never expire after purchase and can be topped up as needed.

Finally, no matter which protocol and route you choose, the 30-day money-back guarantee provides room for trial and error. You can subscribe for a month, test different routes in your actual network environment, and then decide which plan to use long-term.