Protocols & Routes
Technical Guide

Start by checking each layer

Protocols define communication rules, routes define how traffic travels, and the client sends app requests along that route. Check each separately.

Break down the connection

A request typically starts with the app resolving a domain name, then travels through the system network interface, client rules, remote ingress and egress before reaching the destination service. If a page never loads, the issue could be at any stage: name resolution, the handshake, queuing or the app's response. A spinning browser alone cannot tell you whether the protocol is suitable. Before comparing setups, note where the failure occurs: can the client connect to the node, does the domain resolve, does the destination return content, and does the connection hold up during ongoing transfers? These details are more useful for diagnosis than a vague sense of “slow” or “fast.”

A protocol name and its underlying transport are not the same thing. Shadowsocks, VMess, Trojan and VLESS describe their respective proxy and authentication mechanisms, but a real connection also depends on the transport encapsulation, encryption method and client implementation. Hysteria2 and TUIC use QUIC-related mechanisms; understanding them also requires looking at congestion control, connection maintenance and server settings. The same protocol name does not guarantee an identical connection process, and a different name does not mean one option is necessarily more power-efficient or reliable.

Separate capabilities, settings and service commitments

This guide covers general trade-offs in protocol design; it is not a feature-by-feature list of VPNHand's current nodes. A protocol's ability to carry datagrams does not mean every client has that feature enabled, and a route suited to sustained transfers does not mean every region uses the same setup. Check the panel subscription and the client display for currently available protocols, ingress, egress and connection methods. Do not infer server parameters from the protocol list, or assume that a general technical capability means a destination site will accept traffic from a particular egress.

Establish a baseline you can compare

A baseline is not the highest speed from a single test; it is a repeatable experience under the same conditions. Keep your current working setup and use the same device, access network and destination to observe connection setup and sustained use. When comparing protocols, keep the egress region and ingress route as similar as possible. When comparing regions, keep the protocol and client settings unchanged. If you change the protocol, egress, resolution method and rules mode all at once, even a better result will not show what caused the improvement—and you will have trouble reproducing it later.

When reviewing client logs, focus on the stage and type of error rather than searching for one specific English term. Authentication failures point to an account or parameter issue; certificate validation failures may involve the domain, device time or trust chain. A connection timeout still needs to be narrowed down to an unreachable ingress or an interruption along the way. Logs may contain account details, subscription identifiers or destinations. Redact them before submitting a support ticket. VPNHand's anonymous, no-logs policy describes the service's privacy practices; it does not replace managing local logs and device access permissions. See the Privacy Policy for details.

Trade-offs in common protocols

First check whether your client fully supports the option, then consider its transport characteristics. Protocol names are useful for categorizing setups, not for ranking their performance outright.

Shadowsocks and VMess: implementation details matter

Shadowsocks focuses on encrypted proxy forwarding, with a relatively compact set of core concepts. Its behavior still depends on the cipher suite, transport support and implementation quality, so configurations are not interchangeable based on name alone. It can suit setups with a compatible client where a straightforward connection path is preferred. Check that the client supports the specific method in your subscription and that datagram forwarding meets the app's needs. “Lightweight” describes a design goal, not a universal claim about resource use across all devices and workloads.

VMess includes authentication, encryption and request encapsulation in its protocol mechanisms and is common in established subscription and client ecosystems. Users usually do not need to understand every field, but should make sure the subscription is complete and the client can parse its parameters. An incorrect system clock can interfere with time-based authentication checks, so check the device time when a connection fails. VMess can use different transport encapsulations, and compatibility and processing overhead need to be considered together. The behavior of one encapsulation does not apply to every VMess connection, and there is no need to migrate a working setup just to chase a protocol name.

Trojan and VLESS: distinguish authentication from the protection layer

Trojan typically uses TLS to protect the transport, with proxy requests and authentication handled inside the encrypted channel. Certificate domains, server names and validation status are therefore important troubleshooting checks. A successful TLS connection only confirms that the relevant handshake completed; it does not prove the destination site is reachable. If you see a certificate error, check that the subscription is complete, the device clock is correct and the client is using the right server name. Do not treat skipping certificate validation as a long-term fix; it changes the connection's trust boundaries.

VLESS uses a relatively streamlined proxy protocol structure and should not be understood as providing complete transport encryption on its own. The security layer configured alongside it provides protection, and the transport method and client support matter too. “Streamlined” does not necessarily mean faster: additional encapsulation, remote processing and route queuing can still account for most of the time. Keep the complete security parameters supplied by the subscription; do not combine fields copied from other nodes. A client recognizing the configuration does not mean every optional feature is working correctly.

Hysteria2 and TUIC: consider the datagram path

Hysteria2 uses QUIC for proxy transport and is designed with ways to adapt to high-latency or lossy conditions. Its congestion-control behavior depends closely on the settings. It cannot eliminate wireless interference or insufficient upstream capacity, and the connection may fail if the access network handles UDP in a way that prevents it. Some bandwidth-related parameters affect sending behavior; overly aggressive values can increase queuing and retransmission pressure. Starting with the configuration provided by the service makes results easier to interpret than copying extreme settings found online.

TUIC also uses QUIC's stream and connection capabilities to carry proxy traffic. Its practical benefits depend on the client, server and underlying network working together. Independent streams can limit how a delay in one reliable byte stream affects delivery on others, but congestion control and physical bandwidth are still shared; this does not mean apps cannot affect one another. Maintaining a connection as a mobile network changes also depends on the implementation and operating system. If the access network handles UDP poorly, use another transport option actually offered in the panel and supported by your client instead of repeatedly changing unclear internal settings.

Connection setup and resource use

First response, sustained throughput and device load are different measures. Improving one does not necessarily improve the others.

Why the first page load takes longer

A cold connection may involve domain resolution, a transport handshake with the ingress, authentication and encryption negotiation, a connection from egress to the destination, and the destination app's own response. Once connections are reused, some steps do not need to be repeated, so opening pages consecutively may not reflect the first-connection experience. When comparing results, note whether the client is already running, whether relevant connections are still open and whether the destination content is cached. A slower first visit after restarting the client does not automatically mean route capacity has fallen; the connection may simply need to repeat work that was previously cached or reused.

TCP provides a reliable, ordered byte stream. Lost data must be recovered before later bytes can be delivered in order. QUIC manages multiple streams at the encrypted transport layer, which can limit the direct impact of missing data on one stream's delivery to others. However, all streams still compete for the same route capacity. Handshake optimizations and recovery mechanisms may reduce wait times when conditions allow, but they do not guarantee that the same steps will be skipped on every connection. Session resumption, client implementations and server policies vary, so observed connection times can vary too.

Encryption is not the only processing cost

Client workload also includes rule matching, domain resolution, data copying, datagram processing, the system's virtual network interface and connection management. Complex rules, verbose logs or additional traffic inspection may add more work than the protocol itself. Processing capacity and hardware acceleration also affect the overhead on desktop devices, so do not apply findings from a low-power device directly to another computer. If processor use rises and stays high as transfer speeds increase, check both the client process and system network-related processes, not just the brief peak on one core.

Reuse and encapsulation have trade-offs

Connection reuse can reduce the work of setting up connections repeatedly, but that does not mean every reuse option should always be enabled. Putting multiple requests through one reliable transport channel may let congestion or packet loss in that shared channel affect more requests; incompatible implementations can also cause problems. Transport encapsulation may add buffering, frame processing and forwarding steps. Start with the subscription requirements and the client-recommended settings, then compare them using real tasks. An option being available in the interface does not mean it has been verified with the current node combination.

Interpret memory changes in the context of connection lifecycles. Many concurrent requests can leave connection pools, resolution caches and buffers in use; memory may not return to its startup level as soon as a task ends. Investigate if usage keeps growing under similar workloads or comes with system pressure, connection failures or client exits. For troubleshooting, reduce log verbosity and pause unrelated background tasks, then repeat the same action. Avoid repeatedly clearing caches just to get a smaller-looking number; doing so adds cold-start overhead again and again.

Choose based on the task. Work with many short requests cares more about the first useful response and the cost of reconnecting. Sustained downloads depend more on stable throughput, while real-time interactions are more sensitive to jitter and queuing. Record failures alongside successes in every comparison so you do not keep only the successful results. If the current connection completes the task reliably and the device is not under noticeable strain, keeping a simple, reproducible setup is usually better than stacking on supposed optimizations. Before changing protocols, check whether the bottleneck is really in the client or transport layer.

Mobile power use and network changes

Battery use depends on the wireless link, keepalives, reconnections and processing load. Protocol names alone cannot rank mobile battery life.

Wireless radio and keepalive costs

On mobile devices, power use during transfers is not just about encryption. The wireless radio's transitions from idle to active, maintaining connections and changes in signal quality all affect battery life. Even with little traffic, overly frequent keepalives can repeatedly wake the radio. Too few keepalives may let intermediate networks discard connection state, forcing the next request to establish a new connection. Balance both. Clients and servers generally have suitable defaults; unless you understand what a setting does, do not shorten every interval based on the assumption that “more frequent means more stable.”

Weak signal can lead to more retransmissions, wireless scheduling and connection recovery; device heat does not necessarily mean the protocol is doing too much processing. Background sync, video decoding and screen brightness can also mask the client's own power use. For battery comparisons, keep the task, network conditions and background activity consistent, and observe idle connections separately from active transfers. System battery statistics attribute use over a period; they are not lab-grade protocol benchmarks. A higher share in one session may simply mean other apps used less power, not that absolute battery use increased.

Differences in operating system background policies

Android devices may impose extra background restrictions, so a connection that works in the foreground may drop when the screen is locked. First check whether the client still shows the tunnel as active, then review the system's allowed background activity and battery-saving settings. Do not turn off all system protections. Menu names vary by device; the key is to let the client maintain the connection as needed. For import and permission steps, see the Android VPN setup guide. This page explains why background behavior can change connection results.

iOS manages tunnels through its system network extension. Whether the app is in the foreground does not, by itself, tell you whether the tunnel is working. If requests fail after switching apps, check the system connection status, client notifications and destination behavior together. Desktop systems can have similar issues when waking from sleep: the network interface or address used by the existing connection may have changed, requiring the client to establish a new tunnel. In these cases, switching remote regions alone may not help; first make sure the local network has reconnected properly.

Network changes do not guarantee seamless continuity

When switching from Wi-Fi to a mobile network, the local address, egress route and intermediate connection state may all change. QUIC has mechanisms that support connection migration, but whether a proxy keeps working also depends on the client implementation, operating system behavior, remote settings and underlying reachability. TCP connections generally need recovery after a route change too. A capability in the protocol does not guarantee that an app session will continue without interruption; the destination service's session, upload state or real-time connection may also need to restart after a network change.

For mobile use, start with the client's default settings and check whether foreground use, recovery after locking the screen and network changes all work for your tasks. If only one access network fails, first investigate its datagram path or captive portal. If failures only happen when the screen is locked, focus on background restrictions. After making an adjustment, repeat the same scenario and avoid changing the protocol and battery settings at the same time. The easiest setup to manage is usually one with predictable recovery and clear errors, not simply the one that produced the highest throughput in a short test.

Direct, relayed and dedicated routes

The egress region determines the network location seen by the destination; the route topology determines how a request reaches that egress. One cannot substitute for the other.

A region label is not the whole route

A node's region label can help identify its egress location, but it does not reveal the full route from your device to ingress, from ingress to egress, or from egress to the destination. An egress that appears geographically close may still route through distant exchange points, and the destination service may send the request to another region. Choose a route by considering ingress reachability, the egress region you need and the destination's response—not just map distance. VPNHand covers 100+ countries / 250+ routes. Check the panel for available nodes and current settings.

A direct connection generally means the client connects straight to the remote proxy ingress, making the route easier to understand and avoiding an explicit forwarding step. “Direct” does not mean the physical route is shortest; internet traffic may still cross multiple carrier networks and exchange points. Performance depends on the peering between the local carrier and the remote network, as well as peak-time capacity and routing changes. If a direct route works well for a task, there is no reason to rule it out just because its label sounds basic. Fewer forwarding steps do not guarantee greater reliability either.

Relays and dedicated routes solve different problems

With a relay, the client first connects to an ingress, which then forwards traffic to the egress. This may improve access by using a more suitable peering route, but adds equipment, queues and potential failure points to manage. Whether a relay is worthwhile depends on whether the route benefit outweighs the extra processing costs. If the ingress itself is congested, changing the egress behind that same ingress may not help. If the bottleneck is between egress and destination, changing ingress may not help either. Understanding shared parts of the route helps avoid switching regions without a clear reason.

A dedicated route describes managed transport resources or a peering arrangement. A familiar label does not automatically mean fixed bandwidth, exclusive resources or zero packet loss. Even if one segment uses a dedicated link, the local access segment, ingress processing and route from egress to destination may still use shared networks. When reading a label, ask which segment it describes instead of treating it as an end-to-end guarantee. The current facts do not map VPNHand nodes to specific route types, so this guide does not identify particular regions as direct, relayed or dedicated. See the network routes page and the panel for current details.

How to interpret route information

Traceroute shows control messages returned by devices along the way; it is not a complete picture of the round trip for actual traffic. A hop that does not respond, or responds slowly, may simply give control traffic a lower priority. If the destination responds normally afterward, that hop alone does not prove traffic is being lost there. Return routes may also be asymmetric, so what the client sees is only part of the picture. With an encrypted tunnel, a local probe to the remote ingress also says nothing definitive about the route from tunnel egress to the destination. Keep observations for each segment separate.

When choosing a route, first meet the region requirements of the destination, then compare available ingress points and transport options in that region. Keep one verified route for regular tasks and a backup with a different structure; that is more useful than saving many similarly named options. To tell whether a backup is genuinely different, check whether its ingress or transport changes, not just its display name. If everything is slow, check the local network first. If only one destination is affected, look at the egress-to-destination route. Breaking the route into segments explains why changing regions sometimes helps and sometimes makes no difference.

Packet loss, jitter and peak-time congestion

Lower throughput does not always come with obvious packet loss, and higher latency is not always caused by distance. Queues and recovery mechanisms often combine to shape the experience.

Distinguish queuing from packet loss

When data arrives at a network device faster than it can forward it, the data is queued. A long queue can delay requests even if they eventually arrive, making real-time interactions feel sluggish first. Continued pressure on the queue can lead to dropped packets and retransmissions. Peak-time issues do not necessarily mean the remote server is busy; local wireless conditions, the access link, a peering route or a relay ingress may also be handling more traffic. A capacity shortage on any segment can affect connections that pass through it; a protocol cannot change that segment's actual physical capacity.

A deep buffer may sustain high throughput for large file transfers while making web pages and real-time messages wait longer. This kind of queueing is often called bufferbloat. To diagnose it, check whether interactive use improves when background uploads are paused instead of measuring latency only when the network is idle. Backups, sync tasks and other household devices can create the same problem. Even though VPNHand has no device limit for simultaneous connections, all devices still share local access resources and plan traffic. Device limits and available bandwidth are different things.

Packet loss does not have to occur on an international route

Wireless interference, weak signal, network changes, device processing delays and route congestion can all cause packet loss. Reliable transports try to recover missing data, at the cost of extra waiting and lower throughput; datagram-based apps may instead experience missing frames or choppy audio. QUIC stream isolation can change how blocking affects other streams, but it cannot make lost data reappear. Congestion-control algorithms respond differently to loss and latency: an approach that works well in one environment may cause more queue competition in another.

A path MTU mismatch can cause the unusual pattern where large requests fail but small ones work. If datagrams exceed what a route segment can carry and the relevant feedback cannot get through, the connection may stall during transfer. Do not respond by increasing every buffer size; buffer capacity and the size of a datagram the route can carry are different things. First check for relevant client notifications, restore the recommended settings and compare another access network. If an adjustment is needed, follow the client documentation or support guidance.

Cross-check across times and tasks

To identify peak-time congestion, compare the same task under different network loads instead of attributing every intermittent failure to peak hours. Keep the egress, client and destination the same, record differences between idle browsing and sustained transfers, and check whether pausing local background tasks helps. If all egress options worsen on the same access network, consider a shared ingress or local link first. If only one destination is affected, consider destination-side routing and egress peering. A single number in a route status list is only a clue, not a substitute for testing real traffic.

For streaming, brief throughput peaks may not make up for long pauses. Player buffering, the destination's content delivery node, device decoding and egress access all affect picture quality. If video quality drops, check whether the buffer keeps shrinking, whether other apps are competing for bandwidth, and whether it happens with only one title. See How video quality drops relate to bandwidth, but do not treat one video's performance as a general speed verdict on a protocol.

Before changing congestion-related settings, have a clear hypothesis and a way to roll back. Sending more aggressively does not increase available capacity; it may instead crowd out other traffic and create queues. If you cannot say which behavior a setting is meant to address, it is safer to restore the defaults, try a structurally different route or rule out local contention first. Judge reliability by whether a task completes consistently and failures recover, not by a one-off test peak. Keeping original observations is more useful for troubleshooting than rerunning tests until a result looks good.

Choose a setup for your use case

Choose a combination of client, protocol, ingress and egress. Define what counts as failure for the task before deciding what to optimize.

AI tools and everyday work

Accessing AI tools can involve sign-in, short requests, sustained output and file transfers. Interrupted output may be due to connection recovery, destination load, account status or the request itself; changing the protocol may not help. First check that the destination accepts your region and account, then see whether output remains continuous and whether a network change forces you to resubmit. Keep the same egress during a work session where possible to avoid extra session checks from frequent region changes. For guidance on appropriate use, see the ChatGPT access guide.

Web browsing and document collaboration depend more on consistent responsiveness. Many short requests are affected by name resolution, connection setup and destination app processing; strong download throughput may not improve the initial page load. Start with a configuration that has mature client support and predictable recovery, then test sites you use regularly. If rules send related domains over different routes, the main page may load while attachments fail. Check rules and resolution first; do not replace the entire protocol setup just because one part of a page is blank.

Streaming and real-time interactions

For streaming, check the egress region and how the destination platform responds before looking at sustained throughput. Netflix, Disney+ and similar platforms use their own methods to assess region, account and network conditions, so the same region label does not guarantee the same content or access. Test an actual title for stable buffering and picture quality; opening the home page does not prove playback will work. A protocol can affect transport efficiency, but it cannot override a platform's region and account rules. See the streaming access guide and the Disney+ regional catalog guide.

Voice calls, remote interactions and other real-time tasks are more sensitive to jitter and queuing, and may rely on datagram forwarding. First check that the client and node combination supports the transport the app needs, then look for pauses and recovery during sustained use. Average latency alone can hide sudden queueing, and background uploads can have a significant impact. Reduce local contention first and choose a route that responds consistently to the actual destination. A protocol name in the panel does not mean every real-time app has been tested with it, nor should real-time traffic automatically be tied to one protocol.

Multiple devices and data use

In homes and multi-device setups, separate the plan for consistent settings from traffic management. VPNHand has no device limit for simultaneous connections, but operating system permissions, client capabilities and access networks differ across devices. Copying the same subscription does not guarantee the same experience. Shared access also means keeping the account and subscription secure; do not put access credentials in public chats or screenshots. Reproduce connection issues on the affected device; a working device is only a point of comparison. For common ways to count devices, see the guide to multiple devices and family sharing.

Plan capacity does not change a protocol's technical characteristics. VPNHand monthly subscription data resets each month on the activation date, and mid-cycle upgrades are prorated for the remaining days; data add-ons remain available until used and never expire. Choose a billing option based on how often you use the service, then estimate usage from real tasks rather than guessing from a protocol name. See the plans page for full pricing. Once you have chosen a setup, note your main use cases, preferred combination and conditions for switching. Change routes only when a clear failure criterion is met; repeated adjustments while everything works introduce unnecessary variables.

Troubleshooting and reviewing changes

Narrow the issue down layer by layer, from local access to the destination app. Change one explainable variable at a time and keep a way to restore the original settings.

Check local access and account status first

First check that the local network is connected, whether a network sign-in page needs confirmation in a browser, and whether the system clock is correct. Then check that the client has a valid subscription and that the plan status in the panel is as expected. Do not repeatedly reimport a subscription to work around an incomplete network sign-in, or change protocol settings because of an account issue. Creating an account does not require an email address; a username and password are all you need. If you can sign in but cannot connect, treat account access and the proxy connection as separate steps and record their errors separately.

If none of the nodes can establish a connection, try another transport combination explicitly supported by the client and compare a different access network. If the connection works on another network, the issue is more likely with the original route or its handling of datagrams. If authentication fails on only one node, check whether the subscription is complete and its settings have been manually overwritten. After updating the subscription, select the node again rather than assuming old temporary changes still apply. A client showing the tunnel as active only confirms that the local feature is enabled; make an actual request to verify remote connectivity and egress behavior.

Check the destination after confirming the connection

If you can connect to ingress but the destination will not load, check domain resolution, rule matching and the error returned by the destination. A resolved address does not mean it is reachable from the current egress; a region-related message in the browser does not necessarily mean the protocol has failed. Try an unrelated destination as a comparison to tell a general transport issue from a service-specific restriction. If only sign-in fails, check the account and session. If static content loads but uploads fail, look at the transfer stage, app permissions and request size. Different symptoms call for different troubleshooting paths, not a blanket diagnosis of insufficient speed.

System proxy settings and virtual network interfaces may cover different traffic. Some apps do not follow the system proxy; others use their own resolution or create datagram connections, so the browser may work while a desktop app fails. Check the client's current mode and the route the app's requests actually take, then adjust according to the client documentation instead of enabling multiple network interception tools at once. When several tools change routes and resolution, their settings can overwrite one another. Restore a single, known-working management method first, then add only rules you need.

Share useful, redacted diagnostic details

Include the operating system, the protocol and region shown by the client, access network type, failure stage, original error text and comparisons you have already tried. Instead of saying “it doesn't work,” write “the ingress connection succeeds, but destination sign-in fails; the behavior changes after switching egress.” That gives support a direction to investigate. Hide subscription links, account identifiers and authentication fields before sharing screenshots, and check copied logs for browsing history. Do not share your password or use a real subscription URL in a public example. The goal is to locate the route issue, not collect personal information unrelated to diagnosis.

After each change, repeat the original task that failed and make sure other everyday tasks still work. Verifying that one webpage opens does not prove that file uploads, background recovery and real-time connections work too. Keep the original settings and a note of why you changed them. If an improvement is not repeatable, revert and reassess your hypothesis. Server node and destination platform status can change, so a past success is a reference, not a permanent guarantee. Check whether the task completes and the issue recovers; there is no need to run unrelated tests just to collect more numbers.

Finish by writing a setup note you can maintain: which mode your main devices use, which region each task needs, what triggers a switch and how to verify it afterward. VPNHand offers a 60-day money-back guarantee; see the Terms of Service for details. This is a service guarantee, not a protocol performance metric. Understanding the different layers, keeping variables under control and saving useful comparisons will narrow down issues more directly than repeatedly looking for a supposed one-size-fits-all setting, and make recovery clearer the next time the network changes.