Protocol Reference:Six Protocols and Three Route Topologies

Six protocols, and the problem each one solves

A proxy protocol has to handle three things at once: wrap TCP and UDP traffic into a tunnel, make that tunnel not look like a tunnel to the equipment in the middle, and complete authentication and encryption at both ends. How those three priorities are ranked is what separates the protocols. Once you see it that way, picking a protocol stops being a question of which one is stronger and becomes a question of what this particular link is missing.

Shadowsocks: the lightest layer of wrapping

Shadowsocks is one of the earliest lightweight designs. At its core is an encrypted SOCKS5 tunnel that protects the payload with AEAD ciphers such as AES-256-GCM and ChaCha20-Poly1305. It does not pretend to be HTTPS; it only ensures the traffic itself carries no plaintext signatures.

The upside is a simple implementation, the widest client support and the smallest handshake overhead. The cost is a fixed traffic shape: one continuous bidirectional stream of random bytes, not necessarily on port 443. When network equipment classifies sustained encrypted flows on non-standard ports, Shadowsocks has no outer shell to hide behind. UDP support also depends on the implementation, and behaviour varies between clients.

VMess: protocol and transport split into two layers

VMess carries a UUID identity and timestamp validation, and its transport layer is pluggable — WebSocket, gRPC, HTTP/2, mKCP and others can all serve as the outer shell. That is its biggest structural advantage: the same authentication logic can wear different appearances, and if one appearance does not fit, you switch to another.

The cost is complexity. Timestamp validation requires the client and server clocks to stay within an allowed window, so a device with the wrong time fails authentication outright — and the error usually surfaces as nothing more than a connection timeout. The legacy AlterID mechanism kept extra identity derivation for compatibility; it is now normally set to 0 to cut unnecessary overhead and shrink the replay surface.

Trojan: disguising itself as an ordinary TLS session

Trojan takes the most direct approach: the client completes a real TLS handshake with the server, and the password travels inside the TLS channel as the credential. To anything in the middle, the connection is indistinguishable from visiting an ordinary HTTPS site — because at the protocol level, it is one.

The cost is that you need a certificate, you need port 443, and if the certificate expires or is misconfigured the route simply stops working. It is also the protocol most dependent on server-side operations quality: get the certificate chain, the SNI or the HTTP response disguise wrong in any way and the disguise either shows or the connection fails.

VLESS: VMess with the extras removed

VLESS strips out the protocol's own encryption and part of the validation, handing security to the outer TLS or Reality layer and keeping only lightweight identity passing. With one less layer of wrapping, handshakes are faster and CPU cost is lower; combined with the XTLS approach it can reach very low forwarding overhead.

The cost is that it provides no encryption of its own. If TLS is not configured properly, security rests entirely on the outer layer — unlike Trojan, which is TLS by default. Choosing VLESS means confirming the outer transport is set up correctly, not treating it as a protocol that can run unprotected.

Hysteria2: a QUIC design for lossy links

Hysteria2 is built on QUIC (UDP) with its own congestion control. It targets the weakness of TCP-based protocols on high-loss links: QUIC implements congestion control in user space, so it can use algorithms that are not sensitive to random loss instead of treating every dropped packet as a congestion signal the way TCP does.

The cost is an obvious UDP signature. Some networks rate-limit or deprioritise UDP, and then performance collapses suddenly — a collapse caused by the environment that no parameter change will fix. The user-space stack also costs more CPU than kernel TCP, and on low-power devices that difference gets amplified.

TUIC: an even more minimal QUIC proxy

TUIC is also QUIC-based but closer in design to a minimal QUIC proxy, with 0-RTT session resumption. Fewer round trips to establish a connection and fast reconnects make it a good fit for mobile use where connections drop and re-form constantly.

The cost is a narrower ecosystem than Hysteria2: some clients and panels do not support it yet. Check that your client version recognises it first, otherwise you get the frustrating case of a correct config that the client simply will not accept.

Handshakes, overhead and connection setup speed

The first measurable difference between protocols is how many round trips it takes to establish a connection. That number directly sets first-paint speed, especially on cross-border links where every round trip costs well over a hundred milliseconds.

Round trips for one connection

From tapping Connect to the first byte leaving, there are several unavoidable steps:

1. DNS resolution: if the client connects by hostname, the address has to be resolved first. Connecting by IP skips this step.
2. TCP three-way handshake: one round trip, no exceptions.
3. TLS handshake: one round trip for TLS 1.3, two for TLS 1.2. Only Trojan, VLESS over TLS and VMess wrapped in TLS have this layer.
4. The proxy protocol's own authentication: most protocols put authentication in the first packet, so it costs no extra round trip.
5. The destination site's own handshake: the proxy only delivers bytes; the destination's connection setup cost still applies.

On a cross-border link with a 150 ms round trip, TCP plus TLS 1.3 alone costs 300 ms. That is not slow software; it is distance. No client optimisation can remove the time light spends in fibre — only the software overhead on top of it.

Where each protocol sits on that timeline

Shadowsocks has no TLS layer, and authentication is merged into the first data packet, so in theory data can flow after 1 round trip. VMess also authenticates in the first packet and adds no round trip, though parsing the timestamp and UUID in that packet costs a little CPU. Trojan and VLESS over TLS must complete a full TLS handshake, one round trip more than Shadowsocks, and what they buy is looking like HTTPS.

Hysteria2 and TUIC run over QUIC. QUIC merges the transport and cryptographic handshakes into one round trip for a first connection, and TUIC supports 0-RTT resumption, so reconnects within the session ticket lifetime cost no extra round trip. That is a real advantage of the QUIC family for frequent reconnects, not marketing copy.

The real CPU and memory cost

Encryption is not free, but on modern CPUs it is cheap:

• AES-GCM is hardware-accelerated on x86 processors with AES-NI, reaching throughput in the multiple GB/s range — a single proxy connection cannot saturate it.
• On ARM devices (phones, routers, TV boxes) AES instruction support is uneven, and ChaCha20-Poly1305 is usually faster — which is why ChaCha20 is the recommendation on mobile.
• QUIC-based protocols implement the stack in user space, so every packet crosses the user/kernel boundary, and CPU usage is noticeably higher than kernel TCP. On low-power devices this shows up as a fan spinning up or a battery draining fast.
• On memory, the main cost is per-connection buffering. Multiplexing can squeeze many connections into one tunnel, cutting handshakes and buffers, at the price of head-of-line blocking.

Why handshake overhead gets amplified

Handshake cost is paid once, when a new connection opens. Browsers reuse connections to the same site, but modern pages span many hostnames — analytics, fonts, images and APIs each on their own — so a single page load can trigger a dozen or more new connections. That multiplies the handshake round trips, and it is the real reason protocols seem to affect first-paint speed.

Conversely, in long-lived scenarios such as video playback or large downloads the handshake happens once, and differences between protocols become almost invisible. The same protocol can therefore feel completely different depending on the scenario, so any claim about which protocol is faster has to start by naming the scenario.

Mobile battery math

Battery drain on a phone comes from four places: CPU encryption, radio transmission, the number of system wake-ups, and the screen plus hardware decoding. Protocols affect the first three, but what most people notice as faster drain with a proxy on is really the third — wake-ups.

The cost of waking the radio

A mobile radio has several states: idle, low power and high power. Moving from idle to high power takes hundreds of milliseconds, and during that window power draw is several times the peak. If a connection sends a heartbeat every ten seconds, the radio is forced awake every ten seconds — more than eight thousand wake-ups a day.

• TCP-based protocols usually let you configure keepalive, and system-level TCP keepalive defaults are long (measured in hours), so the application layer need not send heartbeats at all.
• QUIC-based protocols send periodic keep-alives by default to hold NAT mappings open, typically every ten to a few tens of seconds. That, rather than encryption itself, is a main reason QUIC drains mobile batteries faster.

So the accurate way to put it is not that switching protocols saves battery, but that switching off periodic heartbeats does. On the same QUIC connection, moving the heartbeat interval from ten-odd seconds to two minutes makes a very visible difference.

How much encryption actually costs

On phones with AES instruction support, AES-GCM throughput is far above the bandwidth ceiling of a mobile network, so encryption time is negligible. What really eats CPU is the QUIC user-space stack: every packet is copied between user and kernel space, and during a sustained full-speed download the CPU sits at a high frequency for a long time.

Conversely, if your usage is browsing pages and reading messages, the traffic volume is small, the QUIC CPU cost never really shows, and battery differences get buried under other factors.

Background keep-alive and the illusion of still connected

Both iOS and Android reclaim background apps. Proxy apps usually run through the system VPN framework, which is relatively stable, but in-app timers are still throttled. The symptom: after the screen has been locked for a while, the connection looks alive on unlock but the first request is noticeably slow — the tunnel needs to be rebuilt or renegotiated.

That still-connected state is more troublesome than a clean disconnect, because it never triggers the client's automatic reconnect logic. If you often see a blank page for a few seconds after unlocking, turn on auto-reconnect in the client, or simply disconnect manually when you will not be using it for a while.

Practical battery tips

• On phones, prefer TCP-based protocols and keep QUIC for weak-network situations.
• Pick a nearby route with lower latency: the shorter the handshake round trip, the less time the radio spends at high power.
• Turn off per-app proxying you do not need: only route the apps that require it, cutting the number of persistent connections.
• Lengthen the heartbeat interval — provided your network does not drop the NAT mapping on timeout.
• During long video sessions, battery differences come mainly from the screen and hardware decoding, which dilutes any gap between protocols.

Route topologies: direct, relay, dedicated

Protocols decide how traffic is wrapped; topology decides which path it takes. On cross-border links, topology usually shapes the experience more than the protocol does. Moving one protocol to another on the same route may matter less than moving to a route with a different topology.

Direct

The client connects straight to the public address of an overseas data centre, and traffic leaves through the carrier's international gateway.

• Simplest structure, no intermediate hop, lowest baseline latency.
• But international gateways are shared resources. At peak hours the queues lengthen, loss and latency rise together, and the provider has no control over that congestion.
• Best for: light browsing, off-peak hours, cost-sensitive use.

The problem with direct is not that it is slow, but that it is unpredictable. Off-peak it may beat a relay; at peak hours it may be unusable, with no warning in between.

Relay

The client connects to a relay entry point first, and that entry point connects onward to the overseas exit.

• It narrows the uncertainty of the last mile into a controllable segment: client to relay entry runs over the domestic backbone, which is usually stable, and relay entry to exit runs over an optimised cross-border route.
• The cost is an extra hop and higher baseline latency. The relay node's own capacity can also become the bottleneck — an under-provisioned relay is worse than direct.
• The key question is not whether there is a relay, but whether the cross-border segment behind it is optimised. Two routes can both be called relay while one uses the public gateway and the other an optimised path.

That is why relay routes from different providers can feel so different: same name, completely different routing policy. There is only one way to judge — use it during peak hours.

Dedicated

An end-to-end logical circuit (IEPL, MPLS and similar), with dedicated or near-dedicated bandwidth that avoids the congested points of the public gateway.

• Stable latency and low loss; peak-hour performance stays close to off-peak.
• High cost and limited total bandwidth, so it is usually deployed only in key regions and cannot cover every country.
• Best for: latency-sensitive work such as conferencing, gaming, remote desktop and business traffic that needs stability.

Dedicated is not faster, it is steadier. Its absolute latency is not necessarily lower than direct, but the number you measure at 8 pm and the number you measure at 2 am should be about the same — that is what you are paying for.

What latency is made of

1. Physical propagation: light travels through fibre at roughly 200 km per millisecond. Shanghai to Los Angeles is about 10,500 km as the crow flies; with a 1.4x routing factor the one-way path is about 14,700 km, or roughly 73 ms one way and 146 ms round trip. That is the physical floor, and no optimisation gets below it.
2. Routing detours: the actual path is not always the shortest, and detours add tens of milliseconds.
3. Queueing delay: when the gateway is congested, packets wait in queues. This term can multiply at peak hours and is the least controllable of all.
4. Protocol handshakes: as covered in the previous chapter, every extra layer adds a round trip.

So a claim like this route has 40 ms latency only means something when the endpoints are stated. The same node measured from Guangzhou and from Harbin can differ by a factor of two.

Packet loss, jitter and peak hours

Slower at peak hours is the most common complaint about cross-border access, and the most misunderstood. It is not one cause but a chain reaction.

Where packet loss comes from

• Bit errors: fibre has an extremely low error rate, so loss from bit errors on a healthy link is negligible. Wireless segments (4G, 5G, Wi-Fi) are the exception — when the signal is weak, the error rate rises noticeably.
• Queue overflow: a router's buffer fills and later packets are dropped. This is the main source of loss on cross-border links.
• Policy drops: some network equipment rate-limits or drops specific traffic types. This is also why QUIC-based protocols behave inconsistently on certain networks.

The three kinds of loss need completely different responses: bit errors can only be fixed by changing the wireless environment, queue overflow by changing topology or timing, and policy drops by changing protocol or port. Tweaking parameters without identifying the source is mostly wasted effort.

How peak hours form

Between 7 pm and 11 pm, home broadband concurrency rises and total traffic on international gateways approaches or exceeds design capacity. Gateway equipment starts queueing, and then the chain runs:

1. Queues lengthen and latency rises.
2. Queues fill and packets start dropping.
3. TCP reads loss as congestion, halves the congestion window, and throughput collapses.
4. Users feel it, refresh and retry, new connections flood in, and congestion gets worse.

This is a positive feedback loop, which is why peak-hour degradation is rarely linear — it falls off a cliff past a certain point. It explains the common experience of everything being fine before eight and unusable at five past.

Why one percent loss can destroy half your bandwidth

TCP throughput is roughly proportional to segment size divided by (round-trip time × the square root of loss rate). At a 150 ms round trip and one percent loss, a single TCP connection's theoretical throughput drops to a small fraction of peak. That is also why a speed test can show full speed while pages load slowly: the test uses many parallel threads, a page uses one connection.

Once you see that, a lot of the mystery goes away: at the same moment on the same route, a download manager saturates the link while the browser stutters — not because the browser is bad, but because the concurrency model differs.

Why the QUIC family does better under heavy loss

QUIC implements congestion control in user space, and common algorithms model bandwidth and round-trip time rather than treating every loss as a congestion signal. On links where loss is mostly random, that keeps throughput higher. The cost is slower reaction to genuine congestion, and it can behave unfairly when bandwidth really is scarce.

In other words, QUIC is not faster, it is more forgiving of loss. On a link that drops nothing there is no meaningful gap; once loss starts, the gap opens.

Bufferbloat

Home routers and some carrier equipment use large buffers. Big buffers help with bursts, but under sustained saturation they push queueing delay into the hundreds of milliseconds. The symptom: speed tests look normal, but every click takes a moment, and video plays while seeking spins.

How to tell: watch round-trip time to the local gateway and to an overseas target at the same time. If the gateway itself wobbles, the problem is local; if the gateway is steady and the overseas target wobbles, the problem is in the cross-border segment. This one step halves the search space.

Jitter hurts more than latency

High but stable latency is something users adapt to; moderate latency with heavy jitter means constant buffering, choppy voice and rubber-banding in games. When choosing a route, weight jitter above average latency. Many clients show a single latency number, usually an average of several probes, which hides jitter — measure several times in a row and look at the spread.

Choosing by scenario

The previous chapters covered principles; this one gives conclusions. The premise: all of the advice below assumes the route itself is usable. If a route is already badly congested at peak hours, changing protocol can ease it but not cure it.

Everyday browsing and office work

Recommended: VLESS over TLS or Trojan.

Why: page loads trigger many short connections, which multiplies handshake round trips. Both protocols use standard TLS and, with connection reuse, give a stable first paint; their traffic also looks like ordinary HTTPS, which is the most compatible across network environments. QUIC is not recommended for office work: its handshake advantage is marginal for short connections, and the user-space stack's CPU cost is noticeable on a low-spec laptop.

4K streaming

Recommended: VLESS or Trojan with a relay or dedicated route.

Why: streaming means long connections and sustained high volume, so bandwidth stability comes first. TCP-based protocols saturate the link when bandwidth is available, and a dedicated or optimised relay route avoids peak-hour gateway congestion. If your network treats UDP well, Hysteria2 is also an option — it holds bitrate better on lossy links and is less likely to trigger a player's quality drop. The site's streaming access page has per-platform route suggestions, and there is a detailed explanation of bitrate versus bandwidth.

Online gaming

Recommended: Trojan or VLESS on a nearby node, with multiplexing off.

Why: games care about latency and jitter, not bandwidth. TCP-based protocols give a flatter latency curve; multiplexing squeezes many connections into one tunnel, so a single loss event stalls them all (head-of-line blocking) — which shows up as the whole match lagging at once.

If the game needs UDP forwarding, confirm UDP is enabled on both client and server, otherwise you get the can log in but cannot join a match pattern. For more measurement ideas on latency and loss, see latency and packet loss in gaming.

Large downloads and updates

Recommended: Hysteria2.

Why: downloads are pure throughput and insensitive to latency. On lossy links the QUIC family's throughput advantage is largest. The cost is high CPU, which can become the bottleneck on low-power devices — if the download will not go faster while the CPU is pinned, the device's compute has hit its ceiling first.

Long standby on mobile

Recommended: Trojan or VLESS. The reasoning is in the battery chapter: QUIC's periodic keep-alives keep waking the radio. Android background and power-saving behaviour has its own details; see the Android hands-on comparison.

Weak network conditions

Recommended: Hysteria2 or TUIC.

Why: weak networks are characterised by high loss and heavy jitter. TCP-based protocols keep shrinking the congestion window in that situation, which shows up as speed swinging up and down; QUIC's congestion control is less sensitive to random loss, so speed stays steadier. Public Wi-Fi, mobile signal at one or two bars, and trains all fall into this category.

When you also use AI tools

AI tool API calls are short requests, but a single response can be long (generated replies stream back). These scenarios are sensitive to first-byte latency and moderate on bandwidth, so VLESS or Trojan on a relay route is the recommendation. More detail on the site's AI Tools page.

Layered troubleshooting and self-checks

Troubleshooting is about layers: separate can it connect from is it fast, then split fast into latency, loss and bandwidth. Change one variable per layer so you can tell which step actually helped.

Layer one: confirm traffic really goes through the tunnel

Connected does not mean traffic actually uses the route. Three ways to verify:

1. Check the exit IP: look it up before and after connecting. It should differ, and the location should match the route's region.
2. Check DNS: resolution should be handled by a resolver inside the tunnel, not by the local carrier. If DNS goes local, you get the connected but some sites will not open pattern.
3. Check per-app routing: if per-app proxying is on, confirm the target app is in the list.

Full steps are in the article how to confirm your VPN is actually working. On the command line:

# 1. Check the current exit IP (example address; replace with any service that returns a plain-text IP)
curl -s https://example.com/ip

# 2. Show the DNS servers currently in use
nslookup example.com
# The address after Server: in the output is the resolver actually in use

# 3. Probe repeatedly to see jitter, not just the average
ping -c 20 example.com

Note that ping uses ICMP, and some routes prioritise ICMP differently from TCP — a healthy ping does not prove TCP is healthy, or vice versa. To measure TCP round trips, use curl and look at the phase timings:

curl -o /dev/null -s -w "dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} total=%{time_total}\n" https://example.com

These numbers tell you where the time goes: a large time_namelookup points to DNS; a large time_connect points to the TCP handshake or the link; if time_appconnect is much larger than time_connect, the TLS handshake is slow, usually because the route's round trip is long or the certificate chain is long.

Layer two: it will not connect

Check in order, without skipping steps:

• Has the subscription expired: once traffic runs out or the term ends, the client still shows connected but every request is rejected. This is the most common cause and the easiest to overlook.
• Device time: VMess relies on timestamp validation, and a large clock skew fails authentication outright. Turn on automatic time sync.
• Protocol and port match: a server-side change that the client subscription has not picked up is a common cause. Refresh the subscription.
• Local firewall: some security software blocks outbound connections on non-standard ports, which shows up as every route failing.
• Certificates: Trojan and VLESS over TLS depend on them. When a certificate expires the client reports a TLS handshake failure rather than a connection timeout.

Layer three: it connects but is slow

1. Change route: the same route can behave very differently at different times. Try a route with a different topology first.
2. Change protocol: switch protocol on the same route. If TCP-based is slow while QUIC is fine, there is loss on the link.
3. Check the time of day: note when it slows down. If it is always in the evening, it is gateway congestion; if it is all day, the route itself is the problem.
4. Check a single connection: test with a single-threaded download. Fast multi-threaded but slow single-threaded points to loss or bufferbloat.
5. Check MTU: QUIC is sensitive to MTU. A path MTU black hole looks like a successful handshake, small requests working and large requests hanging. Lower the MTU (1280, for example) and try again.

Layer four: only some apps have problems

• Whether the per-app proxy list includes that app.
• Whether the app uses its own DNS or encrypted DNS, bypassing the tunnel's resolver.
• Whether the app forces IPv6 while the tunnel only proxies IPv4.
• Whether the app uses certificate pinning, which is incompatible with an intercepting proxy.

This layer is the most expensive to investigate because every app behaves differently. The efficient approach is to confirm the tunnel itself is fine in a browser, then check apps one by one.

Settings cheat sheet and common myths

The final chapter walks through the switches in your client one by one, then lists a few common myths. Treat it as a reference page and come back when an option is unclear.

The switches in your client

• TLS: with it on, traffic looks like HTTPS. Trojan and VLESS require it; Shadowsocks and VMess can be wrapped in TLS, at the cost of one extra round trip.
• XTLS and Reality: two transport optimisations for VLESS. The first reduces copies in the encryption layer; the second lets the server present genuine TLS characteristics without owning a certificate. Both need matching server support — enabling them on the client alone does nothing.
• Multiplexing: funnels many connections into one tunnel. It cuts handshakes but introduces head-of-line blocking on lossy links. Fine for browsing, not recommended for gaming or voice.
• UDP forwarding: decides whether UDP traffic goes through the tunnel. Games, voice calls and some video calls depend on it. Turn it off and those apps either go direct or stop working.
• Congestion control: usually selectable on QUIC-based protocols. Bandwidth-modelling algorithms give better throughput on lossy links but are less friendly to other traffic under genuine congestion.
• Per-app proxying: routes only the apps you list. It saves battery and reduces interference, but a bad configuration shows up as one app that cannot connect.
• Automatic subscription updates: pulls the latest routes periodically. Worth enabling, but do not set the interval too short or every update causes a brief interruption.

Six common myths

Myth one: newer protocols are faster. The protocol determines overhead and loss tolerance; the bandwidth ceiling comes from the route and the exit. On a clean, low-loss link the throughput gap between the six protocols is far smaller than the gap between routes.

Myth two: stronger encryption is slower. AEAD ciphers cost very little on modern processors; the real bottleneck is the link. Moving from AES-256 to ChaCha20 may be measurable on a phone and is essentially imperceptible on a desktop.

Myth three: lower latency always means faster. Latency affects how quickly things start; throughput also depends on loss and the congestion window. A route with 40 ms round trip and two percent loss can download more slowly than one with 80 ms and almost no loss.

Myth four: UDP is always rate-limited. It depends on the network, and generalisations do not help. The test is simple: run a single-threaded download over a TCP-based protocol and a QUIC-based one on the same route and compare.

Myth five: more proxy layers means more security. Stacking layers only adds latency and failure points; it does not make the single-layer encryption stronger. What you need is a correct protocol configuration, not more layers.

Myth six: more connections means faster. Browsers cap concurrent connections and queue the rest. Running several clients or several tunnels just makes them compete for the same bandwidth.

Putting this handbook to work

If you have just decided to try it, check the pricing page for tiers: monthly plans are ¥9.9 for 60GB, ¥18 for 250GB and ¥28 for 500GB, with traffic resetting each month on your activation date and mid-term upgrades credited pro rata for the remaining days; there are also data packs at ¥158/300GB, ¥358/1000GB and ¥658/3000GB that last until used up and never expire. Every plan allows unlimited devices, supports Alipay, WeChat and USDT, and sign-up needs no email address — just a username and password. A no-questions-asked refund is available within 7 days of your first payment.

If you have already subscribed, walk through the import flow in the Guides, then come back and pick a protocol by scenario. To understand what the service stands for first, see About this site.