Protocols and routes
Technical reference

What happens when you open a webpage

When you open a webpage, the app typically looks up the domain, establishes a transport connection, negotiates security and sends a request. Using a proxy adds steps such as routing traffic through the client, connecting to the proxy entry point and forwarding it to the exit. These steps may overlap or reuse existing connections, so the wait you experience is not simply a node's latency. If a page stays blank, the delay may be in DNS lookup. If text appears but images load slowly, image domains may be handled by different rules, or the download may be congested.

It also helps to know how your client handles traffic. A system proxy usually handles only apps that follow the system proxy settings. A virtual network interface can route more traffic, but still depends on system permissions, rules and app behavior. Browser access does not prove that other apps use the same route. Before troubleshooting, check the active mode and confirm that the app is covered by its rules. This helps avoid mistaking a traffic-routing issue for a protocol incompatibility.

Protocols, transports and routes are different choices

A proxy protocol handles authentication, data encapsulation and forwarding semantics. The underlying transport carries data to the other end, while a route describes the actual relationship between the entry point, transit path and exit. A client profile may combine these details in one label, but they remain separate dimensions. The same protocol can run in different regions and topologies, and one region may offer multiple protocols. If you change the protocol, region and entry point at once, you can only tell that the overall combination changed—not which change helped.

Encryption also needs to be understood in layers. An app's HTTPS connection and the encrypted connection between your client and the proxy entry point protect different segments. HTTPS primarily protects data between the app and its destination; the other connection protects the proxy transport link. Encryption can reduce the risk of data being read or altered in transit, but it does not establish whether a destination site is trustworthy or replace account security. Check the source of any subscription, protect your account credentials and never post subscription details containing access credentials in public forums.

Keep a useful record for comparison

A useful record describes which stage the problem occurs at, rather than just saying “the network is bad.” Note whether the client reports a successful connection, whether the destination domain resolves, whether the page is entirely inaccessible or only partly loaded, and whether the problem affects one app or all apps. Also record your network type, selected region, proxy mode and when the issue occurred. These details narrow down the cause and help you tell whether changing routes actually fixed it.

Treat connection tests, webpage access and real-world tasks as separate checks. A client test may contact a specific address or only verify the transport connection; it may not cover an app's login, content loading or persistent connection. If the test passes but the app fails, check the app itself instead of repeatedly running the test. For a complete first-use check, see the Quick Start Guide. The rest of this page explains why different failures call for different adjustments.

Keep the app, network and region fixed, then change one variable at a time. Comparing before and after each change makes it easier to find the cause than applying several optimizations at once.

Shadowsocks: a straightforward proxy protocol

Shadowsocks lets a client and server exchange proxy data using an agreed encryption and encapsulation method. Its basic design is often more straightforward than more layered combinations, but that does not mean every implementation is faster. Encryption algorithms, processor support, client implementation, connection count and the actual route all affect performance. First confirm that your client can read the full subscription. Then check how the target app connects and performs over time, rather than assuming resource use from the protocol name alone.

TCP and UDP support should be checked separately. Web browsing may work without proving that voice or other UDP-dependent apps are supported on the current route. The client may support the protocol but not have the relevant forwarding capability enabled; server support and entry network conditions may also vary. If only certain apps have problems, check whether their required traffic is routed through the proxy and whether your subscription supports it. Don't add mismatched settings to the imported configuration yourself.

VMess: authentication, time and transport combinations

VMess has its own authentication and data-handling mechanisms and is often combined with different transports. What matters to users is whether the client understands the complete configuration—not just the protocol label. Differences in transport, service name, host field or security settings can cause a connection to fail during setup. A successful import only means the configuration was parsed; it does not confirm that remote authentication succeeded. If a connection fails, check the specific stage in the logs and confirm whether the configuration needs updating.

System time is another easy-to-miss factor. Connections that rely on time-based checks may have authentication issues if the device clock is significantly off. Restore normal system time synchronization and check for problems after waking from sleep instead of changing authentication fields at random. Additional transport encapsulation can help support certain deployments, but it also adds steps to negotiate and process. More flexibility and compatibility do not guarantee a shorter wait in every situation.

Trojan and VLESS: where the security layer fits

Trojan deployments commonly rely on TLS to protect transport and use an agreed authentication method to provide proxy access. Certificate validity, domain matching and the system trust chain are therefore important to establishing a connection. Don't treat disabling certificate checks as a long-term fix. It weakens verification of the connection's identity and can hide a configuration error, incorrect device time or wrong entry point. First check the details in your dashboard and the client logs, then decide whether to import the configuration again.

VLESS focuses on lean authentication and forwarding in its base protocol; it does not provide encryption equivalent to an external secure transport layer. Security depends on the full configuration, not the protocol name alone. VLESS can be combined with different transports and security mechanisms, subject to the parameters supported by both the client and server. Some combinations reduce protocol processing but may add handshakes or encapsulation elsewhere. That alone is not enough to conclude that the connection will be faster overall.

These are comparisons of technical categories, not a route-by-route list of VPNUO capabilities. Don't try to substitute a combination that isn't offered in your dashboard by manually changing a protocol name. You need a complete configuration that the client can handle, that matches the entry point and that suits your app. To understand how region and route type affect your choice, read our guide to choosing a route too. This helps avoid attributing every route-quality issue to the protocol.

UDP is a transport, not a speed guarantee

Hysteria2 and TUIC are both related to QUIC and typically use UDP as their transport. QUIC handles connections, encryption and flow control in user space, and can carry multiple data streams over one connection. It does not eliminate the need for reliable delivery; it implements related mechanisms at different layers. So “uses UDP” does not mean “no retransmissions” or “suitable for every game.” Reliability, congestion control and forwarding behavior still depend on the protocol implementation and app type.

When evaluating these protocols, distinguish the outer transport from the inner traffic. A proxy connection carried over UDP may carry reliable data such as web traffic, or forward an app's own UDP datagrams. Establishing the outer connection does not guarantee that every type of inner traffic is handled correctly. Conversely, an app using TCP can still be carried by a suitable QUIC-based proxy. Choose based on the complete forwarding capability and your actual task, not a one-to-one match between app transport and proxy transport.

Hysteria2: tune congestion control and bandwidth settings together

Congestion control—and how data is sent over a lossy or variable path—is a key consideration with Hysteria2. Different configurations and implementations may use different control methods, so don't assume one behavior applies to every deployment. For bandwidth estimates or sending-rate settings, start with the matching values provided by the server and client defaults. Raising estimates blindly does not create capacity; it can increase queuing, packet loss and pressure on your local network, making web and voice tasks harder to use at the same time.

If a network handles UDP poorly, this type of connection may fail to establish or may stall intermittently after connecting. First test it on another access network, then compare it with another transport known to work. If only UDP-based connections are affected, check the entry network or route compatibility. Don't assume the device is underpowered or keep changing several transport settings at once. Being able to switch back to an option suited to the current network is part of reliable use.

TUIC: check multiplexing, connection maintenance and client support

TUIC also uses QUIC capabilities to carry proxy traffic. Multiplexing and datagram handling are key to understanding how it works. Multiplexing lets traffic share an established connection, reducing the need to set up outer connections repeatedly, but shared use does not mean the streams are entirely independent. They still compete for route capacity, congestion windows and device resources. If a background download saturates the upload or download link, chat and browsing may also suffer. Multiplexing alone does not guarantee that every task will remain just as responsive.

Client support must cover the actual configuration, not just show the protocol name in its interface. Security settings, datagram handling and connection maintenance must be compatible with the server. After a device wakes from sleep, switches networks or loses an idle mapping cleared by network equipment, an existing connection may need to be rebuilt. QUIC is designed to handle path changes, but whether a proxy app recovers smoothly also depends on its implementation, system limits and server policy. It does not guarantee uninterrupted service when switching networks.

QUIC-based protocols are worth considering, but keep an alternative route that suits your network. Judge by how your actual task performs over time, not by how new the protocol is.

For a comparison, first check whether basic webpages load, then run a real task and observe what happens when the network changes or the app resumes in the background. If downloads are smooth but voice breaks up, check real-time datagram handling rather than chasing higher download throughput. If a task starts quickly but stalls later, look at queues, connection maintenance and device resources. Record connection setup and sustained performance separately to avoid lumping different causes together as “unstable UDP.”

The benefits and costs of these protocols depend on conditions. User-space processing and encryption consume device resources, maintaining an active connection may increase wireless activity, and congestion control has to adapt to the actual route. Good desktop performance does not necessarily translate to mobile networks. Keep client settings reversible, use the complete subscription provided in your dashboard, and consider battery use, topology and congestion along with protocol choice. That is more useful than comparing protocol labels alone.

A fast connection setup doesn't guarantee fast downloads

“Fast” can mean at least two things: how long it takes to get started and how quickly data keeps flowing. Short tasks may be dominated by DNS lookup, connection setup, security negotiation and the destination's response. Longer tasks are more affected by route capacity, congestion, retransmissions and device performance. A combination that connects quickly may not deliver higher sustained throughput. Conversely, a route that handles large downloads well may feel sluggish when opening small pages if DNS or the handshake takes time. First decide which part you want to improve.

Connection reuse can significantly affect what you observe. Starting the client, switching networks or selecting a new region may require fresh state; repeat visits may reuse DNS cache, security sessions and existing connections. Comparing a new connection with a warmed-up one can make caching look like a protocol advantage. A better approach is to record first and repeat visits separately, and repeat the same kind of task under similar conditions. Don't cherry-pick the smoothest run as a long-term conclusion.

Resource use comes from the whole processing chain

A device handles encryption, decryption, encapsulation, data copying and rule matching. A virtual network interface can add processing between user space and the system network stack. Complex rules, many connections, detailed logs and additional plugins can all use resources, so high process usage isn't necessarily caused by the protocol itself. Compare under the same client mode and similar workloads, then check for background sync, media transcoding or browser activity. Blaming all usage on the proxy process can also obscure the device's real bottleneck.

Processor support for specific encryption operations, client optimizations and system scheduling of background tasks all affect resource use. The same protocol has no fixed performance ranking across devices. If the device gets noticeably hot during sustained transfers, throughput drops as it heats up or other apps become sluggish, consider performance and cooling rather than continuing to switch remote regions. Reducing concurrent tasks, restoring the default log level and using a compatible, simple configuration can make the cause easier to identify.

How to get a useful comparison

Choose tasks that reflect how you actually use the service rather than relying only on throughput tests. For remote work, check document sync and meeting recovery. For AI tools, observe the time from sending a request to the first response, and whether output stalls. For streaming, check startup and recovery after seeking. Use the same destination for each task and record how any failure occurs. If a run is affected by rate limits or a queue at the destination service, it cannot be used by itself to judge the proxy route—let alone draw conclusions about every protocol.

A direct protocol comparison makes sense only when your dashboard offers candidates under similar conditions. If protocols also differ by region and transport path, describe the result as “this combination works better for this task,” rather than claiming to have proved one protocol is better. Acknowledge factors you can't control. The comparison process matters more than a final ranking: it lets you reassess using the same method when you change devices or networks, or run into peak-time congestion.

Choosing a setup is ultimately a balance between experience, compatibility and device load. Everyday light tasks rarely need extra encapsulation just to chase theoretical throughput; for sustained heavy use, don't judge by how quickly the connection starts. Keep settings recoverable, use the client's supported features and avoid tuning unrelated options. If you need to choose a data allowance, see plan pricing. Data allowances and protocol performance are separate considerations.

How wireless activity and background wake-ups use battery

Mobile energy use isn't just about encryption. The wireless module may use power when moving from idle to active, maintaining a connection and handling retransmissions; waking the proxy process can also use power. Even small, frequent transmissions may keep the wireless module active. So observe idle background behavior separately from processing efficiency during sustained downloads. A protocol that uses fewer resources for a large transfer isn't necessarily more power-efficient during long idle periods; the main costs may differ.

Keep-alives help maintain mappings and connection state in network equipment. Sending them too often can increase communication and wake-ups; sending them too rarely can let idle connections expire. The right setting depends on the access network, system background policies and server behavior, so there is no universal value for every device. Start with the subscription and client defaults. Only investigate keep-alive settings if you can reproduce a failure to resume after inactivity; aggressive keep-alives are not a general speed boost.

System limits shape background behavior

iOS places system-level limits on network extensions and background execution, so the client's behavior in the foreground may differ from what happens when the device is locked. Android background restrictions, battery optimization and manufacturer policies may also affect the connection process. Check whether disconnections happen after the screen locks, when switching apps or after system cleanup, then review the system's background permissions. Turning off every battery-saving feature is not a necessary first step. Make the smallest change that addresses the issue and record the before-and-after behavior.

Switching from Wi-Fi to a mobile network can change the device address, routes and network state. Some connections recover; others need to be rebuilt, and the destination app's session may time out. The client can show as connected while the app still needs to send a new request; that does not necessarily mean the proxy is misconfigured. Try reloading the task, then check that the client connection and current network match. Don't confuse a brief recovery issue after a network switch with random drops during sustained transfers.

Compare idle, foreground and weak-signal conditions separately

For battery comparisons, keep screen brightness, app activity, signal conditions and device temperature as similar as possible. A weak signal can make wireless communication more power-hungry, and background sync in the destination app can also change the result. If you change networks as well as protocols, you can't attribute the difference to the protocol. System battery statistics can help identify an unusual process, but they don't always explain the energy cost of a connection. Consider whether the device gets hot, reconnects often or sends data continuously instead of drawing conclusions from a single screenshot.

If idle battery drain seems unusually high, first pause unnecessary automatic tests and frequent updates, then check whether the logs show repeated connection attempts. Constant retries may mean the entry point is unreachable, certificate or authentication checks are failing, or the system keeps stopping the background process. If the device heats up under heavy foreground use, reduce concurrent downloads and check for unnecessary processing. These issues call for different fixes; switching to a protocol with a supposedly lighter name won't solve both.

You can keep one everyday setup and another for specific tasks, but avoid adding rules that are hard to understand just to switch automatically. For everyday use, prioritize connection recovery, background compatibility and acceptable battery use; for large transfers, consider sustained performance. VPNUO supports Windows / macOS / iOS / Android / Linux, with no limit on simultaneously connected devices, but that does not mean every platform will perform the same way. Get clients and import subscriptions through your dashboard. See the Quick Start Guide for the steps.

Direct routes: a direct path isn't always the shortest

Here, a direct route means the client connects to the selected remote entry point without an additional relay arranged by the service provider. This avoids an added forwarding layer, but internet routing is still determined by the networks along the way. Nearby regions on a map may be connected by a detour, while a farther region may have better peering. Geographic distance is a starting point, not a substitute for testing the route with your actual tasks. When choosing a direct route, consider both the path from your access network to the entry point and performance from the exit to the destination service.

Direct routes are usually easier to understand and involve fewer forwarding steps, but they are more sensitive to changes in public-network peering. If performance is usually fine but slows down broadly at certain times, congestion on a shared path may be the cause rather than client settings. Switching protocols on the same path may do little to help. Keep the destination the same, try another entry point or route type offered in your dashboard, and compare the results. Draw conclusions about the specific path you tested, not all direct routes.

Relayed routes: an extra hop can improve connectivity

A relayed route adds an entry point or forwarding node. Traffic first reaches the relay, then continues over another link to the remote destination. An extra hop adds processing and propagation time, but if the onward path is better than the original public peering, the overall experience may still improve. So “more hops always means slower” is not accurate. What matters is the combined effect of the entire route, queuing and forwarding—not simply the number of node names. Consider the quality of the entry point, the link from entry to exit and the path from the exit to the destination site.

Relaying also introduces shared resources and makes faults more complex to locate. Congestion at an entry point may affect several exits, while a problem on one transit segment may affect only some routes. If similar problems occur across several regions that share an entry point, investigate the shared part first instead of assuming all destination regions are affected. Clients usually can't show the entire internal path, so record what you can observe rather than guessing the data center layout. Check your dashboard for the entry point and route mapping.

IEPL dedicated lines: understand the covered segment and what remains

An IEPL dedicated line can provide a more controlled transport path, but it does not cover every step from your device to the destination app. Home Wi-Fi, the access network, public routes beyond the exit and the destination site itself can still affect performance. A dedicated-line label describes how a route is organized; it does not guarantee that every visit will be uninterrupted. When discussing reliability, be clear about which parts may be more controlled and which remain outside the line, rather than turning the capacity of one segment into a promise about the entire service.

A dedicated line also can't resolve account permissions, destination service region policies or queues at the app server. Issues such as being unable to sign in to an AI tool, seeing a different streaming catalog or encountering game server maintenance may have nothing to do with the route. If throughput improves but a feature remains unavailable, check the app layer instead of changing security settings again. See global locations for VPNUO regions and available routes. This page does not assume any specific city, data center or protocol pairing.

When choosing a route, shortlist options suited to your destination region and compare how different topologies perform on real tasks over time. Don't use the number of countries covered as a measure of route quality in a particular country, or keep switching exits based on map distance. VPNUO covers 110+ countries / 160+ routes, giving you options, but check your dashboard for what's actually available. For apps that need to keep a session active, choose a candidate before starting and avoid repeatedly changing exits mid-task.

How packet loss, latency and jitter affect apps

Latency is the time data takes to make a round trip; jitter is variation in that time; packet loss means some data does not arrive as expected. They affect apps in different ways. File transfers can usually recover through retransmission, but may slow down or fluctuate. Real-time voice and games care more about timely delivery: data that arrives too late may be useless even if it is recovered. So a successful download does not prove that a route is suitable for real-time use, and one low reading in a connection test does not show that jitter stayed low throughout a task.

Packet loss does not necessarily come from the remote route. Wireless interference, access device load, background uploads, interface changes and route congestion may all contribute. Some test requests may also get lower priority from network equipment, so loss in a test does not directly equate to packet loss in real traffic. Check whether the actual app stalls, retransmits or reconnects. If the test looks abnormal but the task works normally, note the result and move on. If the task is affected, compare access methods and candidate routes one at a time.

Why performance can slow down at peak times

Peak times usually bring more simultaneous demand for shared resources. A bottleneck may occur on the access network, public peering, relay entry, exit or destination service. When data arrives faster than a link can process it, queues grow, interactive delays increase and severe congestion can cause packet loss. A protocol can change how data is sent and recovered, but it can't create physical capacity. If several apps slow down at once, suspect a shared part of the route before changing settings for each app separately.

Queueing can also happen on a home network. A background backup or sustained upload can slow browsing and calls at the same time, even when the download link appears to have capacity. Pause background traffic and compare interactive performance; if possible, try a wired connection or move closer to your Wi-Fi access point. These inexpensive local checks can help distinguish a Wi-Fi issue from a problem farther along the route. If changing local conditions makes no difference, look at the route and destination service next.

Choose the next check based on how widely the issue occurs

If every app fails, first check that the local network works, then confirm proxy mode, subscription status and entry-point connectivity. If only one app fails, check routing rules, DNS resolution, the destination site and account requirements. If only one type of traffic fails, check UDP or the relevant forwarding support. If the same app works on another network, focus on the access path. If the same action fails across multiple routes, investigate the app or local device state.

When troubleshooting, distinguish “the entry connection is up” from “the request completed.” The client may connect to the proxy service successfully but fail between the exit and destination site. Or transport may work while the app waits for the remote service. Certificate errors, authentication failures, DNS failures and timeouts in logs point to different stages. Record the error type and step where it occurs, not just the final disconnection message. Before sharing diagnostic details, remove usernames, subscription contents and access credentials.

Route tests are clues, not conclusions. Let the scope of the failure guide your checks: local network, traffic routing, connection setup, destination access and sustained app performance.

A path MTU mismatch can also cause confusing stalls: small requests work, large transfers fail, or some content keeps reloading on a particular network. This is only one possible cause, not something to diagnose from symptoms alone. Start with the client's normal automatic handling or default settings and compare another access network. If an adjustment is necessary, follow the client documentation and support advice. Blindly changing fragmentation, buffer or timeout settings adds variables and can make a reproducible issue harder to isolate.

When contacting support, include the device platform, network type, steps to reproduce, candidate region and error type, and say which comparisons you've already tried. Leave out unnecessary personal details, and don't share private conversations from the destination site as proof. Follow up through the support page or a dashboard ticket. You can also check the Help Center for common connection issues. A structured report helps make the next troubleshooting step specific instead of repeating actions you've already ruled out.

AI tools and remote work: prioritize stable sessions

Using AI tools often involves signing in, submitting a request, waiting for generation and receiving an ongoing response. A slow initial response may be caused by connection setup or a queue on the remote service; an interrupted response may involve a long-lived connection, an app timeout or a path change. Keep the region and exit reasonably consistent, then see whether the real task completes. Frequent region changes may trigger additional verification and make comparisons harder. For more on this use case, see our guide to AI access; the result ultimately depends on the destination service and account requirements.

For remote work, test calls, document sync and remote desktop separately. Calls are more sensitive to jitter and recovery, sync to sustained transfer, and remote desktop amplifies interactive delays. Prioritize a combination that works with your client, recovers in the background and completes longer tasks, then compare protocols. Don't keep switching routes during a meeting to chase test readings. Identify a backup option beforehand, switch only when the task is affected and note whether the symptoms changed.

Streaming and gaming: account for app-specific constraints

Choosing a route for streaming is about more than startup speed. Check sustained playback, recovery after seeking and changing shows, and whether the platform's account and regional policies allow the content. Protocols and routes can improve transport, but they don't replace platform authorization or guarantee a particular regional catalog. If playback starts normally but keeps buffering, check throughput and shared traffic. If only one title won't play, distinguish content restrictions from connection issues. See our streaming guide for more.

Gaming depends on timely delivery along the path to the game service, not results from an arbitrary test address. Voice chat, login and gameplay may use different destinations and transports, so check each separately. A global proxy can reroute more traffic than a game needs and may not suit its routing requirements. UDP support alone does not mean a setup is compatible with a particular game. See game boosters vs. proxies. First identify whether the issue is with login, matchmaking or gameplay, then decide whether the current proxy setup is appropriate.

Use a setup you can keep and revert

Start with subscription combinations fully supported by your client. Choose a destination region first, compare route types next, and only then compare protocols under controlled conditions. Once you find a setup that suits everyday tasks, keep a clearly defined backup and note why you'd switch to it. If performance changes after a configuration update, first check that the subscription refreshed completely, then repeat the original task. Don't import rules or settings from unknown sources or combine another service's settings with your current subscription.

Choose a technical setup separately from a plan. VPNUO monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Data resets monthly on the activation date, and mid-cycle upgrades are prorated based on the remaining days. Data packs are ¥158/300GB, ¥358/1000GB and ¥658/3000GB; they remain available until used and never expire. Choose based on your actual usage and habits. A price tier does not guarantee a specific protocol, regional content or performance level. See the plan pricing page for full details.

No email address is required to create an account; just use a username and password. There is no limit on simultaneously connected devices. VPNUO supports Alipay / WeChat / USDT and offers a 30-day money-back guarantee. See the Terms of Service for refund details. These are service terms, not results of a technical test. After reading this guide, check your real use case: can the connection be established, can you reach the destination, does the task continue, and can it recover from an issue? The right setup is the one that works for your device, network and needs.