Protocol and Route Selection Reference

The Design Trade-offs of Six Protocols

A proxy protocol has three problems to solve: wrapping traffic inside a connection that can actually get through, handling encryption and integrity checks between the two ends, and making it impossible for middleboxes on the path to identify the content from the bytes alone. The six mainstream protocols trade these three off differently, and those trade-offs show up directly in handshake round trips, CPU load, loss tolerance and mobile battery drain. This chapter goes through them one by one by design intent, without ranking them, because comparing strengths in isolation from the route tells you nothing.

Shadowsocks: The Thinnest Wrapper

Shadowsocks keeps its goal modest: carry traffic to the exit over a single encrypted TCP or UDP connection, with no extra obfuscation layer on top. Encryption uses AEAD suites — most commonly AES-128-GCM, AES-256-GCM and ChaCha20-Poly1305 — which fold encryption and integrity checking into one step and skip the extra pass of encrypting first and computing a separate checksum afterwards. Because there is no built-in TLS, its handshake cost is among the lowest of the six protocols, which directly benefits latency-sensitive use. The price is that the traffic profile depends entirely on how the outer layer wraps it: run bare, it is just a TCP stream of high-entropy bytes, and any device on the path doing deep packet inspection may take an interest. In practice Shadowsocks is usually placed inside a TLS tunnel or combined with another transport layer.

VMess: Identity and Timestamp Checks in the Header

VMess carries a user identifier and a timestamp in its protocol header, and the server uses both to authenticate the client. That brings a trap that is easy to fall into: the client and the node must keep roughly the same time. If the drift is too large the handshake is rejected outright, which looks like a configuration that checks out line by line but simply will not connect. The VMess header has gone through several versions; the AEAD version brings the header under integrity protection so its fields cannot be altered in transit. Its overhead is slightly higher than Shadowsocks, and what you get for it is a clearer multi-user model and finer-grained header fields, which suits running several subscribers on one node.

Trojan: Traffic Inside Standard TLS

Trojan's approach is to put proxy traffic inside a standard TLS connection: a completely ordinary-looking TLS handshake completes first, and only afterwards does the server check the password. To a middlebox on the path it looks like an ordinary HTTPS session — the same kind of destination hostname, certificate chain and handshake ordering as any regular visit. When the password does not match, the server can forward the connection to a real web service so a prober gets a normal page in response. Compatibility is the strength; the cost is an extra TLS layer, one more round trip in the handshake, and one more symmetric encrypt/decrypt pass on the CPU.

VLESS: Dropping the Duplicate Layer

VLESS takes the view that a protocol should only do its own job: it does not encrypt at all, leaving encryption entirely to the outer TLS layer so you never pay for encryption stacked inside encryption. With XTLS-style flow control the inner and outer encryption no longer run twice, and CPU load drops noticeably. VLESS is stateless — the server keeps no per-user session table — which makes horizontal scaling of nodes easier. It suits setups that already have a solid TLS channel and want to max out throughput and CPU efficiency; conversely, if the outer TLS is misconfigured, VLESS itself has no fallback encryption of its own.

Hysteria2: A Different Congestion Control on QUIC

Hysteria2 runs on QUIC, which means UDP. Its most practical difference is congestion control: it can use a BBR-style algorithm and keep throughput high on lossy routes instead of slashing the window the moment a packet goes missing, as classic TCP congestion control does. The costs are just as clear: UDP traffic is rate-limited or deprioritised on some networks; QUIC is implemented in user space, so every packet goes through a user-space copy and a timer check, pushing CPU load above kernel TCP; and on mobile, long sessions drain the battery faster.

TUIC: Multiplexing and 0-RTT on QUIC

TUIC is also built on QUIC, with the emphasis on multiplexing and fast recovery: one QUIC connection can carry several logical streams in parallel, and a client that has already established a session can reconnect with 0-RTT, saving a round trip. Its trade-offs are close to Hysteria2's — whether UDP works on the route sets the ceiling on the experience. On networks where UDP flows freely, TUIC's time to first byte looks excellent; where UDP is throttled, it does worse than a stable TCP route.

The conclusion is plain: on a good route where low overhead matters, Shadowsocks and VLESS fit best; where compatibility and disguise matter, Trojan is steadier; on a badly lossy route, the congestion control in Hysteria2 and TUIC can win back throughput; for long always-on sessions on mobile, kernel-space TCP protocols are kinder to the battery. VPNLW's 230+ routes list the protocols available per region, and once the subscription is imported the client hands out the matching protocol set for each route — no manual configuration assembly required.

From Click to First Byte: What the Handshake Does

How fast a connection feels is decided by two different quantities: time to first byte — the gap between clicking a link and receiving the first byte — and sustained throughput, the speed once data is actually moving. Time to first byte is set by the number of round trips; throughput is set by bandwidth and congestion control. The two get conflated constantly, which is why troubleshooting so often heads the wrong way: the handshake is simply slow, yet the user keeps switching to higher-bandwidth routes.

How Many Round Trips One Request Takes

Break a single page request apart and it goes roughly through the steps below. First, name resolution: if the local cache has no record, one or more round trips are needed to ask DNS; in proxy mode the lookup may be delegated to the remote side, which adds one more exchange between the client and the node. Second, the transport handshake to the node — TCP needs one round trip. Third, the TLS handshake: TLS 1.3 takes one round trip on a full handshake and can reach 0-RTT on resumption. Fourth, the proxy protocol's own negotiation: VLESS and Trojan add essentially no round trips, VMess has to verify the identifier and timestamp, and the QUIC-based protocols take one round trip or 0-RTT. Fifth, the node to the destination, which depends on the physical distance from the exit datacenter to the target and on routing quality. Only sixth does the data come back.

Add those segments up and a familiar pattern explains itself: the first visit to a site is noticeably slow and the second is fast. Not because the route improved, but because the connection pool and the TLS session ticket get reused, so the later requests skip the handshake.

What 0-RTT Saves and What It Costs

TLS 1.3 session resumption lets the client attach application data to the very first flight — that is 0-RTT. QUIC keeps the same mechanism. What it saves is one full round trip, which on a transoceanic route cuts a visible chunk off time to first byte. The cost is replay risk: an attacker on the path can capture that 0-RTT data and replay it, which is why the specification recommends using it only for idempotent requests. Whether a client actually enables 0-RTT depends on the implementation and on local cache state, so it should not be treated as guaranteed. Worth remembering when working out "why is it sometimes fast and sometimes not".

Connection Reuse and Head-of-Line Blocking

Multiplexing packs several requests into one connection and saves repeated handshakes. On TCP, data within a connection is strictly ordered, so when an earlier packet is lost every stream behind it waits for the retransmission — that is head-of-line blocking. QUIC separates the streams at the transport layer, so a loss on one stream does not hold up the others, at the cost of per-stream state and higher memory and scheduling overhead. Whether to turn multiplexing on depends on the workload: with many small requests and a limited connection count the gain is obvious; for a single large transfer it is often steadier with multiplexing off, because there is no competing with other streams for the same window.

Measuring Time to First Byte Yourself

The Network panel in browser developer tools shows the queuing, DNS, connection, TLS and first-byte timings for each request. On the command line you can use curl's per-phase timing:

curl -o /dev/null -s -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer}\n' https://example.com/

Run that command once before and once after the connection is established; the difference is the handshake cost. The example domain is only there to show the syntax — never paste a real subscription URL into an online tool or a public screenshot.

Once this table makes sense, a vague "the route is slow" turns into something precise: if only the first load is slow, the problem is in the handshake and resolution; if every load is slow, it is the number of round trips; if the first byte arrives quickly but the transfer crawls, it is bandwidth and congestion control. The three cases need completely different fixes.

CPU, Memory and Mobile Battery

On desktop, protocol choice mostly affects speed; on mobile it also affects how long the battery lasts. Battery drain is not an abstract number — it comes from how often the CPU wakes, how long the radio is on, and how often memory is allocated and reclaimed. The same subscription can look identical on a laptop and mean one hour versus three hours on a phone.

Hardware Acceleration for Cipher Suites

AES-GCM is a hardware instruction on x86 processors with AES-NI and on mobile chips with the ARMv8 crypto extensions, so the per-byte cost is tiny. ChaCha20-Poly1305 is the faster option in pure software and therefore wins on older devices without acceleration. Most clients pick automatically based on CPU capability; a few require a manual choice. Switching an older Android device from AES to ChaCha20 sometimes cuts heat and battery drain noticeably — a very cheap adjustment that is often overlooked.

User Space versus Kernel Space

TCP is handled by the operating system kernel, so a packet goes from the network card to the application with only the necessary copies. QUIC is implemented in user space, so every packet involves a system call, a user-space copy and a timer check. On a desktop processor that overhead is negligible; on a mobile processor it turns straight into battery drain and heat. That is why Hysteria2 and TUIC usually last less long than TCP-based protocols during long sessions on a phone. Not because the QUIC protocols are bad — their advantage is on lossy routes and their cost is battery, so the trade-off depends on the scenario.

Heartbeats and Keepalive

NAT devices reclaim idle mappings, so the client has to send periodic heartbeats to keep the channel open. The shorter the interval, the lower the chance of a drop — and the more often the radio wakes up. On mobile the sensible move is a longer interval combined with system-level keepalive; on desktop a shorter interval buys faster recovery. If the connection has to be re-established every time the screen has been off for a while, look at the heartbeat interval before rushing to switch nodes.

Background Keepalive and Power Saving

iOS is strict about background network access: an app that has been in the background for a while gets suspended and the proxy drops with it. Android's power-saving policy restricts background network access too, and the usual symptom is messages that stop arriving a few minutes after the screen locks. The fix is to add the client to the system's battery-optimisation allowlist and permit it to run in the background. This is not optional — it is the precondition for using the service on mobile at all. Step-by-step, screen-by-screen instructions are in the Android guide.

Per-App Proxying Is the Most Direct Battery Saving

Routing only the apps that need it through the proxy cuts three things at once: total traffic, the number of encrypt/decrypt operations, and radio uptime. System updates, app store downloads and local network backups have no business going through an overseas node. Most clients let you tick apps individually, and the setting keeps working once configured. On a plan with a data cap, it also saves a noticeable amount of traffic.

Once these settings are right, the improvement on mobile is often more noticeable than switching routes. The route sets the ceiling; the configuration decides what you actually spend.

Direct, Relay and Dedicated Routes

A route splits into three legs: access from the user to the entry point, the cross-border leg from entry to exit, and the last leg from exit to destination. Only the cross-border leg is something the provider can actively optimise, and that is where route types differ most. Understand this and it becomes clear why two routes in the same city can show similar latency yet behave completely differently at peak hours.

Direct: Shortest Path, Least Controllable Quality

Direct means the node sits overseas and user traffic reaches it straight through the international gateway. The upside is a short path with no extra hops and the lowest latency when the route is in good shape. The downside is just as clear: the cross-border leg is shared with everyone else on the same gateway, and peak-hour congestion is unavoidable. Direct routes work well as a backup, or where latency matters most and some variance is acceptable. Making direct the only choice means betting the experience on somebody else's gateway capacity.

Relay: Swapping an Uncontrollable Leg for a Controllable One

A relay places an entry point closer to the user — Hong Kong or Japan, for example — and the user connects there first, with the entry forwarding along an optimised path to the exit. The value is not a shorter physical distance but replacing the scramble for the shared international gateway with a scheduled backbone path. The entry can also do centralised scheduling: when one exit route congests, traffic moves to another. The cost is one extra hop, so baseline latency is slightly higher than direct, but jitter is usually smaller and the peak-hour drop-off is gentler.

Dedicated: Paying for Predictability

Dedicated lines such as IEPL are provisioned by carriers with explicit service-level commitments on bandwidth and path, and they do not share a queue with public internet traffic. The result is stable latency, low loss and no obvious peak-hour effect. They cost the most of the three, so they are usually offered on selected routes only. To tell whether a route is dedicated, check the label, or run a traceroute and look at the hop count and the networks the cross-border leg passes through. Few hops, a stable path and a cross-border leg confined to a handful of networks usually mean an optimised route.

Latency and Jitter Are Two Different Metrics

Low average latency does not mean a good experience. Video calls suffer from jitter — the variation in latency; large transfers suffer from packet loss, because loss triggers congestion control to shrink the window. Dedicated lines beat the alternatives on those two metrics by a wider margin than on average latency. The familiar report that "the numbers barely moved after switching to a dedicated line, but the calls stopped stuttering" is about jitter.

The recommendation is straightforward: relay is enough for everyday browsing and video; use dedicated for meetings, real-time collaboration and anything with zero tolerance for drops; leave direct for backup and light use. VPNLW's route list labels the route type by region, so you can filter by region on the locations page and compare them one by one.

Latency, Packet Loss and Peak Hours

This chapter explains the three things that come up most often: why latency rises, why packets get lost, and why everything is slower in the evening. Once the causes are clear, most "is the route broken?" questions can be answered without filing a ticket every time.

Latency Has Four Components

First, propagation delay: the time the signal spends travelling through the medium, fixed by physical distance and not optimisable. Second, transmission delay: the time to push the data onto the link, set by bandwidth and packet size. Third, queuing delay: the time spent waiting in router queues, which rises sharply under congestion. Fourth, processing delay: forwarding, encryption and decryption, protocol stack handling. Of the four, only queuing and processing delay leave room for improvement. The floor set by physical distance cannot be broken, which is why a detour is sometimes faster: a path that avoids congested hops can beat the straight line end to end.

Where Packet Loss Comes From

Packet loss usually comes from one of four places. First, queue overflow: a buffer at some hop fills up and later packets are simply dropped. Second, wireless interference: Wi-Fi and mobile networks produce random loss in high-interference environments. Third, rate limiting and policy: some networks throttle specific kinds of traffic and drop whatever exceeds the limit. Fourth, MTU mismatch: packets get fragmented in transit and a lost fragment forces the whole packet to be retransmitted. Each needs a different fix — queue overflow means changing routes, interference means changing how you connect, throttling means changing port or protocol, and MTU problems mean adjusting the client's MTU setting.

Congestion Control Decides What Loss Costs You

Classic TCP congestion control treats loss as a congestion signal and slashes the congestion window as soon as it detects one, so throughput collapses. BBR takes a different view: it continuously estimates the path's bandwidth and minimum round-trip time and paces to those estimates, so loss no longer automatically means slowing down. That is the root reason Hysteria2 does better on lossy routes. Not that it is faster — it reacts to loss differently. Once that clicks, there is no more puzzling over "why does the same node perform so differently after a protocol change".

Why Peak Hours Are Slow

International gateway bandwidth is a shared resource. Evenings are the busy hours: the gateway links fill up, queues grow, queuing delay climbs, and once the queues overflow packets start dropping. The symptoms are latency above its usual level, a higher loss rate, lower throughput, and wide swings within the same hour. This is when dedicated lines and optimised relays prove their worth — they do not compete for the same queue as public traffic on that gateway. If it is only slow in the evening and normal by day, the cause is almost certainly congestion on the shared gateway rather than your local network or the client.

The Limits of Self-Testing

ping uses ICMP, which does not necessarily share a queue with TCP, so a low ping does not mean a fast proxy. Speed test tools measure instantaneous throughput; only repeated samples show stability. The sensible approach is several samples in the same time window, watching jitter and loss rate rather than fixating on a single peak. The speed test server itself can be the bottleneck, so pick a target closer to the exit location for results worth reading.

Keep these five cases in mind and most problems can be pinned to a specific layer before a ticket is ever filed.

Choosing a Protocol by Scenario

There is a fixed order for these decisions: route first, protocol second, client settings last. The route sets the physical ceiling, the protocol sets efficiency on that route, and client settings shape the finer experience. Get the order wrong and you end up cycling through protocols with no improvement, because the bottleneck was never the protocol.

Decision Order

Step one: ask whether the scenario is jitter-sensitive — meetings, real-time collaboration and games are, so dedicated routes come first. Step two: look at loss on the route; if random loss is persistent, the congestion control in QUIC-based protocols can win back throughput. Step three: consider device type and battery constraints; for long always-on sessions on a phone, TCP-based protocols come first. Step four: check whether UDP forwarding is needed — some apps depend on UDP and need both the client and the route to support it.

4K Streaming

4K streaming demands far more sustained bandwidth than 1080p — bitrates usually run in the double-digit Mbps — and it has to be steady, because once the buffer empties the spinner appears. What matters is sustained throughput and route stability, not peak numbers. A TCP-based protocol on a relay or dedicated route is usually steadier than chasing peaks over UDP. If the network throttles UDP, QUIC-based protocols become a liability. The relationship between regional catalogues and exit regions is covered in more detail in the streaming article.

Video Conferencing

Calls are sensitive to latency and jitter and undemanding on bandwidth. Prefer a dedicated route or an optimised relay, and any TCP-based protocol will do. Do not switch nodes mid-call: the switch costs a few seconds of interruption, and a few seconds is enough to cut off someone mid-sentence. If the conferencing app itself uses UDP, make sure the client is not dropping UDP traffic, or you get the classic case of hearing audio but never seeing a shared screen.

Large Files and Backups

On high-bandwidth, high-latency paths the effect of congestion control is magnified. A BBR-style algorithm can fill the pipe, and Hysteria2 has a clear edge here. Watch the data consumption: one full backup can eat most of a month's plan allowance, and a data pack suits that kind of burst far better — it is used up when it is used up and never expires, so there is no need to upgrade the monthly plan for a single month's peak.

Long Always-On Sessions on Mobile

Battery first. Choose a TCP-based protocol, lengthen the heartbeat interval, and turn on per-app proxying. Do not run QUIC-based protocols for long large downloads on a phone — heat and drain both climb noticeably. For messaging and web browsing, light use barely notices the protocol, so pick the most power-efficient combination.

AI Tools and Long-Lived Connections

AI tools stream their responses, and a single exchange can hold a connection open for tens of seconds. Bandwidth demands are modest; stability demands are not — a dropped connection voids the whole answer. A stable route with a TCP-based protocol is more practical than chasing low latency. If answers frequently stop halfway, check route jitter before changing protocols. The help centre has more detailed entries on that troubleshooting path.

Real-Time Competitive Games

Physical distance is a hard constraint and there is only so much a protocol can do. You need UDP forwarding and a route with low jitter. The latency floor for intercontinental play is set by the speed of light, and no protocol gets around it. Setting expectations correctly helps more than cycling through nodes.

Matching plans to scenarios is worth a note too: the ¥9.9 monthly plan includes 60GB and suits light browsing and messaging; ¥18 includes 250GB and covers everyday streaming and work; ¥28 includes 500GB for heavy viewing and several devices at once. Data resets monthly on the activation date, and mid-cycle upgrades are prorated across the remaining days. For sudden heavy use a data pack is better value: ¥158 for 300GB, ¥358 for 1000GB, ¥658 for 3000GB, used up when it is used up and never expiring.

Platform Support and Subscription Import

Once protocol and route are settled, the last mile is the client. The same subscription can behave differently across platforms, mostly because of how much protocol support the core has, the background keepalive policy, and how the proxy takes over traffic. Understanding those three differences saves a lot of confusion over a node that works fine on the laptop and not on the phone.

How the Five Platforms Differ

Windows offers both system proxy and TUN modes; system proxy only affects apps that honour the system setting, while TUN can take over programs that ignore it. macOS has a stricter permission model — enabling TUN the first time requires authorisation and a network extension install. iOS has the tightest background restrictions: the configuration has to be added following the guide, and per-app proxying is limited. Android supports per-app proxying, but the battery policy has to be allowed manually. Linux has both command-line and graphical clients and suits putting the proxy at the routing layer so an entire LAN shares one exit.

Importing a Subscription in Four Steps

Step one: sign in to the user panel and open the subscription page. Step two: copy the subscription link. Step three: in the client, choose import from clipboard or paste the link directly. Step four: after the first import, update once manually and confirm the node list refreshes. With all four done, connect to a route and use any page that reports your exit address to confirm the exit region matches the route you picked.

https://example.com/sub?token=YOUR_TOKEN

The format above is illustrative; the real link comes from the panel after signing in. A subscription link is a credential — anyone who has it can spend your data allowance — so do not post it on public forums or in screenshots. If you suspect it has leaked, reset the subscription in the panel and the old link stops working.

When to Update the Subscription

After node changes, protocol changes or a plan renewal, update the subscription manually in the client once. Some clients support scheduled automatic updates; an interval in the range of several hours is sensible, since pulling more often achieves nothing and briefly leaves the node list unusable during the switch.

No Device Limit, but Shared Bandwidth

A VPNLW subscription has no device limit, and one account works on Windows, macOS, iOS, Android and Linux at the same time. What to keep in mind is that a route's bandwidth is shared: run heavy traffic on several devices at once and the bandwidth available to each drops. At home, scheduling downloads outside peak hours gives a better experience. This is why "unlimited devices" and "unlimited bandwidth" are two different things — the first is a licence, the second is a physical resource.

Clients are downloaded from inside the user panel — sign in and pick your platform. Both the subscription and the clients live in the panel; no static installers are offered on the marketing pages, which keeps versions and account state consistent.

Layered Troubleshooting and Verification

The worst way to troubleshoot is to start by switching nodes. A connection is built up in layers, and a fault at any layer looks like "cannot connect", so eliminating layers one at a time is far faster than trial and error. This chapter gives a procedure to follow and a verification command for each step.

The Six-Layer Model

Layer one is access: is the device online, is the Wi-Fi working, is a captive portal in the way. Layer two is name resolution: does the domain resolve to the right address, or is local DNS hijacking it. Layer three is the transport handshake: can a TCP or UDP connection to the node be established. Layer four is protocol negotiation: does authentication pass, is the clock in sync. Layer five is the routing rules: is this traffic allowed through by the rules. Layer six is the application: is the destination service itself up.

Verifying Each Layer

For access, ping the gateway to confirm the local link. For name resolution, run nslookup against a public resolver and compare. For the transport handshake, use curl's verbose output to see whether the connection is established and TLS completes. For protocol negotiation, read the handshake result in the client log — failures usually carry an explicit error code. For routing rules, compare against global mode. For the application layer, try a different destination to rule out a fault in the target service itself.

ping -c 4 192.168.1.1
nslookup example.com 1.1.1.1
curl -v --max-time 10 https://example.com/
traceroute example.com

Those four commands cover the first three layers. The example addresses are generic — substitute the actual gateway of your own network.

False Faults Caused by Routing Rules

In rule mode some domains go direct and some go through the proxy. If one app fails while others work, switch to global mode and compare: if global works, the rules are at fault; if global fails the same way, the route or protocol is. That single comparison halves the search space and is the biggest time saver available. Rule problems usually come from a mistyped custom rule, an over-broad domain suffix match, or a rule set that has not been updated.

Why Clock Sync Matters

Protocols such as VMess use a timestamp for verification, and a large system clock drift gets the handshake rejected. The symptom is a correct configuration, a node that is online, and a connection that will not come up. Check that automatic time sync is enabled on the device — laptops that sleep for long stretches and older devices hit this most often.

When to File a Ticket

File a ticket only after working through the layers without locating the fault. Include the platform and client, the route in use, the time window when the problem appears, and the verification steps already run with their results. A complete ticket gets resolved noticeably faster because nobody has to go back and forth confirming basics. If the problem only appears at certain times, note the exact times so they can be matched against the records on the route side.

Glossary and Quick Reference

This chapter collects the terms used earlier and adds the service's own specifications for quick reference. The glossary is ordered alphabetically rather than by strict category.

Glossary

Plans and Data Packs

Service Specifications

Coverage: 120+ countries / 230+ routes. Devices: no limit. Platforms: Windows / macOS / iOS / Android / Linux. Payment: Alipay / WeChat / USDT. Refunds: 7-day no-questions refund. Registration: no email address required — a username and password is enough. Encryption: military-grade encryption.

Continue Reading

For a step-by-step first setup, see the getting started guide; to compare tiers and data packs, see plans and pricing; to pick a route by region, see the global route list; common questions are collected in the help centre. Three further articles are worth reading next: a beginner's glossary, regional catalogues and measured 4K bandwidth, and Android background keepalive and per-app proxying.