Routes and protocols: a technical selection guide

Design trade-offs of the six protocols

These six protocols usually sit side by side as options in a client. They are not a new-replaces-old sequence; each makes a different trade-off against a different constraint. Some push overhead to the minimum, some maximise compatibility, some are built specifically for lossy networks. Understanding the trade-offs is far more useful than memorising which one is stronger.

Shadowsocks: light and direct

Shadowsocks has a single design goal: encrypt and forward TCP and UDP traffic with as little overhead as possible. It derives session keys from a pre-shared key, applies AEAD encryption per packet, has no built-in complex authentication handshake and no server-side user system. The result is low first-packet overhead and low server resource use, which suits one person or a handful of devices. The cost is that it has no disguise layer of its own: the traffic looks like an encrypted TCP stream, unlike ordinary TLS web traffic. When an extra TLS layer is needed, it usually comes from a client plugin or an outer forwarder.

VMess: encapsulation with a user system

VMess carries a user identifier and a timestamp in the protocol header, which the server uses to decide whether a request is legitimate and which user it belongs to. That makes it a natural fit for multi-user and multi-device setups: one entry point can route and meter per user. The cost is a slightly larger header and sensitivity to time — if the clock skew between client and server exceeds the allowed range, the connection simply fails, showing up as node test timed out while the network itself is fine. When you see that, set the device clock to automatic sync and try again.

Trojan: the standard-TLS kind

Trojan puts authentication data in the application data after the TLS handshake, usually on port 443, so the handshake is indistinguishable from visiting an HTTPS site. Its strength is compatibility: middleboxes see a standard TLS connection. The cost is that you must maintain a certificate and domain — an expired or replaced certificate breaks the connection outright — and the TLS handshake itself adds a round trip, so first-packet latency is slightly higher than with plain-TCP Shadowsocks.

VLESS: encryption handed to TLS

VLESS drops the protocol's own encryption layer and keeps only a lightweight header and authentication, leaving encryption entirely to outer TLS or REALITY. The upside is lower server CPU cost and a shorter header, which makes it easier to saturate bandwidth in high-throughput scenarios; the downside is that it must be paired with a reliable outer layer and is meaningless on its own. For ordinary users, the felt difference between VLESS and Trojan is usually smaller than the difference between routes, so there is no need to keep switching.

Hysteria2: built for lossy networks

Hysteria2 is based on QUIC, runs over UDP and includes congestion control and bandwidth negotiation. Its strength is high-loss, long-distance links: TCP keeps shrinking its congestion window on such links, while Hysteria2 can maintain throughput with a better-suited algorithm in user space. There are three costs: UDP is rate-limited or dropped outright on some networks; connections must be rebuilt when the mobile network changes; and UDP traffic is more sensitive to MTU, so a wrong fragmentation setting shows up as connects but large files will not transfer.

TUIC: multiplexing on QUIC

TUIC is also built on QUIC, with the emphasis on multiplexing and connection migration: several requests run in parallel inside one QUIC connection, and a lost packet on one request does not block the others; when you move from Wi-Fi to cellular, the QUIC connection identifier lets the session continue without a new handshake. Its use cases are close to Hysteria2, with the differences showing up mostly in the client's congestion control implementation. It is equally bound by UDP availability — if the network does not pass UDP, neither works.

If you remember one thing: with TCP-based protocols the route sets the floor on stability, and with UDP-based protocols the route decides whether traffic still moves when packets are lost. Check the route before choosing a protocol; doing it the other way round means repeatedly testing on the wrong dimension — moving a congested direct route from Trojan to VLESS to Hysteria2 usually changes very little.

Connection setup speed and resource use

When a page loads slowly, most people assume there is not enough bandwidth. More often the cause is round trips: every new connection needs a handshake, a handshake needs a round trip, and round-trip time is set by physical distance and path quality. Bandwidth decides how fast data moves; round trips decide how long before it starts moving.

A full TCP plus TLS connection looks roughly like this: resolve the domain (possibly one round trip), TCP three-way handshake (one round trip), TLS 1.3 handshake (one round trip, skippable on session resumption), then the protocol's own authentication, and only then the HTTP request. In other words, a cold start on a domain costs at least several round trips, and a page that references several domains repeats the process several times. That is why lots of bandwidth but a slow first screen is not rare.

QUIC merges the transport handshake with the TLS handshake: one round trip on a first connection, and session resumption can reach 0 round trips with data attached. That is the main reason UDP-based protocols feel faster on the first page load, and it has nothing to do with bandwidth. The cost is that once a network blocks UDP, that path is simply unavailable, with no fallback.

Resource use has two sides. On the client, encryption and decryption dominate CPU: AES is cheap on processors with hardware acceleration, while ChaCha20 is cheaper on some mobile chips. On the server, the main cost is concurrent connections multiplied by memory per connection, plus the session tables UDP-based protocols must maintain. Multiplexing reduces the connection count but means more state per connection — memory traded for round trips.

One easily missed point: the latency test in a client measures one probe round trip to the entry point, not to the exit, and not page load time. When the entry is close and the exit is far, the test number looks great while pages still load slowly. Judge real experience by full page loads and video buffering, not by that single number.

Mobile battery and data overhead

Phone battery drain comes from three places: the radio waking up repeatedly, CPU spent on encryption, and reconnects. All three relate to protocol and route, but with different weights. Most people assume encryption is the drain; in practice heartbeats and reconnects usually are.

Start with heartbeats. To keep NAT table entries from expiring, the client sends a small keepalive packet at intervals. Too short and the radio keeps waking from idle, which costs real battery; too long and middleboxes drop the mapping, so the next use needs a reconnect, which triggers a full handshake again. The right interval depends on the table timeout of the network you are on — home broadband, office networks and mobile carriers all differ — so clients usually ship a conservative default and expose a setting. If unsure, keep the default and only adjust when something is clearly wrong.

Then reconnects. On mobile networks the most expensive operation is reconnecting: moving from Wi-Fi to cellular, entering a lift, passing through a tunnel all trigger it. TCP-based protocols must redo the handshake after a network change; QUIC-based protocols can migrate the session using the connection identifier, provided the new path is reachable and middleboxes do not block UDP. So UDP-based protocols save battery on mobile holds only under conditions: it holds when handovers are frequent and UDP is available, and reverses when reconnects are more frequent and costlier.

System background limits count too. Both iOS and Android suspend background apps after the screen has been off for a while, and a suspended client naturally loses its connection. This is not a protocol issue — every protocol behaves the same. For always-on scenarios, use the system's on-demand connection features so the system wakes the client when the network changes, instead of keeping the client running and waiting.

On data overhead, protocol headers are a small share; retransmissions and heartbeats are what actually move the meter. On a lossy route, retransmissions can push real consumption far above expectations, and heartbeats add up even though each one is tiny — several hundred a day is still volume. This matters when data is billed by usage: VPNWu data packs last until used up and never expire, while monthly plan data resets each month on the activation date. Under either billing model, check actual usage in the client and compare it with your own estimate.

How to check it yourself. Use the built-in battery usage statistics to compare idle while connected for a while against idle while disconnected for the same period, then read the client's connection log and count reconnects in that window. If reconnects are frequent, changing route type usually helps more than changing protocol — stabilise the path first, then talk about encapsulation.

Route topology: direct, relay and dedicated

Routes are the part of this page that affects real experience most and gets discussed least. The protocol decides encapsulation; the route decides which path the data actually takes. On the same home broadband line, different routes can differ by an order of magnitude at peak hours while the protocol options in the client have not changed at all.

Direct

Direct means the entry and exit are in the same place, so traffic goes straight from the user to the exit data centre. The path is shortest and latency is theoretically lowest. Its weakness is that quality depends entirely on that stretch of public network: at peak hours a direct route queues alongside ordinary international traffic and jitter rises noticeably. Direct suits latency-sensitive uses that do not demand peak-hour stability, such as daytime work or a quick lookup.

Relay

A relay adds an entry node between the user and the exit: the user connects to a nearby entry, and the entry forwards traffic to the exit over the provider's own links. That is one extra hop, a few milliseconds in theory, but the outbound leg is replaced with a more controllable link, so peak-hour jitter is usually lower than on a direct route. Differences between relay routes come mainly from the relay nodes' bandwidth and scheduling policy, so what you are choosing is the operator's capacity, not the node count.

Dedicated

A dedicated route runs over a point-to-point private channel between entry and exit and does not share congestion with public traffic. Its hallmarks are stable latency, low jitter and low loss; the cost is high, so it is usually offered only on popular exits. For video conferencing, real-time collaboration and long-lived stable connections, the value is not peak bandwidth but the fact that it does not collapse at peak hours. If you only watch video occasionally, the improvement may not be noticeable.

The recommended order is: decide the exit region first (where the content and services are), then the route type (whether stability at peak hours is needed), and only then the protocol. Doing it the other way round — picking a protocol first — makes it easy to keep swapping encapsulation on an already congested route, spending time with no effect. Each route on the routes page carries a type label describing one of the three above; do not read relay as a longer detour, therefore slower — what it optimises is the outbound leg.

What causes packet loss and peak-hour congestion

Packet loss is not a fault; it is normal. When a queue fills anywhere along the path, later packets are dropped, and wireless interference causes loss too. The question is not whether loss happens but where it happens, how long it lasts and how the protocol responds.

There are four common sources. Local wireless: Wi-Fi interference, distance and crowded channels make every route slow, and switching routes does nothing. Home broadband upstream: when upload is saturated the download side suffers too, because acknowledgements cannot get out, which shows up as stutter while downloading. International link peaks: cross-border traffic concentrates in the evening, public links queue, and the symptom is slowdowns at fixed hours with normal behaviour at others. Exit data centre egress: exit bandwidth is saturated, so one route is slow while other routes in the same region are fine.

TCP reacts sharply to loss: on detecting a drop it halves the congestion window and then grows it back slowly. Short connections suffer most — a page's dozen requests crowd onto one connection, and a single loss makes the whole connection wait for retransmission. QUIC splits the problem per stream: one stream loses a packet while the others keep moving, which is why UDP-based protocols usually feel smoother on lossy networks.

Peak hours do not mean unusable; they mean higher latency, more jitter and video that drops to a lower bitrate. The most effective move in that window is to change route type (direct to relay or dedicated), not to change protocol. The bottleneck is congestion on the path, not encapsulation; changing protocol only changes the queueing style, and the queue itself is no shorter.

Order of layer-by-layer troubleshooting

From near to far: check whether the local gateway is stable, then whether the entry is reachable, then the exit. Whichever of the three segments starts showing sustained loss, the problem lies beyond it. The command-line tool mtr lists loss per hop, and running it dozens of times in a row is far more meaningful than running it once.

# 1. Confirm the local gateway is stable (replace the example address with your router's address)
ping -c 20 192.168.1.1

# 2. Then check loss and latency per hop on the cross-border path, sampling 50 times
mtr -rwzc 50 example.com

# 3. Repeat the two steps above on another route and compare the same time window

Keep the sampling method consistent too: same time window, same target, at least three rounds of 50 probes each, recording average, maximum and loss rate. A single result is easily misled by momentary jitter. And do not compare two routes measured at different times — the gap between peak hours and the small hours can be larger than the gap between two routes.

Choosing a protocol by scenario

The previous chapters took things apart; this one puts them together. The order is: scenario → route type → protocol → client settings. Reversing it turns simple problems into complex ones — for example, deciding on a protocol first, then hunting for a route that runs it, and finally discovering the route itself cannot hold up at peak hours.

Web and office work

Web browsing is characterised by many short connections: a page opens a dozen connections and each needs a handshake. First-packet latency matters more than bandwidth here, and route round-trip time matters more than peak speed. At the protocol level choose a small header (Trojan, VLESS); the felt difference comes mainly from the route. If your office systems move many small files up and down, check the upstream too — upstream congestion drags the downstream with it.

Video meetings and real-time voice

Meeting traffic is bidirectional and continuous, and more sensitive to jitter than to bandwidth. With high jitter, audio breaks up and video freezes then catches up. UDP-based protocols are smoother under loss, and paired with a dedicated or a good relay route they are the first choice for this scenario. If the network does not pass UDP, TCP-based protocols still work, but a lost packet is more likely to cause a visible freeze.

Long-lived AI tool sessions

Most of these tools use streaming responses: a request stays open for tens of seconds to several minutes while data keeps arriving. If the connection drops, the answer is cut off and retrying is expensive. Stability therefore beats peak speed: a TCP-based protocol on a relay route is more practical than a UDP combination with a smaller test number. By the same logic, this is not a scenario for switching nodes often.

Large files and backups

Downloads and backups are about sustained throughput. Protocol header overhead is almost irrelevant here; route bandwidth and CPU at both ends decide the speed. Because VLESS hands encryption to TLS and keeps protocol overhead low, it saturates more easily at high throughput. Check how data is counted as well: monthly plan data resets each month on the activation date, while data packs last until used up and never expire, so data packs suit backup jobs that run at irregular times.

Three common misconceptions. First, a newer protocol is not necessarily faster: the protocol only decides encapsulation, and the bottleneck is usually the path. Second, one number does not represent everything: client latency is a probe to the entry point. Third, different time windows are not comparable: the gap between peak hours and the small hours can exceed the gap between two routes. Remember these three and you save a lot of trial and error.

Self-check and verification: after connecting

Connecting is not the same as routing correctly. Which country the exit is in, whether DNS resolution goes through the tunnel, and whether large packets get through all need separate confirmation. They produce three completely different symptoms, and mixing them up makes troubleshooting take longer.

Exit address and geolocation

The simplest check is the exit address. After connecting, open the network check page on this site, which shows the current exit and its location; disconnect and check again — only two different results prove traffic really goes through the route. If both are the same, the client is not taking over all traffic, or the app in question matches a direct rule. Only after this step does speed testing mean anything.

DNS resolution and routing rules

Whether resolution goes through the tunnel decides whether the resolved result and the actual exit agree. If the routing rules proxy only some domains, resolution may still happen locally, which shows up as some sites failing while others work. The check is simple: switch temporarily to global mode and try again. If the problem disappears, it is a rule problem — go back and review the rule list, no need to change protocol.

MTU and fragmentation

UDP-based protocols are more sensitive to MTU. The typical pattern: pages open and chat works, but video stalls, large files will not transfer and some apps spin forever. The cause is large packets being dropped along the path while small ones get through. The fix is to lower MTU or enable fragmentation in the client; the setting name differs between clients and usually lives in the protocol settings. After changing it, test a large file again — do not just check whether a page opens.

# Check the current exit address (replace the example domain with any echo service)
curl -s https://example.com/ip

# Check path MTU: start at 1500, then step down if it fails
ping -c 3 -M do -s 1472 example.com

A record sheet you can fill in

The worst part of troubleshooting is relying on memory. Write the items below down for three days in a row and the problem usually surfaces on its own.

The troubleshooting order in one sentence: confirm the exit is right (traffic really goes through the route), then confirm stability (several samples in the same window), and only then adjust the protocol. Reverse the order and route problems get treated as protocol problems, making things messier. If all three fail, go back to the setup guides and redo the import flow along the main path; if it still fails, contact support with the data from the record sheet — far more useful than saying it will not connect.

Glossary and common questions

This chapter is for looking things up later. Terms are ordered by how often they come up, and the Q&A covers the five most frequent questions, with answers that give decision criteria rather than conclusions.

RTTRound-trip time

The time from sending a packet to receiving a response. Most interactive experience depends on it, not on bandwidth.

JITTERJitter

The spread between successive round-trip times. Meetings and voice are most sensitive to jitter and relatively insensitive to peak bandwidth.

LOSSPacket loss rate

The share of sent packets dropped over a period. Short connections are more sensitive to loss, because one drop means waiting a full retransmission round.

MUXMultiplexing

Running several requests in parallel inside one connection. It cuts handshake counts at the cost of maintaining more connection state.

0-RTTZero-round-trip resumption

Skipping the handshake round trip when resuming a session, so the first request goes out with the resumption packet. It requires a previously established session.

MTUMaximum transmission unit

The largest packet that can be sent in one go. UDP-based protocols have extra requirements here, and a wrong setting shows up as large packets failing to transfer.

QUIC

A UDP-based transport protocol that merges the transport and TLS handshakes and supports per-stream retransmission and connection migration.

AEADAuthenticated encryption

Authenticated encryption with associated data, guaranteeing confidentiality and integrity at once; a basic building block of modern protocols.

CCCongestion control

The algorithm a sender uses to adjust its rate based on loss and latency. TCP and QUIC implement it differently, so poor-network behaviour differs too.

EDGEEntry and exit

The entry is the first server the user connects to; the exit is the final egress to external services. The distance between them sets the latency floor.

Common questions

Related pages: for first-time setup see the setup guides; to pick a route by region and route type see the routes page; for plan and data pack pricing see the plans page; to reproduce the speed-test process yourself, see how to measure VPN speed; and to start completely from zero, see the complete beginner guide.