VPN Protocols and Server Routes: Technical Reference

Separate protocols, transport and routes

Clients often list a region, route type and protocol on the same line, making them easy to mistake for the same kind of metric. In practice, a connection has several layers: an app makes a request, routing rules decide whether it goes through a proxy, the proxy protocol handles authentication and encapsulation, the underlying transport carries the data, and the route determines which networks it crosses. The same exit region does not mean the same entry point, carrier network or path to a destination. And using the same protocol does not guarantee the same experience.

For example, when a browser opens a webpage, it typically resolves the domain name, establishes a transport connection, completes any required security handshake, and then exchanges app data. A connected status in the client only confirms that one part of the connection is established; it doesn't prove that all browser requests are taking the expected route. An app may keep an old connection open, the system may still use a cached DNS result, or routing rules may send some domains over the local network. Troubleshoot the path taken by the specific request instead of repeatedly clicking Connect.

A protocol name alone doesn't define the security boundary

A protocol name describes a design, not the whole security picture. A protocol that relies on TLS also needs correct certificate validation and server-name configuration. A protocol that supports encryption still depends on keeping access credentials secure. An encrypted tunnel protects the relevant part of the connection, but the destination website can still identify your account and app activity. Browser security, service-account permissions and operating-system updates each serve a different purpose; a proxy connection cannot replace them.

Likewise, 6NVPN's no-logs policy does not mean your device keeps no browsing history or that third-party websites cannot record account activity. A client may show connection details locally for troubleshooting. Before sharing a screenshot, check for subscription URLs, account identifiers and access credentials. When reporting a technical issue, the error type, circumstances and network type are usually enough; there's no need to share your full configuration.

Start with conditions you can reproduce

Before comparing setups, keep the device, network, target app and test action consistent. Change just one factor at a time—either the protocol or the route—so you can tell what made a difference. If you change the region, client and routing mode together, even an improvement won't tell you which change helped. Note whether a page opens, whether the first response is delayed, whether playback drops out, and whether switching networks resolves the issue. You don't need to start with elaborate speed tests.

Also distinguish between something that works and something that suits your needs. A text-heavy webpage opening doesn't prove a connection is suitable for live calls; a steady download doesn't guarantee responsive interactions. The target app's service status, account region and access permissions can affect results too. A region warning doesn't automatically indicate a protocol problem, just as a login failure shouldn't trigger a password change and a route change in the same troubleshooting step. First identify whether the failure occurs during DNS resolution, connection setup or the app's response.

This page discusses protocol design and trade-offs. It does not rank speeds or promise that every 6NVPN route supports every capability described here. Check the route list for available regions and route types.

A subscription gives your client access to route information; it is not a transport protocol. Updating it may change the available nodes or routing rules, but it won't necessarily make every app on your device reconnect right away. If nothing changes after an update, close the target app's existing session and test again. For help retrieving, saving and updating a subscription, see the guide to finding, importing and updating subscription links.

Shadowsocks and VMess: Check the implementation and client support

Shadowsocks uses a relatively straightforward proxy protocol to carry app traffic. Its encryption, address handling and UDP support depend on the specific implementation and configuration. A simpler protocol structure does not necessarily use fewer resources on every device. The client's network stack, any additional encapsulation and the device's encryption hardware all affect overhead. Before choosing it, make sure your client correctly recognizes the subscription format.

VMess has its own authentication and data-handling mechanisms, and deployments may pair it with an additional transport layer. When you see VMess, check which transport is underneath, whether TLS is also used, and whether your client fully supports that combination. Extra layers may add connection setup and processing work, but their effect on performance depends on the network and device. The protocol field alone can't tell you what to expect.

Trojan and VLESS: Don't overlook the outer security configuration

Trojan commonly uses TLS to protect transport and handle proxy authentication and data exchange. The important point isn't to treat its name as a performance rating, but to ensure TLS validation is configured correctly. An incorrect system clock, failed certificate validation or mismatched server name can end the connection before app data is sent. If you see a certificate error, check the client clock and subscription status; don't hide the problem by turning off validation.

VLESS is designed to simplify the proxy protocol itself, leaving transport protection to the outer mechanism specified in the configuration. It does not provide every form of encryption on its own, and a lightweight protocol header does not guarantee a faster end-to-end connection. The full connection still involves transport negotiation, a security handshake, routing and the destination server's response. A client that doesn't support the required transport combination may fail to connect even if it recognizes the name VLESS.

Compatibility often matters more than theoretical overhead

For desktop work, mature client support, readable rules and compatibility with system proxy settings are usually more important to check first than small differences in protocol headers. Some apps follow the system proxy, some make their own connections, and others need a virtual network interface to be routed. A protocol's ability to carry a type of traffic doesn't mean the client is actually handling that app's traffic. If a browser works but a work app doesn't, check how traffic is intercepted and whether the rules match.

Don't assume TCP is always slow. It delivers data reliably and in order, making it suitable for many websites and business connections. On a stable route, mature congestion control and broad system support are real advantages. Problems are more likely when packet loss, queue buildup or nested transports interact. Consider changing transport only when symptoms recur, not just because you see a newer protocol name.

When changing clients, reimport the subscription and check how it is recognized instead of copying every field from an old configuration by hand. Clients can handle parameter names, rule formats and defaults differently. First test a basic route, then add custom routing gradually. This helps distinguish compatibility issues from service problems. Keeping a known-working setup for comparison is more useful than continually adding parameters.

UDP-based doesn't mean apps have to accept data loss

Hysteria2 and TUIC both use QUIC-based designs. QUIC runs over UDP and implements connection management, encryption and reliable streams in user space. So seeing UDP doesn't mean webpage data is lost at random, and it shouldn't be confused with an app's native, unretransmitted datagrams. Reliable streams still recover lost data; QUIC simply organizes recovery and streams differently from traditional TCP.

QUIC can reduce transport-layer waiting between streams, but it doesn't eliminate all queues. Connections still share congestion control and available bandwidth, and queues can still build up at the client-side entry, along the carrier route or at the server exit. If every stream crosses a congested physical link, switching to QUIC won't create extra capacity. It changes the transport mechanism and how traffic is handled, not the amount of network capacity available.

Hysteria2: Match bandwidth settings to the actual route

Hysteria2's congestion-control choices and bandwidth settings are key to understanding its behavior. With mechanisms tied to a bandwidth target, client settings can affect how data is sent. Setting an unrealistically high target won't give the connection that capacity; overly aggressive sending can increase queueing, packet loss and retransmissions, affecting other apps on the same network. Raising the setting repeatedly is not a general-purpose fix.

If your subscription includes these settings, start with the configuration supplied by the service. Before changing anything, check how your client interprets the parameter and observe whether both sustained transfers and interactive requests improve. A download peak alone can hide longer queueing delays. On a home network used for video, calls and file sync, smooth interaction is often more valuable than a brief burst of higher throughput.

TUIC: Connection reuse and datagram handling have limits

TUIC also uses QUIC connections and streams. Connection reuse, UDP forwarding and congestion control depend on the client and server implementations. Reuse can reduce the work of repeatedly creating underlying connections, but it also means requests share a connection's resources and state. If you get an occasional pause, check whether it affects just one app or all streams using that connection before deciding to reconnect.

When a mobile network changes, QUIC connection IDs and migration may reduce reliance on a fixed network address. Whether a session survives still depends on the implementation, network policy and app behavior. Migration support does not guarantee an uninterrupted connection through every network change. If an app stops working after switching from Wi-Fi to a mobile network, test the app again instead of relying on the client's connection icon.

If the network blocks UDP traffic, a QUIC-based setup may not connect. Compare it with another transport available in your subscription instead of disabling certificate validation or guessing at bandwidth settings.

One more important distinction: a proxy route using QUIC doesn't mean the app also uses QUIC to reach the destination website. A browser may negotiate its own connection beyond the exit. The proxy segment can work normally while the destination responds slowly because of its regional route or its own load. When reviewing logs, distinguish the client-to-route entry, route-to-exit and exit-to-destination segments instead of blaming every error on the client's protocol.

Before choosing one of these protocols, confirm that your network allows the required traffic, then monitor ongoing battery use and background behavior. On a stable fixed network, there's no need to change a setup that already meets your needs just to try a different transport architecture. Where packet loss or network changes are a recurring issue, compare these options under the same conditions and base your choice on repeated observations.

The exit location is only part of the route

A region usually describes the exit location, but your actual connection runs from your local network to the route entry, across the carrier network to the exit, and on to the destination website. Shorter geographic distance can mean lower propagation delay, but networks don't always route along the straight line on a map. Peering arrangements, routing decisions and return paths can send traffic farther afield. When choosing a route, consider both how well you can reach the entry and how well the exit connects to the destination.

A direct route generally means the client connects straight to an international service entry, without an additional relay entry point for the user. The path is simpler and easier to troubleshoot, but performance depends more heavily on the peering route from your local network to the destination network. Congestion in one direction can cause poor performance even if the exit itself is working normally. Direct doesn't mean low quality, and it doesn't guarantee low latency; assess the specific route.

Relays change the entry and carrier path

A relayed route first sends traffic to an entry point, then forwards it along another path to the exit. This may improve reachability to the entry and provide a different carrier path for cross-region traffic. It also adds more links to maintain and troubleshoot. A busy entry, congestion between entry and exit, or an issue reaching the destination from the exit can all look like a slow webpage. Compare routes to narrow down the cause.

When evaluating a relay, don't just count network hops. More hops don't necessarily mean slower performance: capacity, route quality and queue management matter too. A route with fewer hops can still pass through a congested peering point. For users, a more useful comparison is connection setup and sustained transfer in the same app at the same time. If changing the relay entry helps while the exit region stays the same, the issue is more likely related to local access or the carrier path.

A private line describes the transport path, not the entire end-to-end connection

An IEPL private line refers to a specific carrier and interconnection arrangement, often used to reduce the impact of public-route changes on the relevant segment. Your local network, the route entry and the connection from the exit to the destination may still cross other networks. A private line can't fix a weak Wi-Fi signal, an overloaded home upload or a slow destination website. Assuming the entire connection can never be congested because one segment is private can create unrealistic expectations and delay troubleshooting.

For business use, the route from the exit to the destination can matter more than how close the exit is to you. For a corporate system restricted to certain regions, first check which regions the service allows, then compare routes in those regions. For regional media, consider the platform account and content licensing too. A route name is a useful clue, not a substitute for testing the target app. For more on content services, see Streaming.

6NVPN covers 110+ countries and 170+ routes. See the route list for available regions and types. Having more routes gives you more paths to choose from; it doesn't mean every region suits every task equally. For everyday use, keeping one preferred region and one backup on a different route makes it easier to assess performance than repeatedly browsing the full list.

When changing routes, consider how the app handles an exit change. Some existing sessions may stop working; some services may ask you to verify your login again. Whenever possible, choose a route before starting a file transfer or live meeting. Avoid switching repeatedly during an important task. If you need to report an issue, include the exit region, route type and time it occurred; don't share subscription details.

First response, sustained throughput and jitter are different metrics

“Speed” can mean how long it takes for content to appear after a click, or how well a connection sustains a large download. A webpage involves DNS resolution, connection setup, a handshake, server processing and resource loading. Downloads depend more on sustained throughput; calls and remote control are more sensitive to latency changes and packet loss. Different tasks have different requirements, so one file download can't represent the overall experience.

Connection setup time is also affected by reuse. Existing connections may be reused for later requests, so reopening a webpage can skip part of the setup. If one route is tested with a fresh connection and another with cached data or a reused connection, the results aren't directly comparable. For a first-response comparison, note whether you restarted the app, kept the cache and already had a session with the destination service.

Encapsulation layers are only one source of overhead

Protocols require work for authentication, encryption, encapsulation and data copying, but end-to-end time also includes network delays. On a long route, shaving off some local processing may be hard to notice. On a resource-constrained device, intensive encryption or complex rule processing can become a bottleneck. “A lightweight protocol is faster” is a design hypothesis, not a conclusion that applies to every situation.

More encapsulation adds headers, processing steps and possible fragmentation issues, but fewer layers aren't always better. An outer transport may be needed to work with a network or platform; removing it could make the connection unusable. Avoid stacking multiple global proxies or virtual network interfaces without a clear need. They can compete over system routes, change DNS paths and create hard-to-diagnose loops or duplicate traffic interception.

Assess CPU, memory and rule complexity in context

When checking client resource use, consider whether the device is also downloading, updating or running other tasks. High memory use may come from cached rules and connection state, not necessarily a problem. Brief CPU spikes may occur while importing a subscription, parsing rules or creating many connections. Pay closer attention to whether high usage persists after transfers stop, and whether it coincides with lag, heat or failed connections.

If problems only arise when many apps start at once, pause unnecessary background sync and compare the client again. If performance drops only after enabling complex custom rules, test the subscription's default settings. Rule behavior depends on more than the number of rules: match order, DNS resolution and process detection all matter. Sending every domain to remote DNS or routing every request through the same exit can change behavior; don't automatically blame the protocol.

Keep the target app and network consistent when comparing options. Check first that the task completes reliably, then look at resource use. A protocol ranking based on inconsistent test conditions is not a sound basis for configuration.

On desktop, use Task Manager or Activity Monitor to check how the client and target app behave, but don't judge from a single peak. Sustained transfers, idle standby and network changes are different states and should be observed separately. The process name may not match the app's interface name; some clients run a separate core process. Check which processes belong together before attributing resource use to a proxy protocol. This avoids blaming the browser or sync app for the client's overhead.

Finally, consider data use. Speed tests transfer data, and repeated high-volume tests don't necessarily make your diagnosis more useful. 6NVPN monthly subscription traffic resets each month on the activation date; data add-ons never expire and remain available until used. For usage and billing details, see Plans and Pricing. Don't treat a test peak as a service guarantee or as proof of long-term throughput.

Battery use depends on connection behavior and the wireless network

You can't predict a mobile device's battery life just from the protocol name. Data transfer keeps the wireless radio active; encryption and rule matching use processing power; connection keepalives wake the network; and a weak signal can require more communication overhead. If an app keeps syncing in the background, the connection may stay active even when you aren't using the client interface. Before comparing battery use, check that traffic levels and background tasks are similar.

Frequent reconnections can also increase overhead. When a power-saving feature pauses a process, the client may need to restore routing, DNS and its remote connection when it runs again; the app may retry failed requests too. Repeated pauses and resumptions can harm the experience without necessarily saving power. On the other hand, allowing every app to run unrestricted in the background can waste power. Adjust only the permissions related to the issue.

Android: Check background limits before changing protocols

Android background-management behavior varies by device. If a connection drops after the screen locks, first check whether the client is restricted from running in the background, whether it can maintain the required network service, and whether power-saving mode limits network activity. After changing a setting, repeat the same lock-and-resume steps with the same app. If the connection also fails in the foreground, investigate route and transport compatibility rather than attributing every disconnection to background limits.

Per-app proxying can limit which apps the client handles, but apps may depend on one another. An app may use a browser to complete sign-in or rely on a system component to fetch content. Selecting only the main app and missing an auxiliary step can let the page open while sign-in callbacks fail. After changing the app list, test sign-in, content loading and background notifications—not just the home screen. For more detailed steps, see the guide to Android background operation and per-app proxying.

iOS and desktop: System-level traffic handling differs

iOS clients rely on the network-extension capabilities provided by the system. A regular app and its network extension don't necessarily have the same runtime status. Switching away from the client interface doesn't mean the tunnel has ended; seeing a connected status doesn't guarantee every app's requests follow the expected rules. If there's a problem, check the system connection status, then test it in the target app. Follow the Guides to get the client and import your configuration; don't import configuration from unknown sources.

On desktop, a common issue is that apps don't all use the same traffic-handling method. Browsers may follow the system proxy, while games or command-line tools may ignore it. A virtual network interface handles more traffic but can conflict with other network software. Work devices may also be subject to organizational policies; check what changes are allowed before making them. For Windows, see a guide to global proxy settings, split tunneling and workplace compatibility.

6NVPN supports Windows / macOS / iOS / Android / Linux, with unlimited simultaneous devices, but each platform should be tested separately. Get the client through the user panel. If a problem occurs on one platform, describe its specific behavior rather than assuming that a working connection on another device proves the route is working everywhere. Network access, client implementation and system routing can all differ.

First, identify the scope of the issue

When a connection fails, first check whether the issue affects the whole device, every route in the client, or just one app. If local network access is slow too, check Wi-Fi signal, router load and network status first. If only one destination is affected, look at that service, the exit region or the relevant routing rule. Identifying the scope cuts down on unnecessary changes and helps avoid switching protocols when the local network is already unstable.

Packet loss can result from wireless interference, device queues, a congested link or a forwarding issue along the route. Higher latency doesn't always mean a longer physical distance; queueing can delay data too. If a file sync is saturating your upload, interactive requests and acknowledgments may get stuck behind other traffic, making webpages slow to respond. Pausing background uploads for comparison can reveal more than changing the exit.

Compare time of day and routes during peak hours

A slowdown during peak hours can occur on the home connection, at a peering point, at the route entry or between the exit and destination. If different regions and carrier routes all slow down at once—and other activity on your local network is affected too—start by checking your access network. If just one route slows while others work normally, record the route and app affected. Don't assume every evening issue is caused by server load simply because of when it happens.

Keep the test action consistent when comparing routes. Open the same destination page and observe both connection setup and subsequent loading. For video issues, distinguish initial buffering, playback interruptions and automatic quality changes. A service may use different delivery routes based on the device, account or content, so comparing different videos introduces variables. Avoid running many tests simultaneously on one device; they'll compete for bandwidth.

Handle DNS errors and transport errors separately

DNS resolution determines which address an app tries to connect to, but successful resolution doesn't mean the route will work. Caching can make a change appear ineffective for a while, and different apps may use different DNS methods because of routing rules. If only domain-name access fails while other destinations work, check the client's DNS status and rule logs. Don't enter a DNS server address you found online without checking; it could change the request path or conflict with your routing setup.

If small items load but larger transfers stall, consider how the route handles packet sizes. Blocked Path MTU Discovery or fragmentation caused by extra encapsulation can lead to seemingly random pauses. These are possibilities, not reasons to apply a fixed setting blindly. First compare another route or a different transport available in your subscription, then consult the client documentation for relevant settings. Arbitrarily lowering values can hide the issue or reduce efficiency.

A network device that doesn't respond during a path trace isn't necessarily dropping your traffic. Some devices limit diagnostic responses. Judge the issue by the destination and actual app behavior, not a single line in the trace.

If the client says it's connected but the target app still uses the original exit, check in this order: rule match, system traffic handling, old session, DNS cache. Close the app's existing connection first, then confirm whether the app is handled by the system proxy or a virtual network interface. To check the exit, use IP Lookup and the guide to checking your exit IP and DNS. A browser result doesn't represent every app.

Before submitting a support ticket, note when the issue occurs, the platform, type of network, route region, protocol and steps to reproduce it. Say whether all apps are affected, whether switching networks helps and what comparisons you've already tried. Don't include passwords or your full subscription URL. Submit these details through the user panel ticket system. This makes the issue easier to diagnose than simply saying “it's slow” and avoids repeating steps that haven't helped.

Work and AI: Keep routes and rules easy to understand

Web-based work, document collaboration and AI tools often involve sign-in, API requests, streaming responses and file uploads. Loading the home page only checks one part of the service. When choosing a setup, verify sign-in, sustained responses and uploads, and confirm that relevant domains follow the intended rules. Changing the exit mid-session may force the app to reconnect, so choose a route before starting important work.

AI tools have their own account-region, access-permission and service-status requirements. Not every refusal message indicates a route problem. A route can change how traffic travels, but it can't replace the platform's account requirements. Start with a stable setup and clear rules, then compare options based on the specific error. For use cases involving ChatGPT, Claude and Gemini, see AI Tools. Don't infer that a tool will work just from the protocol name.

Streaming and real-time apps need different kinds of stability

Video playback depends more on sustained throughput and buffering. Live calls, gaming and remote control are more sensitive to latency changes, packet loss and recovery. These tasks need different criteria. A video that buffers briefly and then plays smoothly doesn't prove the route is suitable for real-time apps; a smooth call doesn't prove it can handle large downloads. Start with your main use case and test it with a real task instead of relying on a general speed test.

Regional streaming content is also subject to platform licensing, account requirements and exit-location detection. 6NVPN's regional coverage does not guarantee access to every platform. If you see a region warning, first check your account and content eligibility, then compare different routes in the same region. For real-time apps, check whether their traffic is routed through the client, whether they rely on UDP and whether the client supports the required forwarding. If your work needs a consistent network environment, avoid automatic exit changes during a session.

Use a backup to compare, not as an automatic fix

A practical setup includes one everyday option and one backup with a different route or transport. The everyday option should be compatible and easy to understand; the backup can help narrow down an issue. Nodes with different names may still share nearly the same route, so don't assume they're independent backups. And don't change the protocol, region and routing mode all at once. Know which assumption each switch is testing.

For mobile use, first make sure screen-lock recovery and network switching work acceptably, then consider adjusting transport settings. For a fixed desktop, check app traffic handling and work-software compatibility first. In a multi-device household, test each device rather than copying a setup from one platform to another. 6NVPN allows unlimited simultaneous devices, but they still share your local network capacity, and background downloads can affect interactive tasks.

Choose a plan based on usage and a protocol based on your network

Billing tiers don't determine which protocol to use. 6NVPN 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 for the remaining days. Data add-ons are ¥158/300GB, ¥358/1000GB and ¥658/3000GB; they never expire and remain available until used. Choose based on your everyday tasks and data use. Nothing in this protocol guide means a particular price tier guarantees a particular speed.

Payment options include Alipay / WeChat Pay / USDT, and the refund policy is a 7-day money-back guarantee. See Plans and Pricing for full billing details and Terms of Use for service limits. No email address is required; you can register with a username and password. To get started, follow the Guides to import and verify your setup. For further troubleshooting, return to the relevant section of this page. The goal of choosing a setup is a reliable, repeatable connection you can maintain—not chasing protocol names.