Protocol and Network Route Technical Guide

Understand protocols and routes in a connection

Start with a layered view

Opening a webpage may seem like a single request, but it involves the local app, the operating system's network interface, client rules, the service entry point, and the destination site. The client decides which requests to proxy; the protocol defines how the client and server exchange data; and the route describes the path that data takes. These are related, but they are not interchangeable. Blaming a failed connection on a protocol alone can overlook DNS resolution, routing rules, or local network permissions. Before troubleshooting, identify where the failure occurs so you can choose a verifiable next step.

It's also important to distinguish proxy protocols from their underlying transports. Names such as Shadowsocks, VMess, Trojan, and VLESS describe proxy mechanisms, but a connection may use different transports and security layers. TCP provides an ordered, reliable byte stream; UDP delivers datagrams. QUIC, which runs over UDP, implements its own reliable transport, congestion control, and security handshake. So “uses UDP” does not mean “never retransmits,” and a protocol name alone is not a complete configuration guide.

DNS resolution is another part of the connection that's easy to confuse with the rest. An app may use system DNS or resolve names on its own. A client can handle some resolution, depending on its mode and rules. The resulting IP address may also affect which content delivery location a site uses. If a webpage loads but its images don't, the main connection may still be working; static assets might use a different domain and routing rule. Track the domain, matched rule, and actual exit separately instead of checking only whether the homepage opens.

Separate the entry point, exit point, and destination

The entry point is where your device connects to the service network; the exit point is the network location seen by the destination website. A relay route can have entry and exit points in different regions. A region label usually refers more closely to the exit, but check the dashboard for details. Connecting to a region does not mean your data travels there in a straight line. Carrier peering, routing policies, and traffic scheduling all affect the actual path. A map can help illustrate direction, but it cannot show the real route or its quality.

When a client says “Connected,” it generally means that a connection state or system interface has been established—not that every app is routing traffic as expected. A browser may work while a command-line tool ignores the system proxy; a system network interface may be active while a split-tunneling rule sends an app directly. Conversely, a failed client probe does not necessarily mean every service is unreachable, because the probe target may differ from the real destination. Check the specific app and confirm that it can complete the task you need.

Encryption also needs to be understood within its boundaries. Protection between the client and proxy server does not replace HTTPS in the app; certificate validation by the destination site still matters. Using a proxy also does not grant service account access, content rights, or absolute anonymity. VPN86's no-logs policy is a service privacy commitment; see the Privacy Policy for details. When discussing protocols, consider transport protection, account security, and privacy policies separately rather than relying on a single “encrypted” label.

For your own connection notes, record the device platform, client mode, route name, protocol, and affected app. Don't include subscription URLs, account passwords, or complete authentication fields in screenshots. This preserves the conditions needed to reproduce the issue without exposing sensitive information. The comparisons in the following sections use the same layered approach: identify the issue before changing settings, and confirm the app's route before assessing protocol fit.

Understand the trade-offs of common protocols

Compare their encapsulation and security boundaries

Shadowsocks focuses on lightweight proxying, using a supported encryption method to protect data between the client and server. It has a broad implementation ecosystem and can suit setups that need straightforward proxying, but “lightweight” doesn't mean every implementation uses the same resources. Encryption algorithms, hardware acceleration, connection count, and client core all affect performance. If importing a configuration fails, first check that the encryption method is supported by the client. Matching names alone don't guarantee compatible settings or implementations.

VMess includes authentication and data-protection mechanisms, and its use also involves a transport and related settings. Its value often lies in compatibility with existing configurations and client support, not in any guaranteed speed. Some authentication and verification steps depend on the system clock, so correct the device time before troubleshooting the network if it's significantly off. Don't disable verification to fix a handshake issue, or copy fields from an old configuration into a different protocol without checking them.

Trojan places proxy authentication inside a TLS-protected connection, making the certificate, server name, and TLS settings important to establishing a connection. It can work well with clients that have good TLS support, but the protocol name alone doesn't confirm that certificates are configured correctly. An incomplete certificate chain, a problem with the system trust store, or an incorrect device clock can all prevent a connection before traffic flows. Fix the validation issue rather than enabling certificate-verification bypasses.

VLESS does not provide the same data-encryption responsibilities as VMess; its security depends on the security layer and transport used with it. Its protocol design is relatively lean, but a client label that says VLESS may not show the full combination. Compare the security layer, transport, and server requirements together. Calling VLESS inherently more secure or faster is inaccurate. Encapsulation overhead is worth comparing only when the route, implementation, and workload are similar.

Understand QUIC-based options

Hysteria2 is based on QUIC and uses congestion-control strategies suited to its design goals. It's worth comparing on some high-latency or lossy links, but it can't create physical bandwidth. Overly aggressive settings may increase queueing or compete with other traffic. If the network handles UDP poorly, the connection may fail or become unstable. Before choosing it, check that the network can reach the service and test real tasks rather than relying on protocol marketing.

TUIC also uses QUIC-related mechanisms and organizes connections for proxy use. It makes its own trade-offs around multiplexed streams and datagrams, so it isn't interchangeable with Hysteria2. Results depend on whether the client core supports the required features, the server settings match, and the network can carry UDP reliably. Implementations can differ in connection reuse, recovery, and congestion control. A shared underlying transport doesn't guarantee the same experience.

These descriptions explain technical categories; they don't mean every VPN86 route currently supports every protocol. Compare only the combinations provided by your subscription and supported by your client. Don't edit authentication fields or security settings to “convert” one protocol into another. For available regions and routes, check the Network Routes page, then confirm the options in your dashboard. Narrow your choice to available candidates rather than trying every protocol name.

Compare connection setup and session reuse

Measure first load separately from sustained traffic

Establishing a connection involves several stages: resolving an address, reaching the entry point, completing the transport handshake, authenticating, and connecting to the destination service. Some stages can reuse existing state, while others must be repeated. As a result, the first time you open an app may feel different from continued use. A page that loads slowly just after switching routes but works normally afterward doesn't necessarily indicate congestion; the connection or cache may simply be getting established. When comparing protocols, assess first access and continued use separately rather than collapsing them into a single impression.

TCP- and TLS-based connections are affected by round-trip paths, but you can't estimate exact setup time from a protocol name alone. Session resumption, certificate handling, DNS cache, and whether the client keeps the underlying connection open all affect the process. QUIC combines security handshakes with transport design and has different setup and recovery mechanisms, but using those mechanisms depends on both implementations and the existing connection state. Don't turn a theoretical reduction in exchanges into a speed guarantee for every visit.

Early data is another mechanism with important limitations. Some resumed connections can send data sooner, but this involves replay risks and depends on the task; clients or destination services may not enable it. Most users don't need to turn on advanced options just to speed up connection setup. For form submissions, payments, or other non-repeatable actions, follow the security policies of the app and protocol implementation. A shorter-looking handshake is useful only when compatibility and security boundaries are handled correctly.

Reuse reduces overhead but changes failure patterns

Connection reuse lets multiple app requests share an underlying connection, reducing the overhead of repeatedly establishing new ones—especially for many short requests. But when reuse relies on an ordered, reliable byte stream, other logical requests may be affected while the underlying data waits to be retransmitted. Independent QUIC streams can reduce cross-stream head-of-line blocking, but they still share congestion windows, path bandwidth, and connection state. This addresses a particular kind of blocking; it doesn't eliminate every form of interference.

For apps that use long-lived connections, session continuity matters. AI responses, code completion, remote terminals, and real-time messaging may exchange data again after a period of inactivity. Client keepalives, background restrictions, entry-point timeouts, and local network changes can all affect a session. Loading a webpage successfully doesn't prove these tasks are reliable. Test the actual app workflow, including recovery after idle time, sustained output, and network changes.

When switching between Wi-Fi and mobile data, the device's address and route may change. QUIC supports connection migration, but recovery depends on client support, server settings, and the current NAT behavior. Traditional connections may also recover well through app-level retries. So “supports migration” doesn't guarantee an uninterrupted session. For tasks that need to keep running, check whether the app saves drafts, supports resuming, or can safely retry.

A practical comparison starts by closing background tasks that are using significant bandwidth and confirming that the destination service is working. Then test candidate routes one at a time. Don't repeatedly clear every cache to create conditions unlike everyday use, and don't run multiple speed tests at once. If the connection establishes normally but content keeps stalling, look at throughput, congestion, or the destination service. If it consistently fails before authentication, check settings, device time, certificates, and reachability first.

For Cursor, Copilot, or command-line tools, also check whether the app uses the system proxy, supports the current proxy type, and passes environment settings to extension processes. Network access in the main interface doesn't mean background components use the same route. For more guidance, see our VPN guide for AI coding tools. Checking the app's route and the underlying session separately is usually faster than repeatedly changing protocols.

Assess device resources and mobile battery life

Battery use comes from the entire processing chain

Battery drain on mobile devices isn't an inherent property of a protocol name. Wireless signal strength, screen time, background sync, encryption, packet frequency, and client mode all play a part. With a weak signal, maintaining the wireless connection may cost more power than proxy processing. Frequent small requests can also repeatedly wake network components. Before comparing, check that the device isn't also updating its system, syncing photos, or uploading files; otherwise, it's easy to blame the client for power use caused by other tasks.

Encryption and encapsulation use processing resources, but the actual cost depends on the implementation, hardware acceleration, and data path. Some implementations of lean protocols may use fewer resources, but that doesn't mean every device will show a noticeable battery difference. Repeated buffer copies, excessive rule matching, verbose debug logs, and many concurrent connections can also add overhead. When investigating, consider the system battery report, client activity, and your use case—not just a single screenshot of client resource use.

A system-level virtual network interface can cover more apps, but usually has to handle more packets and domain rules. App-level proxying has narrower coverage, and some programs may not use it at all. This is a trade-off in operating mode, not a simple matter of one being better. Broader handling can be worthwhile when you need consistent routing across the device; for a single app, understand the coverage and avoid unnecessary interception. After changing modes, verify each app's route instead of assuming the modes are equivalent.

Balance keepalives with battery life

Keepalives can help maintain a connection or network mapping, but sending them too often can wake the device and use extra data. Disabling them entirely may make an idle connection slow to recover; increasing their frequency too much may not improve the app experience. Most users should keep the client defaults and consult the relevant documentation only if idle disconnections are a recurring problem. Don't change keepalives, timeouts, reuse, and operating mode all at once—you won't know which change helped.

Android background limits and battery optimization may pause the client, causing delayed messages after the screen locks and recovery when it turns back on. Check background permissions through the system's app settings, keeping in mind that menu names vary by device manufacturer. Grant only the permissions needed to maintain the connection; don't enable everything just to troubleshoot. See our Android client setup guide for general steps, then follow the settings on your device.

On iOS and macOS, the system manages network extensions; connection status can also be affected by system permissions, other network filters, and waking from sleep. Windows and Linux can likewise be affected by sleep and resume, virtual network adapters, and other security software. When multiple tools modify routes or DNS, it's hard to isolate the cause to a protocol. Start by avoiding overlapping network interception and keeping one clearly defined path. Don't delete system components or disable all security protections just to get a temporary connection.

For battery comparisons, use similar signal conditions and task types, keep screen use consistent, and let the device cool down if it has been unusually hot. Large downloads, standby, and continuous conversation are different workloads and shouldn't be compared directly. If a route repeatedly reconnects, connection recovery and wireless wake-ups may use more power even when encryption itself is lightweight. Prioritize a setup that reliably completes tasks and behaves predictably in the background before comparing small resource differences.

Understand direct, relay, and dedicated route topologies

Map the path your data takes

A direct route here means the device reaches a service node over its current internet path, and the node then connects to the destination service. This is different from “direct” in a client's routing rules, which means that a request goes to a website without a proxy. The terms are the same, but their meanings differ. Check the context in the dashboard to avoid mistaking “choose a direct route” for “don't use a proxy,” which could lead you to the opposite conclusion when checking the exit point.

A direct route has a relatively simple structure with fewer forwarding steps; the trade-off is that peering and routing changes across networks can affect performance more directly. A nearby location doesn't necessarily mean a short route, as carrier peering can send traffic on a detour. A direct route that works well on your current network may perform differently on another. Treat home broadband, office networks, and mobile data separately, especially since they may use very different international paths.

A relay route sends device traffic to an entry point first, which then forwards it to an exit point. This lets the path be organized in two parts: from the device to the entry point, and onward from there. If the entry point has good connectivity and the onward route is stable, performance may be better than with a direct route. If the entry point is congested or forwarding resources are limited, relaying may add delay. “Relay” describes the topology; it doesn't guarantee more bandwidth, lower latency, or better streaming compatibility.

A dedicated-route label should refer to a specific link

Dedicated-route terms such as IEPL generally refer to dedicated capacity or controlled interconnection on a particular segment. The overall experience still includes the public network between your device and the entry point, server forwarding, and the path from the exit to the destination. Even if one segment uses a dedicated route, that doesn't guarantee the entire path will be congestion-free. When you see a dedicated-route label in the dashboard, check which segment it applies to and how it performs on your current access network. A label describes route organization; it doesn't replace end-to-end testing.

The relative locations of the entry point, exit point, and destination service all affect performance. To access a service in a particular region, choosing an exit in the same region may not be enough; consider content delivery, account routing, and entry-point quality too. For remote development, connectivity from the exit to a code host or cloud server may matter more than a region label. For video, sustained throughput and the platform's regional rules also play a part. Choosing a region is a starting point, not the end of route optimization.

When comparing topologies, try to keep the exit region and task the same. If you switch from a nearby exit to a distant one and from a direct route to a relay at the same time, you won't know whether the difference came from geography or forwarding. If the dashboard doesn't offer different route types with the same exit, note the limitation rather than forcing a precise conclusion. Choose based on the results of your actual task, but don't generalize limited observations to every route.

VPN86 covers 120+ countries and offers 230+ routes. Check the route list and selection guide for available entry points, exits, and route types. Coverage describes the range of options; it doesn't mean every region has the same topology or that every destination accepts the same exit. First identify the region and reliability your task needs, then compare available options. Keeping a primary route and an alternative that work on your current network is more useful than saving a long list of untested labels.

Understand packet loss and peak-hour congestion

Distinguish link problems from queueing delays

Packet loss means data didn't reach the receiver as expected, but there can be several causes. Wireless interference, link errors, full device buffers, and routing policies can all lead to dropped packets. Congestion occurs when demand on a resource exceeds its current capacity, often causing queueing or packet loss. The two are related, but not synonymous. A link can become slower without obvious packet loss, and wireless problems can cause packet loss without congestion. A single latency reading rarely reveals which mechanism is at work.

Reliable transports detect missing data and retransmit it, adding delay and traffic. TCP and QUIC both have recovery mechanisms, but differ in detection, congestion control, and how data is delivered between streams. Protocols can change how a connection responds to packet loss; they can't fix every underlying link problem. If your Wi-Fi signal is unstable, changing protocols might alter how the issue feels temporarily, but improving the local connection is more direct. First check that the connection between your device and local gateway is working properly.

Excessive queueing can produce a familiar symptom: a download keeps running, but webpage clicks, voice calls, or terminal input become sluggish. A background upload or download may have filled the bottleneck, leaving interactive traffic waiting behind a large volume of data. Switching to a different remote region may not help; pausing background sync, uploads, or updates is a better way to isolate the issue. If things improve after stopping those tasks, local shared bandwidth or queue competition is likely involved—not just the service node.

Peak-hour congestion is a load condition, not a protocol property

Peak hours usually mean that some access, interconnection, or service resources are handling more simultaneous demand. The problem might be on the home connection, carrier peering, service entry point, forwarding segment, or exit—it doesn't automatically point to one place. If performance is fine during the day but slows at night, the timing is useful evidence, but compare other networks and routes too. If switching to another access network on the same device fixes the issue, focus on the original access path. If multiple access networks show problems with the same entry point, investigate entry-point factors.

Congestion control adjusts the sending rate in response to feedback from the path. Being too conservative may leave available capacity unused; being too aggressive can increase queueing and affect other traffic on a shared network. QUIC-based options may behave differently on some impaired links, but more aggressive isn't always better. On a shared home network, account for other devices using video calls or work apps too. A setup that keeps interactions responsive may serve everyday needs better than one that lets a single download consume the whole connection.

Diagnostic tools have limitations. Some network devices give diagnostic packets lower priority, and a router along the path may not reply even while forwarding traffic normally. If a route trace shows an anomaly, compare it with the destination's response and real app behavior. Don't treat a missing intermediate hop as proof of failure, or a single successful probe as a guarantee of ongoing reliability. Repeatable issues such as interrupted output or failed page loads are usually more informative.

To investigate a suspected peak-hour problem, keep the app and exit region fixed, then try a different entry point or topology. Next, keep the route fixed and switch the local access network to see whether the access path is involved. Change only one thing at a time, and record the time and symptoms. If every candidate has problems with just one destination service, check that service's status and account notices too. This turns “everything is slow at night” into a diagnosable issue instead of a pile of conflicting guesses.

Subscription data allowances and moment-to-moment transfer performance are also separate. VPN86 monthly subscription data resets each month on the activation date. The allowance determines how much data is included in the plan; it doesn't describe the instantaneous throughput of a particular route. Data add-ons remain available until used and never expire, but that doesn't mean network conditions will stay the same forever. Keeping these concepts separate helps with plan selection and route troubleshooting: the former matches usage, while the latter addresses paths and service response.

Choose a connection setup for your use case

Start by identifying what your task needs from the network

Everyday browsing involves many short requests. It depends on correct DNS resolution, smooth connection setup, and consistent routing for page assets. A suitable setup usually doesn't require complex manual settings; client compatibility, a stable entry point, and clear rules matter more. If parts of a page are missing, check the asset domains and rules before changing protocols. Replacing a stable setup just because a protocol name is newer may add compatibility work without solving the real issue.

AI chat and coding assistants rely more on sustained sessions, a stable exit, and the app's full network path. Loading a page only confirms access to the entry point; model responses, file uploads, extension background requests, and account authentication may use different service domains. Use an account and region that comply with the platform's rules, and avoid frequently changing exits mid-task. If the website works but the editor doesn't, first check proxy settings for the editor and its extension processes. For more scenario-specific guidance, see the AI Tools feature page.

Streaming depends on sustained throughput, content delivery paths, and the platform's own regional rules. Exit region and visible content don't have a simple one-to-one relationship; account location, licensing, and platform policies also matter. A protocol carries the connection but doesn't grant content rights. Test with an actual video in steady playback and watch for repeated buffering rather than checking only the homepage thumbnail. After switching routes, the playback session may need to reconnect. If the old connection stays open, the exit change may not affect the current stream right away.

Remote terminals, desktop sessions, and real-time collaboration are more sensitive to jitter and brief interruptions. A route with high average throughput can still feel sluggish if queueing delays input. Prioritize responsive interaction and reliable recovery after idle periods, and avoid running other high-bandwidth tasks at the same time. For apps that use UDP, confirm that the client and route support that traffic. If the app protocol isn't supported, switching to a different exit region usually won't help. Specific requirements matter more than a vague goal of being “fastest.”

Consider device compatibility and usage in the right context

Large file transfers depend on sustained throughput, retries, and resume support. Test with the download tool you actually use instead of relying only on a generic speed test. For long tasks, use the app's own verification and recovery features so a route change doesn't cost you progress. If the device has been running hot, client performance may also be a bottleneck. When choosing a protocol, consider local resources, network conditions, and app capabilities together instead of treating one protocol as permanently “for large files.”

VPN86 supports Windows / macOS / iOS / Android / Linux, with unlimited devices. However, platform support doesn't mean every platform has identical client-core features or proxy modes. Clients for Android / Windows / macOS / Linux are available after signing in. On iOS, a valid plan is required to access the download link, and subscriptions are available after signing in. Check the client downloads in the user dashboard. Marketing pages don't provide direct downloads or subscription links.

Choose a plan based on usage, not assumptions about protocol performance based on price. Monthly subscriptions are ¥9.9/month for 60GB, ¥18/month for 250GB, and ¥28/month for 500GB. Data resets monthly on the activation date; mid-cycle upgrades are prorated by the remaining days. For occasional use, compare data add-ons: ¥158/300GB, ¥358/1000GB, and ¥658/3000GB. They remain available until used and never expire. See the Plans page for full billing details. The 30-day refund policy and technical test results are separate considerations, not performance guarantees.

Build a repeatable troubleshooting process

Start with symptoms, not assumptions

Describe the symptom in a reproducible sentence, such as “The browser loads the page, but code completion doesn't respond,” rather than “the network is broken.” Note the device platform, operating mode, route label, protocol, and conditions, then confirm the subscription is imported, required permissions are granted, and the system clock is correct. If you haven't completed those basics, start with the quick-start guide. This reference helps narrow down causes; it doesn't replace the basic installation and connection steps.

Next, determine the scope of the problem. If only one app is affected, check whether it uses the proxy, whether the account is valid, and whether the destination service reports an issue. If multiple apps are affected, check the client connection status, local access network, and route reachability. If only certain domains are affected, check DNS and routing rules. If the issue occurs only after the screen locks, check background settings and session recovery. Classifying the scope reduces unnecessary changes and helps distinguish an app limitation from a route outage.

Establish a baseline before trying alternatives. Keep the device, access network, and task the same, then try another route of the same type. If the issue persists, test a different entry point or transport. If you need to switch local networks, record that change separately instead of combining it with a protocol switch. If an adjustment seems to help, check whether the original issue can still be reproduced under the same conditions. This helps avoid crediting an advanced setting for a problem that the destination service happened to resolve on its own.

Choose checks based on the stage where the error occurs

For authentication failures, first check whether the subscription is up to date, the client supports the configuration, and the system clock is correct; don't start by changing DNS. For certificate errors, check the device clock, system trust store, and server name instead of skipping verification. If the connection establishes but then stalls, look at the destination service, congestion, and app session. For DNS errors, first confirm which path DNS requests use. The clearer the error, the more closely troubleshooting should target the relevant stage. Reinstalling the client isn't the answer to every problem.

If needed, use a system-provided tool to inspect a basic HTTPS request. The command below reads response headers from an example domain and contains no subscription or authentication data. It uses the current network path of the command-line process; it doesn't prove that the request went through the client. If your system uses a virtual network interface, behavior may differ from using only the system proxy. If the command isn't available, there's no need to download an unfamiliar tool; use a browser and the client's built-in diagnostics instead.

curl --head https://example.com/

When reading the output, first check for clear errors in DNS resolution, connection setup, or certificate validation, then distinguish a normal HTTP response from a network interruption. An application error code from the destination usually means some response arrived; it doesn't mean the transfer failed completely. However, the response could come from a local gateway page or another intermediary. Don't remove security checks just to get a “success” message. A diagnostic command is for observation, not a network repair switch.

Before sharing troubleshooting materials, hide subscription URLs, authentication identifiers, account passwords, and complete request headers. Keep the error stage, route name, device platform, and steps taken. For help, submit a clear description through the signed-in support ticket portal. You can also check the FAQ for common questions. Don't post private configuration in public discussions or assume that more complete logs are always better; include information relevant to the issue without exposing your account.

Finish by checking the actual task

Once the issue is resolved, retest the real task you started with: check that webpage resources load, conversations continue, files finish transferring, and the connection recovers after the screen locks. Note the final working route and mode, return debug logging to its usual level, and undo experimental changes you no longer need. If the cause is still unclear, record that the setup works for now and the cause is unconfirmed. Describing uncertainty accurately is more useful for future troubleshooting than treating a one-off improvement as a protocol rule.