Protocol & Route Technology Reference

Understanding Protocols & Routes: The Two Layers of a Connection

When you click "Connect" in your client, two independent things actually happen: first, your device uses a protocol to encapsulate and encrypt data so it can travel safely over public networks; second, that encrypted data follows a specific route path from your device through intermediate nodes to the destination server. Protocol and route are two orthogonal dimensions — the same protocol can run on different routes, and the same route can carry different protocols.

Many users only care about whether they can connect, but advanced users will find that understanding these two layers helps resolve most vague questions: "Why is it still slow after switching routes?" "Why does this protocol drain my phone battery so fast?" "Why does it keep dropping during peak hours?" The answers to these questions lie in the interaction between protocol and route.

Protocol Layer: How Data Is Encapsulated and Transmitted

The core problem proxy protocols solve is how to transmit data securely and discreetly over public networks. Different protocols use different encryption algorithms, handshake flows, and obfuscation strategies. Some protocols prioritize extreme lightweight design (like Shadowsocks), some excel at disguising traffic as ordinary HTTPS (like Trojan), and others leverage modern transport protocol features to combat network jitter (like Hysteria2).

Protocol choice affects three key metrics: connection establishment speed, transmission throughput, and resource usage. Connection establishment speed determines how quickly you can start browsing after clicking connect; transmission throughput sets the ceiling for high-traffic scenarios like streaming and file downloads; resource usage affects CPU and memory consumption, which on mobile devices directly translates to battery drain.

Route Layer: Which Path the Data Takes

The route determines the physical path data takes from you to the destination server. A direct route connects you directly to servers in the target region — shortest path but vulnerable to international gateway congestion. A relay route passes through an intermediate node to "detour" for you — slightly higher latency but more stable. A dedicated line is a carrier-grade high-quality link leased or self-built by the provider, with guaranteed latency and stability.

VPNXE offers coverage of 120+ countries / 190+ routes, with different topology types across routes. Understanding route topology helps you judge: why are some routes fast during the day but laggy at night? Why are dedicated lines worth the higher price? Why is the saying "the more nodes, the better" not entirely correct?

The following sections dive into the protocol and route dimensions separately, and finally provide scenario-based selection recommendations. You can read sequentially or jump directly to the section you're interested in. Each route has its type labeled on the Nodes page; after reading this, you'll understand the meaning behind those labels.

Design Trade-offs of Mainstream Proxy Protocols

There are six mainstream proxy protocols today: Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC. Each has different priorities, and understanding these differences is the prerequisite for making a choice. Let's go through them one by one.

Shadowsocks: Lightweight and Widely Supported

Shadowsocks is one of the most classic proxy protocols, designed to provide a lightweight, low-latency encrypted tunnel in firewall environments. It uses the SOCKS5 proxy mode with simple encryption (typically AES-256-GCM or ChaCha20-Poly1305), short handshake flow, fast connection establishment, and low CPU usage. Its ecosystem is extremely mature — almost all clients support it natively, and its configuration format is the simplest. The downside is that its encrypted traffic has distinctive characteristics, making it easier to identify in deep packet inspection environments.

VMess: The Core Protocol of V2Ray

VMess is a protocol introduced by the V2Ray project, designed to solve the problem of Shadowsocks' distinctive traffic characteristics. It introduces UUID as an identity identifier, generates a random request ID for each connection, and combines with AEAD encryption to make traffic features harder to identify. VMess also supports multiplexing, allowing multiple requests to be transmitted concurrently over a single TCP connection, reducing handshake overhead. The cost is a more complex protocol header, slightly slower connection establishment than Shadowsocks, and somewhat higher CPU usage.

Trojan: Disguised as HTTPS Traffic

Trojan's core idea is to "disguise itself as normal HTTPS traffic." It directly uses the TLS protocol as its outer layer, so communication between server and client looks like an ordinary HTTPS website, making it extremely difficult to identify in deep packet inspection. Trojan doesn't need an additional encryption layer (since TLS already encrypts), so its overhead is lower than VMess and connection speed is faster. Its configuration is relatively simple — just a domain and a certificate — making it a preferred choice in many scenarios where both stealth and performance matter.

VLESS: VMess Without the Redundancy

VLESS is an improved version of VMess, with the core change being the removal of VMess's redundant encryption layer. VMess itself uses AEAD to encrypt the request body, but VLESS argues that when TLS encryption is already in place at the outer layer, this additional encryption is redundant — it only adds CPU overhead and connection latency. VLESS is therefore lighter than VMess, establishes connections faster, while retaining VMess's anti-identification capability. VLESS is typically paired with XTLS, which can pass through raw traffic directly after the TLS handshake, further reducing overhead.

Hysteria2: QUIC-Based Anti-Packet-Loss Design

Hysteria2 is based on the QUIC protocol, which runs on top of UDP and has built-in congestion control and connection migration capabilities. Hysteria2's killer feature is its congestion control algorithm — it assumes the network is "best-effort" and aggressively fills available bandwidth. Therefore, in networks with high packet loss (like international gateways during peak hours), Hysteria2 often outperforms TCP-based protocols. The trade-off is that it may over-consume bandwidth when network conditions are good, and UDP traffic may be restricted in some networks.

TUIC: A Lightweight QUIC Protocol

TUIC is also based on QUIC, but its design philosophy differs from Hysteria2. It pursues "minimal overhead," adding only a thin proxy layer on top of QUIC without Hysteria2's aggressive congestion control. TUIC is particularly well-suited for mobile scenarios: QUIC's connection migration feature keeps connections alive when switching between Wi-Fi and cellular networks, and UDP transport reduces reliance on the TCP stack, helping lower battery consumption.

From this table, you can see that there's no "best" protocol — only the one "most suitable for current network conditions." In low-packet-loss network environments, TCP-based protocols (Trojan, VLESS) are often faster; in high-packet-loss environments, QUIC-based protocols (Hysteria2, TUIC) have the advantage.

Connection Establishment Speed & Resource Usage Comparison

"Waiting a few seconds after clicking connect" is one of the most common user complaints. This wait time consists of two parts: protocol handshake time and route connection time. Understanding the factors that influence each helps you determine which layer the problem is in.

Protocol Handshake: From Click to Tunnel Establishment

The protocol handshake process generally goes like this: the client sends a connection request, the server verifies identity, both parties negotiate encryption parameters, and the tunnel is established. Different protocols have different numbers of round trips in this phase.

• Shadowsocks: The handshake requires only one round trip — the client directly sends an encrypted SOCKS5 request, and the server decrypts and responds immediately. This is the fastest handshake.
• Trojan / VLESS: Requires a TLS handshake, typically 1–2 round trips (1 round trip for TLS 1.3). Plus identity verification, totaling about 2 round trips.
• VMess: Has its own handshake layer on top of TLS (if not using TLS), requiring additional round trips to exchange request IDs and encryption parameters. Total round trips are about 3.
• Hysteria2 / TUIC: Based on QUIC, whose handshake is 1 round trip (0-RTT or 1-RTT), plus the protocol's own authentication, totaling about 2 round trips.

In real network environments, each round trip takes about 20–80ms (depending on route latency). So Shadowsocks' handshake might complete within 50ms, while VMess might need 150ms or more. This difference is almost imperceptible to the naked eye, but in scenarios with frequent reconnections (like mobile devices switching between Wi-Fi and cellular), it accumulates noticeably.

Transmission Throughput: The Ceiling for High-Traffic Scenarios

Throughput is affected by both the protocol's transmission efficiency and network conditions. TCP-based protocols are limited by TCP's congestion control algorithm, and throughput drops sharply when packet loss exceeds 1%. QUIC-based protocols have more aggressive built-in congestion control, maintaining higher throughput in environments with higher packet loss.

In practice, the route's bandwidth ceiling also plays a decisive role. VPNXE's plans are billed by traffic and don't limit the bandwidth ceiling of a single connection; but different routes have different actual bandwidth capabilities, and dedicated lines typically provide more stable high bandwidth. If you need high-volume transfers, check the traffic quotas of different tiers on the Plans page and choose the one that fits your usage habits.

Resource Usage: CPU & Memory

Encryption and decryption are the main sources of CPU usage. AES-256-GCM and ChaCha20-Poly1305 are both efficient AEAD encryption algorithms with hardware acceleration on modern processors (Intel AES-NI, ARMv8 Crypto Extensions), so CPU usage is usually not the bottleneck. But on older or low-power devices, encryption overhead is amplified.

In terms of memory usage, each connection allocates a certain buffer. The more complex the protocol header, the higher the per-connection memory usage. Because VMess has a more complex protocol header, its per-connection memory usage is about 20–30% higher than Shadowsocks. In scenarios with many simultaneous connections (like a browser with dozens of tabs open), this difference accumulates.

Mobile Battery Performance: How Protocols Affect Battery Life

Mobile device users are especially sensitive to battery life — on the same phone, the battery difference after enabling a proxy can be as high as 20–30%. This difference comes from three layers: encryption computation power, network transmission power, and connection keep-alive strategy.

Power Consumption of Encryption Computation

Every data transmission requires encryption and decryption. On mobile devices, this computation is done by the CPU or a dedicated encryption unit. AES-256-GCM has extremely low power consumption on chips with hardware acceleration (supported by almost all modern phone SoCs), but ChaCha20-Poly1305 consumes more power on older chips without hardware acceleration.

More critical is the complexity of the protocol header. The more complex the header, the more bytes need to be computed, and the higher the power consumption. Because VMess has a complex header structure, its encryption computation power consumption on mobile is about 15–20% higher than Shadowsocks.

Power Consumption of Network Transmission

The mobile radio module (RF) is one of the most power-hungry components in a phone, and its power consumption is proportional to transmission time. TCP-based protocols trigger retransmission on packet loss, extending transmission time and thus increasing RF module working time. QUIC-based protocols (TUIC, Hysteria2) recover faster on packet loss, reducing ineffective transmissions, so they may actually be more power-efficient in weak network environments.

Another easily overlooked factor is connection migration. The QUIC protocol supports connection migration — when you switch between Wi-Fi and cellular, the connection doesn't drop and doesn't need to re-handshake. This means your phone doesn't go through a high-power "re-establishing tunnel" process every time you switch networks. TUIC excels in this regard.

Connection Keep-Alive Strategy

Many clients keep connections alive by default to maintain low latency, but this means the connection stays active even when there's no data transmission. Idle connections on mobile devices consume a small but continuous amount of power. If the client supports "on-demand connection" (only establishing the tunnel when apps need it), battery consumption can be significantly reduced.

Mobile Battery-Saving Practices

Besides protocol selection, several client settings can directly affect battery consumption. First, turn off unnecessary background connections — many apps keep connections alive to receive push notifications, but most don't need it. Second, choose "on-demand connection" mode so the tunnel is only established when apps send requests. Third, when Wi-Fi signal is stable, prioritize Wi-Fi over cellular — Wi-Fi consumes much less power than cellular.

VPNXE's client is optimized for mobile battery saving: it uses TUIC or Shadowsocks by default (depending on network conditions) and supports on-demand connection mode. You can adjust based on your device's actual situation. If you're on iOS, you can also refer to the iOS VPN Setup Guide for specific client configuration steps.

Route Topology: Direct, Relay, and Dedicated

Route topology determines which nodes data passes through from your device to the destination server. Understanding topology types helps you explain many network experience differences and guides you in choosing more suitable routes.

Direct Route: Shortest Path, but Affected by International Gateways

A direct route means your data goes directly through the international gateway to the destination server, without passing through any intermediate relay nodes. This route has the shortest path and theoretically the lowest latency, but is most affected by international gateway bandwidth and congestion. The international gateway from China to overseas typically experiences noticeable congestion during peak evening hours (Beijing time 20:00–24:00), causing latency spikes and increased packet loss on direct routes.

Direct routes suit scenarios that are latency-sensitive and have good network conditions, like short web browsing sessions and online document collaboration. But during peak evening hours, the stability of direct routes drops significantly.

Relay Route: Detouring for Stability

A relay route inserts one or more intermediate nodes between you and the destination server. The intermediate node's role isn't simply "detouring" — it helps you avoid congested paths. For example, a direct route from China to the US might be severely congested during peak hours, but if you first connect to a relay node in Hong Kong and then go from Hong Kong to the US, the path is longer but each segment has better quality.

Relay routes typically have 10–30ms higher latency than direct routes, but significantly better stability. The trade-off is increased maintenance costs for relay nodes, so relay routes are usually priced higher than direct routes.

Dedicated Route: Carrier-Grade Quality

Dedicated routes are carrier-grade links leased or self-built by the service provider. Compared to public relay, dedicated lines have independent bandwidth quotas, lower packet loss, and more stable latency. Dedicated routes typically use IEPL (International Ethernet Private Line) technology, providing quality close to local networks.

Dedicated routes typically have the lowest latency and highest stability, but also the highest cost. In VPNXE's plans, higher-tier plans offer more dedicated route options; lower-tier plans mainly feature direct and relay routes.

How to Determine the Topology of the Current Route

On VPNXE's Nodes page, you can view the type label for each route. The client also shows the topology information of the current route. If you find a route unstable during certain periods, try switching to another route in the same region — even in the same region, topology types may differ.

Causes of Packet Loss and Peak-Hour Congestion

"Why is it fine during the day but lags at night?" This is a problem almost every network user has encountered. Peak-hour congestion isn't a specific provider's issue — it's a common phenomenon of global internet infrastructure. Understanding its causes helps you make more rational route choices.

What Is Packet Loss

Packet loss refers to the phenomenon where data packets are lost during network transmission. When network devices (routers, switches) have their buffers full, newly arriving packets are dropped. Packet loss rate is one of the core metrics for measuring network quality: when packet loss exceeds 1%, TCP throughput drops sharply because TCP enters congestion control mode, reducing send rate and retransmitting lost packets.

Packet loss affects user experience in multiple ways. Slower page loading, video buffering, and gaming latency spikes are all typical manifestations of packet loss. In networks with high packet loss, even with high bandwidth, the actual user experience won't be good.

Why Peak Hours Cause Congestion

Peak hours (Beijing time 19:00–24:00) are the period with the most concentrated global internet traffic. User behavior during this period is highly homogeneous: after getting off work, people watch videos, play games, and browse social media. This concentrated traffic fills up international gateway bandwidth, especially on popular routes like China–US and China–Europe.

International gateway bandwidth is a limited resource, and carriers allocate bandwidth according to policy during peak hours. When actual traffic exceeds designed capacity, routers start dropping packets, congestion control mechanisms are triggered, and what users perceive is "slowness" and "instability."

How Protocols Handle Packet Loss

TCP-based protocols (Shadowsocks, VMess, Trojan, VLESS) strictly follow TCP's congestion control algorithm. When packet loss is detected, TCP immediately reduces the send rate and then slowly recovers. This mechanism performs well at low packet loss rates, but causes throughput to plummet at high packet loss rates.

QUIC-based protocols (Hysteria2, TUIC) adopt a more aggressive strategy. Hysteria2's congestion control algorithm assumes the network is "best-effort" — it doesn't drastically reduce the send rate for a few lost packets, but instead maintains throughput by continuously probing available bandwidth. This allows Hysteria2 to maintain good throughput even in networks with 3–5% packet loss.

What Users Can Do

Facing peak-hour congestion, users have several practical strategies. First, switch routes — different routes in the same region may take different physical paths, with vastly different congestion levels. Second, switch protocols — if your client supports it, try switching to Hysteria2 or TUIC during peak hours. Third, adjust usage time — if you're latency-sensitive (like video conferencing), avoid peak hours.

VPNXE's client has a built-in smart route selection feature that automatically detects real-time quality of each route and recommends the best one. You can enable this feature in the client to automatically handle peak-hour congestion.

How to Choose a Protocol by Use Case

There's no "best" protocol — only the one "most suitable for the current scenario." Below are selection recommendations by common use case.

A Practical Decision-Making Process for Selection

If you're not sure which protocol to choose, follow this process for a quick decision:

1. First, check network conditions: If your network has high packet loss (e.g., during peak hours), prioritize Hysteria2 or TUIC; if network quality is good, any protocol works.
2. Next, check device type: On mobile, prioritize TUIC or Shadowsocks (battery-efficient); on desktop, protocol choice is less sensitive, so you can choose by scenario.
3. Finally, check use case: For gaming and real-time communication, prioritize low-latency protocols (Shadowsocks, VLESS); for streaming and large files, prioritize high-throughput protocols (Hysteria2).

Combining Protocols and Routes

Protocol and route are not independent. A common misconception is that "choosing a dedicated route guarantees low latency," but in reality, if the protocol itself performs poorly in high-packet-loss environments, even the best route may be wasted. Conversely, if a direct route is of good enough quality, pairing it with a lightweight protocol (like Shadowsocks) can also deliver an excellent experience.

VPNXE's client allows you to specify a protocol for each route individually. This means you can try different protocols on the same route to find the combination that best suits your current network conditions. If you're not sure how to configure it, let the client's smart route selection feature decide for you.

VPNXE's Smart Route Selection

VPNXE's client has built-in smart route selection logic that automatically chooses protocol and route based on current network conditions. Specifically, the client periodically measures latency and packet loss for each route, then selects the route with the lowest latency and packet loss. You don't need to intervene manually — the client continuously optimizes.

If you have a preference for a specific protocol, you can also specify it manually in the client settings. The client supports specifying a protocol for each route individually, so you can use different protocols in different scenarios.

Subscription & Clients: How Configuration Takes Effect

After you purchase a plan, you'll get a subscription link in your user panel. This link contains your account information and route list; the client parses it to obtain all configuration.

What's in a Subscription Link

A subscription link is essentially an encrypted configuration file containing: your account identifier, a list of all available routes, each route's protocol type, server address, port, encryption method, and traffic and expiration information. The client re-fetches this data every time it refreshes the subscription, so any configuration changes you make in the provider's backend sync to the client.

For example, with VPNXE, you can find your dedicated subscription link on the "Subscription" page in your user panel. Copy it into the "Subscription" field in your client, and the client will automatically parse and load the route list.

How Clients Parse Subscriptions

Different clients parse subscriptions slightly differently, but the basic flow is the same: the client sends an HTTPS request to the subscription link → the server returns an encrypted configuration file → the client decrypts and parses it → generates the route list. The whole process takes just a few seconds.

VPNXE supports multiple clients, including Windows, macOS, iOS, Android, and Linux. You can get the client for your platform from the Download Center. iOS users should note that some clients need to be obtained through the App Store (depending on your region).

Common Configuration File Formats

Subscription files typically use URI format, with each line representing a route. A typical route URI looks like this:

vmess://eyJ2IjoiMiIsInBzIjoi5Li65Y2M5pe76ZWcIiwiYWRkIjoiZXhhbXBsZS5jb20iLCJwb3J0IjoiNDQzIiwiaWQiOiJ5b3VyLXV1aWQiLCJuZXQiOiJ0Y3AifQ==

This URI is Base64-encoded JSON, which when decoded contains the route's server address, port, user ID, and other information. Different protocols have different URI prefixes: Shadowsocks is ss://, VMess is vmess://, VLESS is vless://, Trojan is trojan://, Hysteria2 is hysteria2://, TUIC is tuic://.

Common Steps for Importing Subscriptions

In most clients, importing a subscription takes just three steps: open the client's "Subscription" or "Configuration" page → paste the subscription link → click "Update" or "Import." The client automatically downloads and parses the configuration, and the route list appears on the main interface.

If you're using the VPNXE official client, the import process is even simpler: enter your username and password on the login page (no email address required), and the client automatically pulls your subscription and loads the route list.

How to Verify the Configuration Is Active

After importing the subscription, select a route and click connect. Once connected, you can verify whether your exit IP has changed on the IP Lookup page. If it shows an IP from the region of the route you selected, the configuration is active.

Common Issues & Troubleshooting

Even after understanding the principles of protocols and routes, you may still encounter various issues in practice. Below are the most common problems and their troubleshooting approaches.

Connection Fails, but the Route List Looks Normal

This is usually caused by your local network environment. Check the following in order: First, confirm your device can access the internet normally — open a browser and visit any website; if you can't even load a website, the problem is in your local network. Second, try switching protocols — some network environments restrict UDP traffic, preventing QUIC-based protocols from connecting; switching to a TCP protocol should fix it. Third, check firewall settings — some firewalls block proxy connections, so you need to add the client to the whitelist.

Connection Succeeds, but Speed Is Slow

Slow speed is usually caused by route congestion or inappropriate protocol selection. Troubleshoot in this order: First, switch routes — the current route may be in peak-hour congestion; switching to another route in the same region usually helps. Second, switch protocols — if you're using a TCP protocol, try switching to Hysteria2 or TUIC. Third, check your local network — if your local Wi-Fi is slow to begin with, a proxy can't improve it.

Connection Drops Frequently

Frequent disconnections are usually caused by network instability. Try the following: First, switch routes — the current route may be of poor quality. Second, enable auto-reconnect — most clients support automatic reconnection after disconnection; enabling it can automatically restore the connection. Third, check device power management — some devices' power-saving modes restrict background network activity, causing connections to be cut off.

Some Websites Won't Open

If only some websites won't open while others work fine, the target websites may have special restrictions on proxy traffic. Try the following: First, switch routes — different routes have different IP ranges, and some IPs may be blocked by the target website. Second, switch protocols — some websites are more friendly to TLS traffic; switch to Trojan or VLESS. Third, check DNS settings — some clients use remote DNS resolution by default; if resolution fails, switch to local DNS mode.

Abnormal Battery Drain on Mobile

If battery drain increases noticeably after enabling the proxy on mobile, check: First, whether on-demand connection is enabled — if not, the client keeps a persistent connection, increasing battery drain. Second, protocol selection — TUIC and Shadowsocks have the lowest power consumption on mobile. Third, background apps — some apps send frequent requests, causing the tunnel to continuously transmit data.

Subscription Can't Be Imported

If the subscription link can't be imported into the client, confirm: First, whether the link is complete — subscription links are usually long and easy to truncate when copying. Second, whether your account is valid — confirm your plan hasn't expired. Third, client version — older client versions may not support certain protocols; upgrade to the latest version.