VPN Protocols and Network Routes

CONNECTION MODEL

How Connections Work and What to Check

What Protocols, Transports and Routes Do

A web request doesn't travel in a simple straight line from client to server. An app starts with a destination address; the system or client decides whether to proxy the traffic. The client then connects to an entry point and forwards the request to a remote exit, which accesses the destination service. The protocol handles authentication and request formatting, the transport determines how data travels across the network, and the route determines which carriers and links it crosses. Treating all of this as simply “is this server any good?” can lead to repeated changes in the wrong place.

Two connections using VLESS can use different transports and security layers. Likewise, routes labeled Tokyo may have different entry points and relay paths. A protocol name alone therefore tells you nothing definitive about latency, throughput or which content you can access. Don't switch protocols just because a new one is available. First identify whether the problem occurs during connection setup, sustained data transfer or access to a particular destination. Comparing options is meaningful only once you know which stage is failing.

A fast connection setup doesn't guarantee fast transfers

Opening a web page can involve several sources of delay: DNS lookup, transport handshake, security negotiation and establishing a connection to the destination. The first visit may also incur cache-miss overhead, while later visits may reuse the connection. Comparing a new route on its first visit with an already-warmed route can skew the results. For a fairer comparison, keep the destination, client mode and test conditions consistent, and check the first load, a repeat visit and sustained use separately.

Large file transfers depend more on sustained throughput; calls are more sensitive to jitter and brief packet loss; interactive pages are often affected by request setup time. A fast download and a choppy meeting aren't contradictory: during congestion, queues can keep throughput high while delaying the small packets used for real-time traffic. Start by describing what isn't working instead of reducing every experience to a speed rating. A client's test results also aren't a substitute for the destination website's actual response.

Keep a comparison log you can revisit

Record your region, access network, route name, protocol, client mode and symptoms. Never share account credentials. Record the full route group, even when route names look similar, so you can tell whether the path actually changed. Pause background downloads and keep the destination service and device the same. If a problem occurs, change just one factor at a time—for example, the entry point or the access network. Changing several things at once might fix the issue temporarily, but you'll have no way to tell why or reproduce the result.

This page describes resource use and connection setup time in conditional terms; it doesn't assign protocols a fixed ranking. Implementation quality, hardware encryption support, connection reuse and server load can matter more than protocol differences. If your current connection meets your needs, keeping a compatible setup that's easy to troubleshoot is often the better choice. Make changes only when you can reproduce a specific shortcoming, and target that issue to avoid adding variables just to use a newer-sounding protocol.

First confirm that requests use the intended route, then assess its performance. Incorrect routing that sends traffic directly can't be fixed by changing encryption algorithms.

SHADOWSOCKS / VMESS

Choosing Between Shadowsocks and VMess

Lightweight protocols still need a complete setup

Shadowsocks is built around encrypted proxy forwarding and typically has a straightforward request-encapsulation path. The client and server must agree on the encryption method, credentials and destination request format before forwarding app traffic. Its implementation is relatively compact, making it a common choice when you want less overhead and broad client compatibility. But “lightweight” describes a design preference; it doesn't mean the protocol will use less battery on every device or fix packet loss on your access network.

A real connection may also include a plugin or another outer transport. Adding these layers changes the handshake, compatibility requirements and resource use, so you can't assess the experience based on the simplest setup. When importing a subscription, keep all server-provided settings intact. Don't remove fields just because they look unnecessary based on the protocol name. An encryption-method mismatch usually prevents connection rather than falling back to a slower working mode, and repeated speed tests won't fix incorrect credentials.

VMess identity and time requirements

VMess is a proxy protocol with authentication and request encapsulation that can run over different underlying transports. Its performance depends closely on the client implementation, outer transport and any additional security layer. Calling VMess “slower than another protocol” overlooks these factors: configurations with the same protocol name may use different connection setups and reuse connections differently. Compare the protocol, transport and security settings together—not just the names in your subscription list.

When troubleshooting VMess, check that your device's clock is correct. An incorrect time can affect authentication and outer certificate validation, making it look as if every route has suddenly failed. Turn automatic time synchronization back on, reconnect and check again. Don't change authentication settings at random to work around an error. If the subscription works on another device, check the local device's time, client compatibility and whether the subscription imported fully before assuming the server is at fault.

How to compare without drawing the wrong conclusion

If the service offers different protocols on routes in the same region with similar paths, compare page loads and sustained access on the same network. If the routes use different entry points, results reflect the whole setup—not the protocol alone. Don't compare Shadowsocks on an idle dedicated line with VMess on a congested relay and use that to rank the protocols. Server resources, exit routing and distance to the destination can all change the result; the protocol is just one layer.

For apps that need UDP, confirm that the server, client and local forwarding mode all support the required traffic. Seeing a protocol name in your subscription doesn't mean every app's traffic will be handled as expected. If web browsing works but voice calls don't, check UDP forwarding, routing rules and the app's own connection path. If you only need reliable browsing and document work, a complete import, a well-supported client and smooth access in practice are easier to maintain than manually assembling settings.

This guide doesn't recommend replacing encryption methods or editing transport fields based on advice from a general online article. If the server doesn't have matching settings, local changes will prevent the two sides from negotiating a connection. For help getting, updating and safeguarding your subscription, read the beginner's guide to subscription links. Confirm where your configuration came from and how updates work before comparing performance.

TROJAN / VLESS

Trojan, VLESS and Security Layers

Understand the proxy protocol and encrypted tunnel separately

Trojan typically handles authentication and proxy requests inside a secure TLS connection. These layers have different jobs: TLS provides channel confidentiality and verifies the server's identity, while the proxy protocol specifies the destination and checks access permissions. A certificate validation error and incorrect account credentials can both prevent a connection, but they occur at different stages and need different fixes. Check the error category in your client logs before resetting the entire configuration. This can also prevent an incorrect device clock from being mistaken for a route problem.

VLESS doesn't provide content encryption in its basic request layer; its actual security depends on the security layer and transport settings used with it. So “VLESS is simpler” doesn't mean “there's no need to check security settings.” Nor does seeing TLS in the configuration prove that the entire connection is set up correctly. Verify server identity, client support and the source of subscription settings together. The protocol, transport and security layer need to form a complete setup; the name alone doesn't tell you how secure it is.

Certificates, domain names and system time

When using TLS, the certificate must match the expected server identity. An unverifiable certificate chain, a domain name mismatch or an incorrect device clock can all stop the handshake. Don't disable certificate validation as a routine fix. First check automatic time synchronization, subscription update status and whether the client uses the system's trusted certificates. If the problem occurs only on a public access network, make sure you've completed that network's normal sign-in process before trying to establish a secure connection.

Some subscriptions include a server name for the handshake, a transport path or other settings. These aren't display notes; changing them can affect how the server identifies a connection. If a copied configuration is missing a field, the port may be reachable but the application-level handshake can still fail. Reimport the full subscription instead of guessing settings from the route name. When sharing logs with support, include the error type only; redact identity details, passwords and subscription URLs.

The more layers involved, the more important it is to understand each one

Different transport combinations may add handshakes, request-header handling and connection maintenance. Each has its purpose, but more layers don't automatically mean a more stable connection. For frequent short requests, connection reuse can affect setup overhead; for sustained transfers, underlying congestion and buffering may matter more. A complex configuration isn't proof of better performance, and a short one isn't proof of weak security. Check which security layers and transport behaviors are actually enabled.

Resource use also depends on implementation. Devices with hardware acceleration may handle secure connections very differently from older devices, and forwarding data in user space can affect CPU usage. If the connection works but the device gets hot, first check for verbose logging, frequent route probes or multiple proxy apps. Blaming all extra resource use on Trojan or VLESS can hide the actual work being done on the device.

VPNWhen uses the marketing phrase “military-grade encryption.” For any particular connection, check the client's security layer and authentication status. An encrypted tunnel doesn't replace safeguarding your account, updating your device or using security protections built into the destination website.

When choosing this kind of setup, prioritize compatibility: does the subscription import completely, does the client report missing fields, and can the connection recover reliably? Many combinations are technically possible, but the service provides specific configurations. Following the combination in your subscription is usually easier to control than assembling settings from a generic example. For first-time import steps, return to the quick-start guide.

HYSTERIA2 / TUIC

Choosing a QUIC-Based Transport

Changing transports doesn't bypass congestion control

Hysteria2 and TUIC are both QUIC-based proxy solutions. QUIC provides secure connections, streams and reliable delivery over UDP, so “uses UDP” doesn't mean “no guarantee that data will arrive.” Web browsing still needs reliable byte streams, which must handle loss and ordering. This distinction matters: switching to a QUIC-based solution changes the transport mechanism and implementation strategy. It doesn't make network capacity, queues or wireless interference disappear.

Separate streams can reduce some forms of delivery-level waiting, but streams in the same connection may still share congestion control and link capacity. A stream sending a large amount of data can compete for bandwidth with others. QUIC can't remove queues in an access router or shorten the distance data has to travel. It may help in some lossy environments, but may not establish a connection at all on certain restricted networks. Choose it only if your network supports the transport.

What to Consider with Hysteria2 and TUIC

Hysteria2 settings and implementation involve bandwidth estimates, sending strategies and congestion-control behavior. Misunderstanding bandwidth settings can lead to sending too aggressively or underusing available capacity. Setting a very high value doesn't give the route more capacity. When sharing a network with other devices, excessive upstream traffic can queue interactive requests, making web pages and calls sluggish even while a download continues. Keep the parameters provided by the service; don't copy tuning advice from an unfamiliar environment.

TUIC also uses QUIC to carry proxy requests, but has its own design for authentication, forwarding and implementation. Connection setup, UDP forwarding and congestion behavior depend on client support. The fact that both use QUIC doesn't mean you can swap their settings or assume every client supports the same features. If the protocol is ignored after import, routes are missing or the client reports it as unsupported, check client compatibility instead of copying the route into other groups and trying again.

Limits of QUIC in lossy networks and during mobile handoffs

Random loss from wireless signal fluctuations isn't the same as sustained loss caused by congestion. Some strategies can make better use of the link in the first case, but may increase contention in the second. If switching protocols restores speed but makes other apps noticeably worse, check whether the shared link is saturated. Don't judge the result only by a single download; also watch web browsing, calls and device responsiveness to see whether the improvement simply shifts the wait to another task.

QUIC includes mechanisms that support connection migration, but results depend on whether the client, server and proxy app actually use them and on how the access network changes. This isn't a guarantee of seamless switching between Wi-Fi and mobile data. If you switch networks and the client says “connected” but you can't access anything, have it reconnect first, then check whether DNS and routing rules recovered. A status indicator only reflects one connection stage; it doesn't guarantee that every destination request succeeds.

Treat QUIC-based options as a tested choice or backup, not the only answer. If your access network handles UDP poorly, keeping another compatible transport is more practical. If congestion at the destination exit is the main issue, changing protocols may not affect the bottleneck. When reading the regions and routes guide, consider transport type and route together rather than using the protocol name as a substitute for choosing a complete route.

DIRECT / RELAY / IEPL

Direct, Relayed and Dedicated Routes

The entry region and exit region are different things

A region shown in a route list usually helps identify its exit, but the entry point may be somewhere else. A request can enter through a nearby point, travel over a relay or dedicated line to the destination region, and then reach the service from the exit. The entry affects how well you connect; the exit affects the region and network source the destination sees; the path in between affects sustained transfers. Choosing an exit based only on map distance overlooks entry-point reachability and carrier interconnection. A nearby entry doesn't mean a destination website will respond faster.

A direct route generally means the client connects straight to a remote service entry point, with fewer network hops and a more straightforward deployment. However, public internet routing doesn't always follow the shortest geographic path; carrier interconnection and congestion can affect the result. A direct route may perform well off-peak and fluctuate at certain times. “Direct” doesn't mean low quality, nor does it guarantee low latency. What matters is the full path from your access network to the remote entry point and from the exit to the destination.

A relay changes the route the traffic takes

A relay uses an additional node to send traffic over a different network path. Although this adds a hop, it may avoid a poor interconnection on the original path and improve performance. It may also get worse due to relay load or a longer route. One extra hop doesn't necessarily mean slower, and one fewer doesn't necessarily mean more stable. When troubleshooting a relay route, consider the access-to-relay, relay-to-exit and exit-to-destination segments separately. Don't attribute every pause to the region shown at the end.

IEPL describes a specific type of dedicated network capacity and carriage, not an application-layer protocol. It can work with different proxy protocols, but still depends on the local access network, service entry point, device capabilities and network path from the exit to the destination. A dedicated line can provide a more controlled cross-region route, but won't eliminate home Wi-Fi interference, destination website outages or client errors. It's more accurate to treat it as a routing condition than a promise of speed in every situation.

Check the complete round trip for the app

Real requests travel both ways, and the outbound and return paths may differ. A route trace from the client can't fully reconstruct the return path or pinpoint an intermediate device as the cause of an app failure. Some routers give low priority to trace replies, so a missing reply doesn't necessarily mean real traffic is affected. Treat traces as clues and compare them with sustained responses from the destination app. Don't conclude that a route is down just because an intermediate hop didn't respond.

When choosing Tokyo, Hong Kong or another region, first meet the destination service's regional requirements, then compare the available routes in that region. For content services, region is only one requirement; licensing, account settings and exit-detection policies can affect availability too. Examples in a route list aren't a guarantee of continued access to a specific catalog. For work apps, an exit nearer the service's deployment may help, but test it in actual use rather than guessing from the region name.

VPNWhen covers 100+ countries and 180+ routes. Refer to your subscription and the panel for available groups and current options. For examples by region, visit the servers page. Track region, route type and protocol as separate factors. Switching between different labels for the same path may not actually remove the original bottleneck.

Route optimization can't replace destination availability. Confirm separately that the entry point connects, the exit can reach the destination and the destination app allows access.

LOSS / QUEUE / CONGESTION

Packet Loss, Jitter and Peak-Time Congestion

Distinguish random loss from persistent queueing

Packet loss can come from wireless interference, underpowered access equipment, link congestion or route changes. Apps handle it differently: reliable transports may wait for retransmission, real-time voice may have brief dropouts, and video may temporarily mask the issue with buffering. A frozen video doesn't immediately mean the remote route is dropping packets; local decoding, destination response times and background tasks can look similar. Start by checking which apps are affected at the same time.

Jitter is variation in latency over time. Even if average latency seems acceptable, large short-term swings can disrupt real-time interactions. Queueing is a common cause: when the sending rate exceeds a link's capacity, data builds up in a buffer and later interactive requests must wait. Buffering can avoid immediate packet drops, but may increase latency. So if a large file is still downloading while web pages become unresponsive, check for bandwidth contention before looking for another protocol.

“Peak-time congestion” doesn't identify a single cause

Peak hours mean more people are online, but congestion could be in the home network, carrier interconnection, relay capacity or at the exit. If pausing local sync and downloads clearly helps, check the home network load first. If several devices on the same access network slow down at once and switching networks restores performance, focus on the access path. If only one route has a problem while other routes in the same region work, narrow it down to that route combination rather than the whole service.

A saturated upload is especially easy to miss. Downloads still need to send acknowledgements and control data, and video calls may compete with cloud backups for upstream bandwidth, degrading interactive performance first. Repeated speed tests add even more load and make symptoms harder to interpret. Pause background tasks using the network, then check whether your actual apps recover. Compare routes only after confirming that the shared link has capacity to spare. A testing tool generates traffic too; it's not a neutral observer.

Troubleshoot in a controlled order

First check that ordinary direct access and the local network work. Then check client status and destination routing rules. Next, compare routes in the same region, and only then consider changing the transport protocol. This order doesn't mean protocols are unimportant; it helps rule out conditions with a wider impact first. If multiple protocols share the same entry and exit, switching protocols may leave the entire congested path unchanged. If changing access networks fixes the issue, checking the local network is usually more useful than changing server settings.

If small requests work but large transfers keep stalling, the path may also be handling packet sizes poorly. Encapsulation adds overhead, and problems with path discovery can cause hard-to-spot issues. That doesn't mean you should immediately change the MTU by hand. Restore client defaults first, check for nested tunnels and note whether the problem also occurs on other networks. Lowering the setting at random may mask the issue temporarily or introduce fragmentation and reduce efficiency. Any adjustment should be based on evidence.

When contacting support, include your access region, network type, route name, time of day, affected apps and what changed after switching networks or routes. These details are more useful than “all routes are slow.” Include only necessary error details in logs and redact subscription URLs and identity fields. Don't upload a full configuration containing account credentials. For help, use the support ticket option in the panel; you don't need to share sensitive information publicly to demonstrate the problem.

For more on gaming latency, packet loss and when a proxy is appropriate, read Gaming Accelerators vs. VPNs. Connecting to a game and getting a better network path are separate issues. First check whether the game's traffic actually uses the intended route.

CLIENT / POWER / NETWORK CHANGE

Platform Compatibility and Mobile Battery Use

The same subscription doesn't guarantee the same traffic path

Windows, macOS, iOS, Android and Linux differ in network interfaces, background scheduling and permission models. Even with the same subscription, a client may route traffic through the system proxy, a virtual network interface or its own app-level forwarding. Some apps follow the system proxy; others use their own network logic. So if a browser works but another app doesn't, first check the client's operating mode and routing rules—not just whether the route switch is on.

On desktop, watch for multiple network tools running at once. They may compete over system proxy, routing and DNS settings, creating a complicated path where one program handles requests and another handles DNS. If something goes wrong, close tools you don't need and test again with just one client running. Reimporting a subscription won't clear system settings left by other programs. If access still doesn't work after the client exits, check whether the system proxy returned to its expected state.

Battery use comes from ongoing activity, not just encryption

Mobile battery use involves encryption, user-space forwarding, wireless radio wakeups, keepalives and the app's actual data transfer. Frequent route checks while idle and verbose logging may matter more than differences suggested by protocol names. Many small requests can repeatedly wake the network and processor; large ongoing transfers keep the wireless radio busy. For a useful battery comparison, keep the tasks, screen state and network conditions similar. Don't attribute the difference between watching a video and sitting idle to the protocol.

A weak signal may make the access link consume more resources, and retransmissions add extra work. A hot device doesn't necessarily mean the client algorithm is inefficient; background sync, content decoding or repeated reconnections may be contributing. Check system battery and data usage to find the main source, then see whether client logs show repeated reconnections. If the device heats up only on one access network, testing a more stable network tells you more than immediately changing protocols.

Test idle behavior and network switching separately

When a device sleeps, the system may suspend app activity or change background connection status. After waking, the client may still show the last connection name even though the connection is no longer valid. If access is briefly unavailable after unlocking the screen, check whether a new handshake completes before blaming the route. On Android, check background management as described by your client; don't blindly remove every system restriction. On other platforms too, distinguish a delay caused by system scheduling from a persistent issue with the remote path.

Switching from Wi-Fi to mobile data can change the local address, default route and DNS environment. Depending on its implementation, the client may need to reconnect or migrate the connection. An app may also retain a connection pool that's no longer valid. If browsing works again after the client reconnects but one app remains stuck, try reopening that app before assuming the route is unavailable. Test network switching on its own, not at the same time as background downloads or resuming from sleep.

VPNWhen allows unlimited simultaneous device connections, but devices still share the traffic included in the selected plan; the device limit doesn't mean extra data is included. Download clients through the download section in the panel. Sign in to get your subscription. Clients are available after sign-in on platforms other than iOS; check the panel for iOS availability. For import instructions, see the setup guides for each platform.

When your connection is stable, you don't need to keep switching protocols to chase theoretical battery savings. Reduce unnecessary checks and debugging first, then compare battery use while doing the same tasks.

SCENARIO / VERIFICATION / FALLBACK

Choosing a Protocol and Route for Your Needs

Turn your main task into something you can test

Choose a setup based on what you need to do, not on a protocol list. Web browsing and documents need fast page loads and consistent responses; video needs sustained throughput and buffering; calls need low jitter and minimal brief packet loss; long-running tasks need reliable recovery and a consistent exit. Identify your most common task first, then choose a region and route, and finally confirm which protocol combinations your client supports. A setup that handles your main tasks and recovers easily is usually more practical than a technically complex option that's hard to maintain.

For AI tools, performance can depend on a stable session, your account status and the destination service's regional policies. A successful route connection doesn't mean your account is eligible, and it can't guarantee that a long task will never be interrupted. Choose an exit that meets the service's regional requirements, then test sign-in, a standard request and a sustained session before relying on it for work. Switching exits repeatedly during a task may trigger extra verification, so compare routes before starting important work.

Use different criteria for streaming and real-time interactions

For streaming, first check whether the service accepts your current exit, account region and content license, then test sustained playback. Opening the home page doesn't mean the content you want will play, and a short clip working doesn't guarantee stable playback over a longer session. If the region is wrong, check routing rules and the exit first. If playback keeps buffering, look at route load and local bandwidth contention. Changing protocols to fix a content licensing issue usually targets the wrong layer.

Calls, remote desktops and gaming depend more on stable round-trip performance. Avoid large downloads at the same time and prioritize routes that perform steadily in practice, not just those with high large-file throughput. If the app uses UDP, confirm support in the client mode and on the remote side. If the app's traffic isn't being proxied, comparing protocols won't help. Gaming also depends on the game server's region and any specialized routing. A regular proxy isn't a guarantee of faster gameplay in every game. Read the related networking article for more.

Keep a backup route instead of accumulating configurations

Use your primary route for everyday tasks, and choose a backup with a different entry point, transport or network path. If every backup shares the same bottleneck, adding more won't necessarily help. Keep clear route labels and note which access networks they work on, so you don't face a list of lookalike names during an outage. After a subscription update, check that your primary and backup routes are still available. Don't rely indefinitely on manual configurations that may have been removed. Treat your subscription URL like an account credential; never put it in public notes.

Choose a plan separately from a protocol. VPNWhen monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Data resets monthly on the activation date; mid-cycle upgrades are prorated by the remaining days. Data add-ons are ¥158 for 300GB, ¥358 for 1000GB and ¥658 for 3000GB. They remain available until used and never expire. Choose based on your actual data needs, not on assumptions about a protocol name. See the plans page for full details.

This service offers a 14-day no-questions-asked refund and supports Alipay / WeChat Pay / USDT. No email address is required; create an account with a username and password. Before getting started, follow the quick-start guide to import your setup, then test the region, route and recovery behavior with your usual tasks. If you're still unsure where an issue occurs, send support your access environment, route and symptoms. That makes it easier to get actionable next steps than repeatedly changing every setting.

The best connection isn't necessarily the “most advanced protocol.” It's a setup you can reproduce, understand and recover on your device, access network and destination.