VPN protocols
and network routes

Connection layers and performance limits

Before comparing protocols, break down the entire connection. An app sends a request; the system or client decides whether to route it; the client connects to an entry node, which then connects to the destination service, which returns the content. A slow page could be caused by DNS lookup, connection setup, remote processing, or content transfer. Protocols mainly affect authentication, encapsulation, and transport between the client and node. They don’t replace checks of the other parts of the chain.

Protocols, transports, and routes are different things

Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are different protocol designs. TCP, UDP, TLS, and QUIC describe transport or security mechanisms, which can be combined or depend on one another. Labels such as direct, relay, and IEPL dedicated line describe how a route is organized. Ranking protocol names alongside route types can make improvements from a better entry point look like an advantage of the protocol itself.

A connection may also use application-layer encapsulation. With WebSocket, for example, the client and server must handle data accordingly; with TLS enabled, they must verify certificates and complete a security negotiation. These steps can meet deployment needs, but they can also add work during connection setup. Don’t infer the layers used from keywords in a node name alone; check the client’s actual configuration and logs.

Assess connection setup and sustained transfers separately

Between clicking a link and receiving the first content, the connection may involve DNS lookup, transport setup, security negotiation, and a response from the destination. Sustained downloads depend more on available bandwidth, congestion control, loss recovery, and receiver performance. A protocol that makes new pages respond more quickly isn’t necessarily better for long downloads. Likewise, smooth sustained transfers don’t prove that short requests have low connection setup overhead.

The latency shown by a client usually measures a particular probe, not necessarily the time a real task takes. Results vary depending on the probe target, connection reuse, and whether DNS lookup is included. To assess performance, also check the first response from a real page, continued scrolling, completed uploads, and whether the app keeps reconnecting. Chasing the lowest probe result alone may lead you to an exit route that doesn’t suit the destination service.

Use controlled comparisons, not impressions

For a useful comparison, keep the device, network connection, destination service, and test task as consistent as possible. If you change the Wi-Fi network, client mode, and protocol at the same time as the node, the result only tells you that the overall setup changed—not what caused the difference. A better approach is to hold the route constant while comparing protocols supported by the client, then hold the protocol constant while comparing routes. Note whether a failure occurs during connection setup or sustained transfer.

Also account for cache effects. A page you’ve already opened may load from local cache, and a reused connection doesn’t need to repeat the full negotiation. For a first-visit comparison, confirm that the request actually goes through the selected node. For long-lived connections, don’t switch exit routes mid-transfer. You don’t need elaborate testing tools; what matters is that each observation answers the same question and can be reproduced.

Shadowsocks and VMess: design trade-offs

Shadowsocks and VMess can both carry proxy traffic, but their protocol structures, authentication methods, and implementation ecosystems differ. First check whether your client can fully interpret the subscription parameters—not whether a protocol name is familiar. Server support doesn’t guarantee that your client supports the same encryption method, transport combination, or datagram handling. A successful import doesn’t guarantee that a connection can be established.

Shadowsocks: consider the implementation and encapsulation layers

Common Shadowsocks deployments use a shared key and encrypted transport; their security properties depend on the method and implementation. Its configuration concepts are relatively compact, but implementations may offer different extensions. When considering resource use, distinguish protocol processing from additional plugins: a straightforward base forwarding path doesn’t mean the connection overhead stays the same after adding other layers of encapsulation.

For everyday browsing and document work, client compatibility and reachability of the entry point often matter more than extra features. If your current connection is stable, there’s no need to switch just because another protocol name sounds newer. If something goes wrong, first check that the password or key is complete, the server address is correct, and the subscription is up to date. Then decide whether another protocol is needed, rather than mistaking a configuration error for a protocol limitation.

Check datagram-based tasks separately. UDP traffic from an app may be forwarded directly by the client, handled through a specific encapsulation, or restricted by the current mode. Opening a web page doesn’t prove that voice calls or meetings use a working transport path. If only those tasks fail, check datagram support in the client, network conditions, and node capabilities instead of repeatedly running web speed tests.

VMess: check authentication and transport together

VMess incorporates user identity and protocol authentication into its design, and deployments may combine it with different transports and security layers. Performance depends on the complete combination; not all VMess nodes use the same transport path. Some client configurations may rely on time-based checks, so a significantly incorrect device clock can cause authentication problems. Enabling automatic system time is usually more sensible than editing subscription fields blindly.

Additional encapsulation can suit different deployment environments, but it also adds parameters that must match. If the transport type, path, hostname, or security settings don’t match, the entry point may be reachable while the application connection still fails. Repeatedly changing route regions usually won’t help. Check the first error category in the client log and, as a priority, fetch the complete subscription again to avoid introducing inconsistencies through manual edits.

Protocol names alone don’t predict resource use

CPU use depends on whether the encryption implementation takes advantage of system capabilities, how the client manages connections, and whether detailed logging continues in the background. Background apps, Wi-Fi signal quality, and downloads can also affect battery use. If your device gets noticeably warmer after switching protocols, first keep the workload similar and check for repeated connection failures or unusual retries. Excessive reconnects may be a bigger issue than normal encrypted forwarding.

When choosing between these protocols, favor a combination that imports cleanly, provides clear logs, and works for your tasks. For long-term use, also consider whether the client is easy to update and recover when something goes wrong, rather than judging it by one connection response. The goal is to reduce hard-to-explain failures: configurations should be easy to retrieve from the panel, errors traceable to a specific layer, and everyday tasks consistently completed.

Trojan, VLESS, and TLS configuration boundaries

Trojan and VLESS are often used in deployments that include TLS, but they aren’t simply different names for the same protocol. In common designs, Trojan places proxy authentication and forwarding inside a TLS connection. VLESS separates identity authentication from the transport, so its security properties depend on the outer mechanism actually used. Seeing “TLS” in a node name alone doesn’t confirm that the entire route is configured correctly.

What TLS does—and doesn’t do

When the server’s identity is verified correctly and negotiation is complete, TLS protects data in the connection. It doesn’t automatically increase route bandwidth or guarantee that a destination site will accept the exit address. Security negotiation is part of connection setup, while sustained transfers also depend on network congestion, the client implementation, and the destination service. Treating TLS as a standalone speed boost or stability guarantee goes beyond its purpose.

Certificate verification confirms that you’re connected to the intended server. The server name, certificate validity, and system time can all affect verification. If you see a certificate error, don’t disable verification just to make the client show a successful connection. Check the device date, subscription source, and client compatibility first, then fetch the configuration again. If the problem persists, keep the error summary and describe it in a panel support ticket instead of treating the verification switch as a routine troubleshooting step.

Trojan: distinguish outer security from internal authentication

Trojan connections can fail at different stages. An unreachable entry point indicates a network path issue; a failed TLS negotiation may be related to the server name or certificate; if the secure connection is established but authentication is rejected, check the subscription and access credentials. Calling all of these “node failures” misses useful clues. Look for the earliest failure in the logs; later application errors are often just knock-on effects of the same problem.

Trojan’s resource use depends on the TLS implementation, connection reuse, and workload. For frequent short requests, reusing an existing connection may reduce repeated negotiation; sustained high-volume transfers depend more on the transport path and processing capacity. More reuse isn’t always better: if several tasks share the same underlying connection, congestion there can affect them all. Assess it against the client’s default behavior and real-world performance.

VLESS: a lightweight protocol isn’t a complete security solution

VLESS doesn’t provide content encryption itself, so its confidentiality can’t be assessed separately from the outer configuration. Deployments can use different transports and security mechanisms. A relatively simple protocol header doesn’t mean the complete connection will necessarily use less power, run faster, or be easier to maintain. Evaluate the full connection setup—including client support, identity parameters, transport, and the server’s security requirements—instead of comparing protocol labels alone.

Some combinations also require matching a hostname, path, or other transport fields. They may look like simple text parameters, but they determine whether the connection is handled correctly. A missing character when copying by hand, or parameters taken from another node, can make the entry point reachable while leaving the service unusable. For most users, the complete subscription from the panel is easier to maintain than a manually assembled configuration. Keep a working configuration to roll back to before making changes.

Choose your next step based on where the failure occurs

If all TLS connections fail verification on the same network, first check the local environment and device time. If only one configuration reports an error, update the subscription and check the node requirements. If the connection succeeds but the destination app reports a region or account issue, investigate the exit route and service rules. These decision points help avoid repeatedly switching settings at the wrong layer and make support tickets more actionable than “it doesn’t work.”

For these protocols, use a client that verifies server identity correctly, imports subscriptions directly, and clearly displays errors. Don’t change a working connection just to pursue complex parameters. Changing encapsulation or connection reuse makes sense only when you know whether you’re addressing connection setup, interrupted transfers, or compatibility. Otherwise, more options only widen the troubleshooting scope.

Hysteria2, TUIC, and datagram transport

Hysteria2 and TUIC both use UDP-based QUIC technology, but their authentication, forwarding, and congestion handling differ. QUIC combines secure connections with transport mechanisms and provides streams. It can change some loss-recovery and connection-management behavior, but it can’t eliminate packet loss, congestion, or Wi-Fi signal problems along the route. Understanding when these protocols fit is more useful than equating UDP with speed.

Multiple streams and ordered delivery

TCP provides an ordered byte stream to higher layers, so missing data can delay delivery of subsequent bytes. QUIC can organize independent streams within one connection, allowing data on one stream to proceed without waiting for missing data on another. However, streams sharing a connection still share network capacity and congestion conditions. QUIC reduces some forms of blocking at a specific layer; it doesn’t turn every app into its own independent physical route.

The destination website also has its own transport, separate from the proxy connection. Even if QUIC is used between the client and node, the node-to-destination connection may still use TCP or another method. Improvements to the outer protocol may not fix a slow remote server, an indirect exit route, or packet loss at the destination. When assessing protocol differences, be clear about which segment of the route has changed rather than attributing the entire connection to one transport label.

Hysteria2: match bandwidth parameters to your network

Hysteria2 implementations can use different congestion control strategies, and some configurations include bandwidth-related parameters. These aren’t bandwidth promises from a plan or speed-boost switches where bigger is always better. Settings far above your actual connection capacity may cause queueing, packet loss, or competition with other tasks. Start with the subscription settings and client documentation. If problems arise, restore the defaults and compare using the same task.

In environments with some packet loss or route variation, this transport may recover differently from traditional TCP-based combinations. But if the network blocks UDP, the client may not complete even the initial handshake. That doesn’t mean the node itself is faulty just because web pages still load. Keep a working TCP-based connection as a comparison and check whether failures are concentrated in UDP-dependent setups.

TUIC: connection management depends on the implementation

TUIC carries proxy traffic over QUIC. Check what the specific client supports for datagrams, connection reuse, and congestion control. Even with the same protocol name, differences in implementation may mean fields aren’t recognized on import or some traffic can’t be forwarded. Choose a client compatible with the configuration provided in the panel. Don’t delete unfamiliar fields and continue testing; they may be required for the connection.

QUIC supports connection migration, but whether proxy traffic continues after a network change still depends on the client, server, and handling of the existing session. Switching Wi-Fi networks can change the exit path and address, and the app may also reconnect. Protocol capabilities alone don’t guarantee uninterrupted video calls, uploads, or remote sessions. Test the actual task you need to use.

On mobile, check reconnects before battery use

UDP and QUIC don’t inherently use less power. Keepalive frequency, packet processing, congestion recovery, and Wi-Fi conditions all affect battery use. If network conditions cause repeated retries, the device may stay active even without a noticeable download. For comparisons, keep screen use and workload consistent, check system battery records, and distinguish client activity from the destination app’s playback and decoding.

Consider these protocols when the conditions are right, not as automatic replacements for every connection. Keep them if the network supports them, the client is compatible, and the same task recovers more effectively. If handshakes often fail or the client keeps reconnecting in the background, favor a stable setup whose behavior is easy to explain and reproduce. Choose protocols to get the job done, not to take on extra maintenance for the sake of a technology name.

Direct, relay, and dedicated-line routing

Route types describe how traffic is carried, not a performance rating. Direct usually means the client connects straight to the relevant entry point; a relay adds a forwarding step; a dedicated line refers to dedicated transport on part of the route. Real-world performance depends on the full path: local access, entry location, cross-region transport, exit network, and destination service. Route names can help guide a choice, but they can’t replace end-to-end testing.

Direct routes: fewer steps don’t guarantee better routing

A direct route has fewer explicit relay steps, but public internet routing doesn’t always follow geographic distance. An exit that looks nearby may still be reached via a complex path. When a direct route works well, configuration and troubleshooting are often more straightforward. If it doesn’t, check connectivity between the local access network and the entry point. A simple route label doesn’t guarantee there will be no queueing or variation at peak times.

Don’t confuse the entry point’s location with the final exit location. Users usually choose a node for the exit region needed by a destination service, but the client first connects to an access endpoint. Some routes have entry and exit points in different locations, so the address resolved by the client alone won’t identify the business exit. Confirm it using the route information in the panel, actual access results, and information shown by the destination platform.

Relay routes: extra steps can improve the path

A relay sends traffic first to a more suitable access point, then forwards it to the exit. It may improve routing for some access networks, but congestion on the forwarding segment can add uncertainty. Extra steps require more coordination of connections and capacity, so a relay isn’t necessarily slower or more stable. Focus on whether your current network can reach the entry reliably and whether the onward route suits your task.

If direct and relay routes to the same exit are both available, keep the task the same and compare connection setup, sustained transfers, and peak-time recovery. If only the relay has issues, the problem may be in the forwarding segment or at that entry point. If both paths have issues, investigate what they share between the exit and destination. This won’t fully diagnose the network, but it can narrow down which part of the route needs checking.

IEPL dedicated lines: understand the transport, then test the service

An IEPL dedicated line usually refers to transport over a dedicated Ethernet line. In a proxy service, the label often describes one segment of the route, not a connection from the user’s device all the way to every destination website. Local Wi-Fi, the access network, and the connection from the exit to the destination may still use public networks. A dedicated line can still be affected by local interference, queueing at the entry, exit congestion, or the destination service.

Dedicated transport can help provide a controlled route, but capacity, maintenance, and traffic scheduling still matter. A dedicated-line label doesn’t establish a bandwidth limit or uptime guarantee that hasn’t been provided. For long work sessions, meetings, or sustained transfers, consider it as an option and test it with the actual task. Switching to a dedicated line may not help if the issue is local signal quality or the destination service.

Understand coverage separately from route availability

GMTVPN covers 100+ countries / 170+ routes. Coverage indicates the range of available network resources; it doesn’t mean every device will perform the same way in every region. See the network page for details. Check the panel for current availability. When choosing a route, first identify the exit region required by the destination service, then compare suitable options instead of switching to an unsuitable region just for a lower probe result.

For troubleshooting, keep a simple route record: local access method, entry route name, exit region, and affected task. Don’t treat a node nickname as a network map or assume a single address lookup reveals the transport used. For questions about route ownership or traffic scheduling, share observed facts with support so any conclusions remain verifiable; don’t infer unconfirmed network structure from labels.

Packet loss and peak-time congestion

Slower performance at peak times often means demand has increased for a shared resource, but congestion can occur anywhere. Possible bottlenecks include local Wi-Fi channels, the access network, entry transport, cross-region links, and exit peering. Packet loss may result from full queues, wireless interference, device limitations, or route changes. Seeing packet loss doesn’t identify its cause, and it doesn’t prove that an entire node or protocol is unsuitable.

How bandwidth, queueing, and response time interact

When data is sent faster than a link can process it, it enters a buffer and waits longer. Downloads may still be flowing, while page loads and meeting audio feel sluggish. If the buffer keeps filling, packets may be dropped, and the transport then retries or adjusts its sending rate. Users often experience a mix of slow responses and fluctuating throughput, not simply a complete disconnect.

Cloud sync, system updates, or uploads from other devices can also create queues. When the upload link is saturated, interactive requests and acknowledgments may be affected. Before troubleshooting, pause unnecessary transfers and check whether other devices on the network are running heavy tasks. If things improve after pausing them, local resource contention is a more likely cause than an international route issue.

Loss recovery involves trade-offs

Reliable transports attempt to recover missing data, but recovery takes time and uses additional bandwidth. TCP’s ordered delivery can make later data wait for a missing segment. QUIC can reduce some delivery blocking between streams, but still has to manage packet loss and congestion. Sending more aggressively doesn’t always help: when a link is congested, extra load can lengthen queues and affect other tasks.

Some network devices may give probe packets lower priority, so packet loss reported by a probe may not match loss during actual use. If a probe looks abnormal but long-lived connections and real tasks work normally, don’t declare the route faulty based on that result alone. Conversely, a successful probe doesn’t rule out a failed connection to a website. The most useful evidence is how a real task relates to the route and time of the issue.

Narrow down congestion one layer at a time

First check whether ordinary network tasks that don’t use the current proxy are also affected. If the local network is unstable overall, start with Wi-Fi signal, router load, and access status. Then keep the client and destination service fixed while comparing entry points, followed by route types under the same exit conditions. If every entry point is slow only for one destination, investigate the service or exit peering instead of repeatedly reinstalling the client.

To compare peak and off-peak performance, keep the task similar. Comparing a cached page opened during the day with a large page loaded for the first time at night won’t show an equivalent change in route performance. Record whether the same task involves waiting, reconnects, or interrupted transfers, and whether switching routes restores it. Keep the notes simple, but include what you were actually doing—not just “it’s slow.”

Change settings only with a clear way to roll back

Congestion control, connection reuse, and bandwidth parameters affect sending behavior, but it’s usually not helpful to change them all at once when the cause is unclear. Keep the original configuration, change one setting at a time, and test again. If there’s no consistent improvement, restore the original value. A one-off speed increase may be due to changing shared network load, not an effective setting. A change is worth considering only when it produces repeatable improvement under similar conditions.

For long-term use, prioritize routes with acceptable variation and a clear recovery process over brief peak speeds. If problems persist at peak times, submit a panel support ticket with your access network, route name, affected task, time, and error summary. Don’t include the full subscription or authentication details. Support needs facts that help locate the affected route; they’re more useful than an isolated speed-test screenshot.

Connection stability and mobile battery use

A stable connection isn’t just a client icon that always says “connected”; it means the destination task keeps working and recovers appropriately when the network changes. Mobile devices are also affected by background restrictions, changing wireless signals, and system battery policies. An app remaining open doesn’t mean its network activity is working properly in the background, and a temporarily unavailable app doesn’t necessarily mean the proxy connection has dropped. Consider the client status, system status, and actual task together.

First distinguish connection failures from task failures

If the connection fails during setup, check whether the entry is reachable, authentication, and security negotiation. If the client says connected but no tasks work, check the system proxy, traffic-handling mode, DNS path, and routing rules. If only one app is affected, check whether it’s excluded, uses a different transport, or depends on destination-region or account requirements. Issues with different scopes need different troubleshooting steps.

System proxy settings and virtual-network traffic handling don’t cover the same apps. Some apps don’t use the system proxy; in other modes, the client may handle their traffic directly. Existing connections may not move to the new route immediately after switching modes, so the destination app may need to reconnect. Don’t change rules, DNS, and nodes all at once before testing; even if the issue clears, you won’t know which change helped.

Check background settings before blaming the protocol

Android background management and battery restrictions may affect whether the client keeps working. Check the app’s background permissions and battery settings in the system settings; menu names vary by device. Adjust only the apps that need it, then check whether the change resolves reconnects after the screen locks. For background connection maintenance and per-app proxying, see our Android VPN guide.

iOS network extensions are managed by the system, so the status shown in the app may differ from the actual connection state. On Windows, macOS, and Linux, also consider sleep and wake, network interface changes, and interactions with other security software. Troubleshooting across platforms can’t rely on the same menu steps. Focus on the same goals: confirm the client is still working, system traffic is following the expected route, and the destination task can reconnect.

Keepalives and recovery both have a cost

Keepalives help maintain route state, but frequent Wi-Fi wake-ups can increase battery use. Too few keepalives may let some network devices release an idle connection earlier, requiring a new connection for the next request. There’s no single interval that works for every network. Start with the client’s default settings. Only adjust them if you’ve confirmed that idle connections are expiring, and follow the official guidance instead of blindly increasing the send frequency.

For battery comparisons, keep screen use, signal conditions, and workload similar. Video decoding, wireless activity in weak-signal areas, and background content sync can all affect results. System battery stats may also attribute some network use to the destination app. If the client stays highly active, first look for repeated reconnects, verbose logging, or background transfers before deciding that protocol encryption itself is the main burden.

A reconnected link doesn’t restore the original session

Switching routes changes the path and may affect remote terminals, uploads, meetings, and account sessions. Even if the client reconnects automatically, the task may need you to sign in again or resume the transfer. Test candidate routes before important work and try to keep the exit consistent during the task. After a network change, check the destination app itself instead of assuming an operation completed just because the connection icon returned.

When reporting an issue, describe the state change—for example, the connection fails after the screen locks, after waking from sleep, or after changing networks. Keep only the necessary error summary in logs, and remove subscriptions, keys, and personal task data. These notes help distinguish system background restrictions from transport failures and app session problems. Reinstalling repeatedly may hide the cause for a while, only for it to return in the same situation.

Choose and verify based on the task

Start with the task you need to complete, not a protocol name. Check whether the destination service requires an exit region, which combinations your client supports, then compare connection setup, sustained transfers, and recovery from errors. Technically usable doesn’t always mean suitable for the task: a connection that opens ordinary websites may still be poor for long meetings or fail to meet the destination platform’s account or region requirements.

Browsing and work: avoid unnecessary variables

Web browsing, document collaboration, and everyday work usually involve many short requests, and may also reuse long-lived connections. Start with a combination that imports easily, authenticates correctly, and loads pages consistently. If several protocols get the job done, the one that’s easier to maintain is often more practical. Don’t add transport parameters you can’t explain just to pursue a theoretical handshake advantage; more complex configuration means more things to check when something goes wrong.

For AI tools, distinguish network connectivity from platform eligibility. The network can affect page loading, streamed responses, and file uploads, but it can’t replace account status, regional rules, or server-side review. If only one feature fails, keep the exit the same and check the platform’s response rather than repeatedly switching regions and adding variables. For specific use cases, see our AI access guide; assess the connection based on the actual task.

Streaming and meetings: focus on continuity

Streaming depends on sustained transfers and buffer recovery, but playback availability also depends on content region, account status, and platform checks. A connected client doesn’t guarantee that the platform will offer particular content. Test by opening the content you want to watch and checking quality changes, recovery after seeking, and uninterrupted playback. For more on platform requirements, see our Streaming guide. Don’t treat a brief probe result as proof that content is available.

Meetings, voice calls, and remote collaboration rely more on responsive, continuous connections; download speed alone doesn’t capture the experience. Check upload contention, Wi-Fi signal, and datagram support, and avoid running speed tests during meetings. Before using a QUIC-based setup, check that the network and client are compatible. If a TCP-based connection already works well, there’s no need to switch just because a protocol is newer. Keep a tested alternative for important tasks.

Choose a subscription separately from a protocol

GMTVPN supports Windows / macOS / iOS / Android / Linux, with no device limit. Supported devices indicate which platforms are available, not that every operating system uses identical transport implementations. Download clients and subscriptions from the panel download page. Sign in to get a subscription; iOS download eligibility is shown in the panel. No email address is required; create an account with a username and password.

Pricing isn’t a protocol speed setting. Monthly plans: ¥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 for the remaining days. Data add-ons cost ¥158/300GB, ¥358/1000GB, and ¥658/3000GB; they remain valid until used and never expire. Check the plans page for your usage needs; don’t infer unlisted route performance differences from price.

Payment methods are Alipay / WeChat / USDT. The refund summary is a 30-day no-questions-asked refund; see the Terms of Service for full conditions. These are subscription and service-protection details, not guarantees of protocol performance. Before choosing a long-term VPN, read our guide to long-term VPN billing options and assess data needs, configuration maintenance, and actual task performance separately rather than basing every decision on one speed test.

Keep a record you can review

Keep a short record of your main task, target region, access network, client mode, protocol combination, and fallback plan. Recheck the setup with the same task when your usual environment changes. Don’t generalize from one result across every network, or treat an untested node as a reliable backup. A useful configuration makes it clear what to check first when something goes wrong and how to return to a verified setup.

If you’re still unsure where the problem is, start with the quick-start guide to check subscription import and traffic handling, then troubleshoot each connection layer on this page. For support, submit a panel support ticket with notes that don’t include sensitive information. Recording what you observed and where the failure occurred is more useful for finding a connection that suits your setup than labeling a protocol fast or slow.