VPN protocol and route technical guide

Connection layers: pinpoint where the problem occurs

Opening a webpage looks like a simple click, but the request passes through name resolution, rule matching, connection setup, data transfer and application response. A subscription protocol is involved in only some of these steps. If a page takes a long time to appear, DNS lookup may be delayed—or the destination service may be busy. If a download starts quickly but then slows, look more closely at the path carrying ongoing traffic. Separating these stages helps avoid blaming every issue on the node name.

What subscriptions, protocols and routes each do

A subscription gives the client connection details, usually including node addresses, authentication information and related settings. A protocol defines how the client and server identify each other, wrap requests and transfer data. A route is the network path the data actually takes, including access, cross-border transit and the exit. Updating a subscription can fix outdated details, but it does not add capacity to your local network. Changing protocols can alter transport behavior, but it cannot create spare bandwidth at a congested exit.

The client is another independent layer. It reads the subscription, runs the proxy core, matches rules and directs system or app traffic to the appropriate outbound. The same node may use different DNS methods, connection reuse settings or system-level routing in different clients. When comparing results, note the client mode—not just the node. If a browser works but another app does not, first check traffic capture and rule matching before changing routes.

Trace a request along its path

Starting at your device, traffic goes through the local access network to an entry address in the subscription. It may then pass through a relay or dedicated transport segment before reaching an exit that connects to the destination service. DNS resolution may happen on the device, through the proxy or within the app. Different DNS locations can return different addresses, affecting which content delivery network is used. If changing DNS settings changes performance, that does not prove one protocol is faster; the request may simply be reaching a different destination.

Control signals and application data are not the same thing. A client reporting a successful connection usually means a connection or probe completed; it does not verify access to every destination service. An app may also check account region, login status or exit IP characteristics. A network connection can succeed while an app refuses to serve content—that is a different layer of the problem. When troubleshooting, note whether you see a connection timeout, certificate warning, app error or an explicit region message; each points to a different next step.

Separate service coverage from technical conclusions

VPNSon covers 120+ countries / 150+ routes, supports Windows / macOS / iOS / Android / Linux, and allows unlimited simultaneous devices. These facts describe the range of locations and devices available; they do not mean every route has the same physical path or that every client has the same features. Check the global server locations page for current options, and the downloads section of the user panel for the right client for your device. Technical background is not a list of current features.

Describe the issue clearly: which app, which network, where it gets stuck and whether you can reproduce it consistently. A reproducible symptom is more useful for troubleshooting than saying “this protocol doesn’t work.”

As you read the following sections, use the same order of checks: first confirm that traffic reaches the intended destination, then examine how the connection is established, and finally assess ongoing transfers. If traffic capture is misconfigured, detailed protocol comparisons won’t help. This order also applies when the service works but one app does not—and helps avoid introducing noise by switching nodes repeatedly.

Protocol trade-offs: design choices behind the names

Shadowsocks, VMess, Trojan, VLESS, Hysteria2 and TUIC often appear in the same comparison, but they do not all operate at the same abstraction level. Some combine authentication and data protection closely; others rely on an outer secure transport, while some focus on UDP-based connection management. Understanding these differences is more useful than ranking names by speed. Actual results also depend on the implementation, transport combination and network conditions.

Shadowsocks and VMess: encapsulation and authentication

Shadowsocks uses a relatively simple proxy wrapper to relay traffic. Its security properties depend on the cipher suite, authentication method and implementation in use. The name alone does not tell you whether it provides the same replay protection or UDP behavior in every setup. Its direct encapsulation makes the connection path easier to understand, but DNS handling, extra plugins and any additional transport layers enabled by the client still need to be checked separately.

VMess organizes authentication and data transfer information in requests, so the client and server must be configured compatibly. Some authentication flows are sensitive to system time. If the device clock is significantly off, restore automatic time synchronization before cycling through routes. When assessing VMess resource use, include any outer transport: if another connection layer wraps it, the handshake and encapsulation costs are not limited to the protocol itself.

Trojan and VLESS: don’t overlook the outer security layer

Trojan commonly carries authentication and proxy requests over a TLS-protected connection. The certificate chain, server name and server configuration are therefore essential parts of the connection. If you see a certificate error, check the device clock, configuration source and server name; disabling verification is not a routine fix. TLS provides authentication and transport protection for a reason. Skipping verification changes the security boundary.

VLESS uses lightweight authentication and proxy encapsulation. It does not provide a complete encryption layer that can replace secure transport, so it is usually paired with suitable outer protection. VLESS alone does not tell you which transport is in use, or how connection reuse, certificates or UDP forwarding are handled. Consider the protocol, transport and security settings together. If the panel does not show these details, keeping the subscription defaults is usually safer than copying snippets from the web.

Hysteria2 and TUIC: different approaches to UDP

Hysteria2 builds proxy transport on QUIC, and its congestion control and bandwidth settings can significantly affect performance. On lossy paths, it may recover differently from traditional TCP transport—but only if the network allows UDP traffic to flow normally in both directions. Bandwidth settings beyond what your connection can handle may increase queuing and contention, affecting other apps on the same network. Aggressive settings are not the same as optimization.

TUIC also uses QUIC for connections and proxy forwarding, including mechanisms such as multiplexed streams. It is not interchangeable with Hysteria2: authentication details, congestion control and UDP forwarding need to match the implementation. QUIC can reduce some head-of-line blocking between reliable streams, but they may still share connection capacity and congestion state. If the underlying network is unsuitable for UDP, switching to another QUIC-based protocol may not solve the problem.

This guide explains protocol design; it does not rank protocols by default speed. Do not try to enable a protocol that is not in your current subscription by manually changing its name. Both ends must actually support the protocol.

Compare complete setups: client implementation, protocol, outer transport, network route and destination app. A simpler wrapper may reduce some processing, but a busy exit can still slow responses. A more complex transport may reduce waiting on later requests through connection reuse. Once your current setup meets your needs, there is no need to switch just because a protocol name has changed. A configuration you can explain is better for long-term use than a list of untested settings.

Handshakes and transport: fast to connect isn’t the same as fast to download

Connection setup speed measures the wait from the start of a request until it can exchange application data. Throughput measures how much data can be transferred over time. Short webpages, interactive tools and large downloads have different sensitivities to each. A route may handle downloads smoothly but feel slow when opening new pages because of DNS or handshake delays. Another setup may deliver the first byte quickly but have limited sustained capacity; that does not make it the best choice for every use.

Cold connections, warm connections and reuse

A cold connection has to complete the necessary DNS, transport setup and authentication again; a warm connection may reuse an existing channel. When a browser opens the same site repeatedly, connection caching and session resumption can change how long requests take. So a slow first visit followed by faster ones is not unusual, nor does it prove that a setting permanently improved the route. Record first-connection and ongoing performance separately, rather than comparing a newly started client with one that already has an active connection.

Connection reuse can reduce the cost of repeatedly establishing channels, but it also means sharing state. If multiple requests share an outer connection, congestion, a disconnect or receive-buffer limits may affect them all. Whether reuse helps depends on request volume and network quality. It can benefit workloads with many short requests. For a mix of large ongoing transfers and interactive requests, check whether background downloads slow foreground responses instead of focusing only on the reduced connection count.

What TCP and QUIC each do

TCP provides an ordered, reliable byte stream. If data is missing, later bytes may have to wait before they can be delivered to the next layer, even if they have already arrived. Multiplexing several logical tasks over one TCP connection can make them all feel that delay. This describes transport behavior; it does not mean every TCP setup is slow. On networks with little packet loss and mature routes, kernel implementations, hardware offload and years of optimization can all contribute to stable performance.

QUIC combines reliability, encryption and stream management over UDP, allowing separate reliable streams to handle some delivery delays independently. It still needs congestion control, acknowledgements and retransmissions; lost data does not simply disappear. Processing many packets in user space can also increase device overhead. For forwarded UDP traffic, check whether the implementation uses datagrams or wraps them in reliable streams: that choice affects latency, retransmissions and how the app’s own recovery mechanisms interact.

Resource use depends on workload

Protocol processing includes encryption and decryption, memory copies, buffer management, timers and packet handling. Hardware acceleration and how efficiently the client uses system interfaces both affect overhead. A “lighter” wrapper does not automatically mean lower overall battery use. A simple setup that repeatedly fails and retries may consume more power in practice. To assess resource use, keep the transferred content and connection state as consistent as possible, then compare processor usage and system reports.

Settings also have trade-offs. Larger buffers may improve some long-distance transfers, but can use more memory and increase queuing delays. Larger connection pools may reduce setup time, but keep more background state. For everyday use, start with the subscription and client defaults. Adjust options only when you can reproduce a specific issue. If you cannot tell which stage improved after a change, keep a record so you can roll it back—and avoid mistaking a temporary network change for a setting’s benefit.

Network routes: understanding direct, relay and dedicated links

Protocols determine how data is exchanged; topology determines where it goes. A device may connect directly to an exit, or traffic may pass through a relay and different transport segments before reaching one. Labels such as direct, relay and IEPL dedicated line help explain the path, but cannot predict performance on their own. Results also depend on peering between your local ISP and the entry point, cross-border capacity, exit load and routing from the exit to the destination service. A label describes the structure; it does not replace testing.

Direct connections: a simple path isn’t necessarily the shortest

A direct connection usually means your device connects to an overseas entry or exit service without an additional service-side relay in your local region. The structure is easier to understand and depends on fewer relay steps. But network routes do not automatically follow straight lines on a map. ISP peering and routing policies can send traffic on a detour. A geographically closer direct connection is not necessarily faster; if peering from your local network to that region is poor, even a simple path may fluctuate significantly.

For direct connections, first check your local access network, then compare candidate exits. If the same route performs very differently across access networks, the difference may lie in peering before the entry point. In that case, switching to another protocol for the same exit may help less than changing the route. Conversely, if every exit has trouble with just one app, look at the app, DNS and rules rather than blaming the direct connection.

Relays: an extra hop can still reduce detours

With a relay, your device connects to an entry point, which forwards traffic to a later node. This adds network segments and operational steps, but may use better peering and avoid an inefficient detour. “Better” is conditional; a relay is not always better than a direct route. The entry point’s capacity, transport quality from relay to exit and congestion from shared users can all become bottlenecks. Assess the route in the context of your use case and the time of day.

To identify relay-related issues, check whether the problem follows the exit. Nodes in different regions may share a similar entry path and fluctuate together at that stage. If changing regions temporarily fixes things, that does not prove the original exit service failed. The panel usually does not show the complete physical route, so there is no need to guess at internal data center topology. When contacting support, report which nodes fail together and which still work; that is more accurate than claiming a particular backbone segment is at fault.

IEPL dedicated lines: understand which segment is dedicated

IEPL generally refers to an operator-provided dedicated Ethernet transport service and may cover a specific segment of a route. It can make transport paths and capacity easier to plan, but the label does not mean every segment from your device to a website uses a private network. Your local Wi-Fi, access provider, entry capacity and the exit’s connection to the destination service still affect performance. When choosing a dedicated line, consider whether the full route suits your needs rather than treating the name as an end-to-end guarantee.

Also distinguish the entry point’s location from the exit region. Apps generally identify your location from the exit IP, while the connection quality from your device to the entry point affects the first part of the route. A city shown for an exit does not reveal where the entry point is or whether traffic passes through other regions. For location options, check the network page and the current panel details. For a straightforward way to narrow your choices, see the VPN route selection guide: filter by use case, then compare a manageable shortlist.

For everyday use, it’s more helpful to keep candidate routes with different path characteristics than a long list of similar names. If the main route is congested near the entry, switching to another node that shares that segment may not help. When choosing a backup, consider its region, type and actual performance, and note which setup works on your current network. That gives you a clear fallback when performance fluctuates, without random clicking through a long list.

Packet loss and peak-hour slowdowns: how queuing affects reliability

Packet loss does not only happen on remote routes. Wireless interference, busy access equipment, ISP peering congestion, queues at the entry point and exit load can all prevent data from arriving as expected. Higher latency does not necessarily mean more packet loss; data may simply be waiting longer in a buffer. It is important to distinguish “lost” from “late”: the first requires recovery or tolerance for missing data, while the second can make real-time apps unusable even as a download continues.

Why congestion slows interactive traffic

When data arrives at a link faster than it can be sent for a sustained period, the queue grows. It may drop packets once buffer space runs out, but delays can become noticeable even before that. If background syncing or uploads saturate your access network’s upstream capacity, interactive requests and acknowledgements may have to wait, slowing page loads and interrupting calls. Available download capacity does not rule out a local bottleneck: traffic directions and queues can affect each other.

Peak-hour slowdowns usually reflect higher demand for shared resources, whether on a home connection, regional peering or a service exit. A route that works during the day but slows when usage is high is worth noting, but timing alone cannot pinpoint the cause. Recheck different apps and routes at similar times to see whether the issue affects them all. If performance improves when other devices on your home network stop transferring data, address local contention first. If only a particular route is affected, compare routes next.

Retransmission and congestion control are not free fixes

Reliable transports try to recover lost data and adjust sending behavior in response to feedback. Retransmissions use capacity and take time, so a complete download does not mean the route was good. Congestion control aims to balance capacity use against excessive queuing; algorithms respond differently to latency changes, loss feedback and bandwidth estimates. An algorithm’s name is not a performance guarantee. How network equipment treats traffic and whether the route changes frequently also matter.

UDP-based proxies are subject to the same constraints. Some implementations may use a link more aggressively under certain packet-loss conditions, but sending too much can lengthen queues and make interactive traffic and other users on the network suffer. Don’t mask network problems by continually raising bandwidth settings. For video calls, a stable response often matters more than filling the available capacity. For downloads, check whether they affect other work on the device.

Interpret test results in the context of the task

Common network tests may use different destinations, packet types or connection methods from your actual traffic. Network equipment may also handle test packets differently from forwarded application traffic. So if an intermediate hop does not respond to a probe, that alone does not prove it is dropping your traffic. A fast probe to an entry point does not guarantee a smooth route from the exit to an app, either. Treat probes as clues, and interpret them alongside the app’s connection, first response and ongoing transfer results.

During a brief slowdown, reduce concurrent activity and background uploads before retrying the same task. Starting several speed tests at once changes the network conditions you’re trying to observe and makes the results harder to interpret.

Path MTU and fragmentation issues are another common source of confusion. Extra encapsulation takes up packet space, and if the path cannot handle larger packets correctly, small requests may work while larger transfers stall. The same symptoms can also come from an app or destination service, so don’t change system settings on that basis alone. Start with the client’s recommended settings and check whether other candidate routes work. If you need further analysis, give support the steps to reproduce the issue rather than changing several packet-size options at once.

When judging reliability, look at recovery too. After a brief interruption, the client’s reconnection behavior, the app’s retries and any change in exit route all affect the experience. Reliability does not mean no fluctuations ever; it means the task can continue within an acceptable wait. Keep the app’s error message and network conditions from the time of the issue. They are more useful than a single test result and help determine whether to change routes, adjust the client or wait for the destination service to recover.

Mobile battery use: system behavior matters as much as protocols

Battery use on mobile devices depends on the processor, wireless radio, screen, background tasks and system scheduling. Running a proxy involves encryption and packet handling, and can also keep the wireless connection active. A protocol that runs efficiently on a desktop is not necessarily the most power-efficient on a phone. Chip capabilities, network quality, client implementation and workload all affect results; compare on your own device and with your typical use rather than relying on a universal battery ranking.

Keepalives, reconnections and weak signals

Keepalives maintain a route or connection so that intermediate devices do not clear an idle session. Sending them too often can wake the wireless radio more frequently; sending them too rarely may mean rebuilding the connection when you use it again. The right balance depends on network conditions and client behavior. Most users should not disable all keepalives in the name of saving power or copy aggressive settings. First check whether idle connections fail to recover with the defaults, then decide if anything needs to change.

In weak-signal areas, retransmissions and changes in access network conditions can affect battery use more than the protocol itself. When a device switches networks, its address and route may change, requiring some connections to be rebuilt and apps to repeat requests. QUIC has connection migration mechanisms, but whether they work smoothly depends on the specific proxy, client, server and their settings. The protocol name alone cannot guarantee an uninterrupted handoff. Test the network changes you commonly encounter.

System traffic handling changes what the client has to do

A system proxy mainly affects apps that honor those settings, while tunnel mode typically covers a broader range of traffic; exact behavior depends on the system and client. Broader coverage can also send background apps, updates and sync traffic through the proxy, increasing processing and data transfer. That does not necessarily mean the protocol is less efficient; it may simply have more work to do. Before comparing results, make sure traffic handling modes and rules match. In particular, don’t compare a browser-only proxy with a full-device tunnel.

Android background battery management may stop or restrict a client, causing a connection to fail while idle rather than slowing an ongoing transfer. iOS background and network extension behavior is also subject to system scheduling, so a connected status in the interface does not replace testing the destination app. If issues appear after sleep, first check for background restrictions and whether the client restored its tunnel; consider the protocol only afterward. Don’t disable every power-saving feature at once—change only settings related to the reproducible issue.

Compare battery use under the same workload

Keep app content, screen use and network conditions as similar as possible. Compare active use separately from idle standby. Video playback, background downloads and idle messaging are different workloads and shouldn’t be compared directly. System battery reports are estimates by app, not precision measurements; a proxy may carry traffic for other apps, with some of the power attributed to the client. If its share rises, also check total usage, data transferred and whether connections are repeatedly failing.

Consider device temperature and task completion when assessing resource use. If a setup consistently gets hot under the same workload and logs show repeated connection failures, fix the cause of those failures before changing encryption options. If the device gets warm only during large transfers, that may be normal processing load. Reducing unnecessary background traffic and keeping a stable route are often more useful than searching for a protocol name that claims to save battery.

Download VPNSon clients for all supported platforms from the user panel downloads. Import steps and permission prompts vary by platform; see the guide for the overall process. For help preparing an iPhone client and profile, read iPhone clients and configuration profiles. Getting set up first helps distinguish installation or permission issues from performance problems.

Choosing by use case: decide what to compare first

You don’t have to start with protocols. First, identify what your task depends on: web browsing and AI tools benefit from responsive connections and session continuity; long video sessions need sustained transfers; real-time audio and video are sensitive to jitter; downloads need capacity and recovery. Then narrow your options based on UDP support on your network, the location requirements of candidate routes and whether the client handles traffic correctly. Protocol differences become useful to compare only after those conditions are clear.

Web and AI tools: test the full session

Web browsing often involves many short requests, so connection setup, DNS results and reuse all affect the experience. AI tools may also use persistent connections or streaming responses; a page loading does not mean a long session will finish successfully. Check whether sign-in, submitting a request, receiving a continuous response and reloading all work. If only one account feature fails, check the destination service’s account and region requirements instead of treating every app message as a network problem.

For these tasks, start with a region and route that reliably complete the workflow, then compare first-load and ongoing interactions. Avoid switching exits repeatedly during a session: the destination app may revalidate it or ask you to sign in again. Keeping one tested backup route gives you a clear fallback. Suitable connection reuse and reliable handshakes may help, but they cannot replace the destination service’s own capacity or guarantee that every app will remain accessible.

Streaming and downloads: focus on consistency, not peak speed

Video playback depends on a steady flow of data; a brief throughput spike does not show that a long session will play smoothly. Regional catalogs, account permissions, content rights and exit IP detection can also affect what’s available. First confirm that your account can access the content, then check startup time, playback quality and recovery after seeking. See streaming availability for relevant limitations. A route’s region label does not mean every service will provide all content.

For large downloads, look at sustained throughput, resume behavior and the impact on other tasks. If a download saturates your local connection, browsing and calls may slow too. Reduce concurrent activity or limit background transfers before increasing the number of connections. Protocols can handle packet loss and reuse differently, but the download host may also throttle speed. Keep the source the same when comparing routes so differences in server capacity are not mistaken for route performance.

Calls and gaming: check the path the app actually uses

Real-time audio and video depend on timely, consistent delivery; frequent spikes can interrupt a call even when average latency is low. Check whether the client forwards UDP traffic as expected and whether the app uses a different fallback. Gaming also depends on server location, matchmaking region and the game’s own networking design. A general-purpose proxy is not the same as a dedicated gaming route optimizer. See game accelerators vs. VPNs: when to use each for an overview of their different roles.

Using multiple devices also means sharing capacity on a home or office connection. VPNSon allows unlimited simultaneous devices, but that does not give your local network unlimited capacity for concurrent transfers. When devices upload, sync and stream at the same time, traffic can still queue at the access point. Separate important tasks from background activity before changing routes. Technical choices affect connection behavior; plan choices should match how you use data. They are separate considerations.

Monthly subscriptions reset data each month on the renewal date; data packages remain valid indefinitely until used up. See the plans page for prices and allowances. Don’t infer data usage or which plan to choose from a protocol name. If your task is complete and your device is running normally, you can stop comparing. The goal is to get your work done reliably—not to collect protocol labels or use up data running speed tests.

Testing and troubleshooting: change one thing at a time

A common troubleshooting mistake is to update the subscription, switch protocols, change DNS and reinstall the client all at once. Even if things work afterward, you won’t know which change helped, and the same issue may return. Instead, record the current setup, keep a known-working configuration and change one setting based on a clear hypothesis. Repeat the same task after each change to see whether the symptom follows it. Roll back ineffective changes so the configuration stays easy to understand.

Set up a reproducible baseline

Record the operating system, client name, traffic handling mode, node region and route type, and whether you’re using home or another network. For the app, describe the exact action—for example, the page loads but a request fails, or playback starts but stalls after seeking. Keep the original wording of error messages. Don’t lump certificate errors, authentication failures and timeouts together as “can’t connect.” These details help distinguish configuration, transport and application-layer issues.

Confirm the local network works, then check that the subscription updated successfully and that the account and data status meet the requirements for use. If the device clock is significantly off, correct it first—especially if you see an authentication or certificate warning. If the problem started after importing, make sure the client has selected a node from the new subscription rather than an old group. Follow the quick-start guide to check the import and verification steps; there’s no need to start with advanced settings.

Choose the smallest troubleshooting branch that fits

If no nodes can connect, first check client permissions, network access, subscription authentication and system time. If only one type of transport fails, compare other combinations available in the panel and check whether your current network supports UDP. Don’t manually rename a node’s protocol or turn off certificate verification. These are not equivalent substitutions and may break compatibility between the two ends or weaken the original security boundary.

If the browser works but the destination app does not, check whether the app follows the system proxy and whether the rules send it to the intended outbound. If tunnel mode is enabled, confirm that permissions and routing are active. Then check whether the app has its own DNS behavior or connection cache. After switching modes, an old connection may still be open; restart the app’s session to make a fair comparison. Repeatedly changing regions may simply invalidate that session and conceal the actual traffic-handling issue.

If the connection works but speed fluctuates, pause background transfers and see whether the same destination recovers; then compare candidate routes using the same client. If changing routes makes no difference, try another access network to distinguish the local segment from the rest of the path. Keep the task unchanged, and don’t run speed tests alongside it. If only one site is slow, check the destination service and DNS results before assuming the entire subscription is affected.

Before sharing logs, screenshots or troubleshooting notes, remove subscription URLs, authentication details, account passwords and personally identifying information. Full subscription contents are not safe to share publicly for troubleshooting.

Keep useful records, then decide whether to escalate

When contacting support, organize your report around the original setup, steps to reproduce, actual error, comparisons already made and configurations that still work. There’s no need to guess which data center or ISP is responsible, or paste long, unfiltered logs. Share only the relevant information from around the time of the error and say whether it happens consistently or intermittently. Submit your report through a user panel support ticket so follow-up can stay focused on the same issue.

If a setting appears to fix the problem, test it with your usual tasks before calling it a permanent solution. Network conditions, destination services and background load can change; one successful attempt only shows that the setup worked at that moment. Record what you changed and how to undo it, and keep the original working route. For peak-hour issues, test again under similar conditions. For problems after sleep, repeat the sleep-and-resume cycle rather than testing only just after startup.

Keep service details separate from technical diagnosis: VPNSon requires no email address; create an account with a username and password. Supported payment methods are Alipay / WeChat Pay / USDT, and the service offers a 60-day no-questions-asked refund. See the plans page and terms of service for details. The next troubleshooting step depends on the evidence: fix the client for traffic-handling issues, compare routes for path issues, and check the destination service for app-specific requirements. For more common questions, visit the Help Center.