Protocols and Network Routes: A Technical Guide

FOUNDATIONS

Protocols, Transport and Routing: The Layers

Break the connection process into steps you can check

A web request passes through the application, the operating system's network interface, the client, an access server and the destination service. The application requests a DNS lookup and a connection; the client then applies its rules to decide whether to handle the traffic and which route to use. A protocol defines how the client and server authenticate, encapsulate and forward data. The route describes the networks the data actually traverses. The same protocol doesn't guarantee the same route, and the same exit region doesn't guarantee the same entry point or transport path. Conflating these concepts can make a slow destination look like a protocol performance problem.

A subscription URL is a way to deliver configuration, not a communications protocol. It can include the server address, port, authentication details, protocol, transport settings and group information. After import, the client still needs to interpret those fields and use its network core to connect. A client that can read a subscription may not support every node configuration it contains. If the import succeeds but some routes are missing, check protocol and field compatibility before importing again. Converting between subscription formats can also drop transport or certificate-related fields.

Application Proxies, System Proxies and Virtual Interfaces

An application proxy usually affects only software that explicitly uses its proxy interface. A system proxy advertises proxy settings to applications, but whether an application follows them depends on how it's built. Virtual interface mode intercepts more traffic at the network layer, making it useful for software that ignores system proxy settings. It can also introduce routing, permission, DNS and local network compatibility issues. These modes cover different amounts of traffic; one isn't inherently faster. When troubleshooting, note the active mode and check whether the target app is actually routed through the client. A connected status doesn't mean every request on the device uses the same route.

What Protocol Fields Do

The server address identifies the connection endpoint; the port identifies a service on that server. Authentication fields confirm access. TLS-related settings cover encrypted connections and certificate validation, so the server name must match the identity expected in the certificate. The transport method determines which connection carries proxy data; multiplexing settings determine whether multiple logical requests share an underlying connection. These fields aren't performance knobs to swap at random. Changing a protocol name by hand or copying only the address while ignoring transport settings usually won't produce a working connection. Use the complete configuration provided by the service whenever possible.

DNS is another concept to understand on its own. Depending on the client mode and rules, DNS lookups may be handled by the operating system, the local client or a remote resolver. Where resolution happens can affect which destination address is selected, but it isn't the same as the exit region. A website's displayed region reflects the origin of the access request; a DNS log shows the path taken by the lookup. Check resolution and the connection separately rather than assuming all application traffic is routed incorrectly because a resolver appears to be in a different region.

The next sections follow these boundaries: protocol design first, route topology next, then performance, devices and troubleshooting. VPN54 covers 100+ countries / 180+ routes; the client subscription list shows the configurations currently available. Coverage figures indicate the range of options, not how a particular route will perform with a specific service. To check regions and route types, see the Servers page. Don't infer a route's location from a protocol abbreviation.

PROTOCOL FAMILIES

Trade-offs in Common Proxy Protocols

Shadowsocks and VMess: Encapsulation and Implementation

Shadowsocks is an encrypted proxy protocol that forwards application connections to a server. Its behavior depends on the cipher suite, protocol generation, client and server implementations, and whether additional transport components are used. To check compatibility, confirm the exact configuration supported at both ends rather than judging by the protocol name. A streamlined implementation may reduce some encapsulation overhead, but that doesn't make it faster on every network. Route congestion, destination distance and device performance are often more noticeable bottlenecks than differences in protocol headers.

VMess incorporates user authentication and data encapsulation into its protocol design, and common implementations can use different transport methods. When troubleshooting authentication failures, check client compatibility and system time as well as server and authentication settings. Some authentication mechanisms use time-based validation, so a significantly incorrect device clock can cause requests to fail. Updating the subscription and correcting the system clock address different issues: the first checks whether the configuration is current; the second checks whether the device meets authentication requirements. Don't disable necessary identity checks to make an incorrect configuration connect temporarily.

Trojan and VLESS: Understand the Security Layer

Trojan typically relies on TLS to protect traffic between the client and server, making certificate validation a key part of the connection. If the address is reachable but the certificate identity doesn't match, the client may refuse to connect. That's different from a port being unreachable. Check that the subscription is complete, the device clock is correct and the client supports the configured transport options. Ignoring certificate errors and routinely skipping validation changes the connection's trust boundary. Fix the configuration or contact support to confirm the server status instead.

VLESS doesn't encrypt data by itself and needs to be paired with an appropriate secure transport. Its design focuses on authentication and forwarding encapsulation; a simple name doesn't mean the whole connection automatically has every security property. Check the security layer and transport method specified in the complete configuration. Two nodes labeled VLESS may use different transports, with different connection steps and network compatibility. For most users, a complete subscription and a compatible client are more reliable than manually combining parameters that merely look advanced.

Protocol names aren't speed rankings

Establishing a connection may involve DNS resolution, setting up the underlying transport, a security handshake and proxy authentication. The order and whether an existing connection can be reused vary. A proxy carried over TCP may require round trips for a new connection, but client pre-connection and connection reuse can change the experience. Web pages may also reuse application-layer connections. So a page loading quickly doesn't prove that a protocol has fewer handshake steps; a slow load doesn't prove the protocol itself is at fault. For a fair comparison, keep the destination, route and test conditions as consistent as possible.

Resource use depends on the implementation, too. Processor load can be affected by hardware acceleration for encryption, repeated data copies in user space, traffic sniffing and rule complexity. Comparing protocols across different clients adds too many variables. A more useful test is to switch between complete node configurations on the same device, within the same client's supported options, and check whether the task actually improves. If the difference can't be reproduced, prefer a well-supported setup with clear error logs.

This reference covers Shadowsocks, VMess, Trojan, VLESS, Hysteria2 and TUIC. The list explains technical concepts; it doesn't promise that every route supports every protocol. The current subscription shows the available options.

UDP / QUIC

Hysteria2, TUIC and Their Transport Limits

First, understand what QUIC is designed to do

QUIC uses UDP to provide reliable transport and secure connections. UDP is only the underlying transport; it doesn't mean applications can ignore packet loss or that all UDP traffic is reliable. Reliability, congestion control, stream management and encryption are implemented by the protocol above it. Hysteria2 and TUIC both use QUIC-related capabilities for proxy transport, but their designs and implementations aren't interchangeable. A client supporting one doesn't automatically support the other. If the corresponding node is missing after import, check support in the client core rather than manually changing it to a similarly named type.

With TCP, losing a segment can block later data from being delivered in order. QUIC can make separate streams more independent at the delivery layer, reducing the direct impact of loss on one stream on others. However, streams within the same connection still share path capacity and congestion control. When the network is congested, other streams may also see lower bandwidth. QUIC doesn't eliminate congestion, and packet loss doesn't automatically mean it will be faster. It changes how transport is organized; results still depend on the network, server resources and application behavior.

Hysteria2: Set Bandwidth Parameters for the Real Route

Common Hysteria2 implementations offer congestion-control-related settings, and some modes use an estimate of available bandwidth. These parameters aren't a plan speed guarantee, and higher values aren't automatically better. Setting expected send capacity far above what the route can handle may increase queuing, packet loss and retransmissions, making web browsing and calls worse. Conversely, overly conservative limits may leave the route underused. When using a service-provided subscription, keep the complete configuration as is to start. Only consider changing local parameters if you understand the fields, can reproduce the problem and have guidance that applies to your setup.

TUIC also requires an understanding of the client implementation, including its connection management, authentication and UDP forwarding. Multiplexing can reduce the overhead of repeated connections, but it makes more traffic share underlying state. Keepalives can maintain a mapping but may generate extra traffic while idle. Default behavior can differ after switching clients, even when the node name is the same. For a useful comparison, note whether multiplexing and keepalives are enabled, whether the app handles real-time data, and whether the network changed from Wi-Fi to mobile data. Otherwise, environmental changes can look like protocol differences.

Network Switching and Datagram Size

QUIC connection IDs provide a basis for keeping a connection alive when the network path changes, but support for this behavior varies across proxy clients, servers and applications. When a device switches networks, its local address, default route and address-translation mapping may all change; the operating system may also pause background processes. Even if the transport recovers, the app may already have timed out. Don't assume one successful network switch means every session will survive, or that QUIC has no effect just because an app reconnects. Observe the client session and the application request separately.

The maximum transmission unit (MTU) determines the packet size a path can carry. Encapsulation adds overhead, so oversized datagrams may need fragmentation or be dropped if path MTU discovery doesn't work as expected. A common symptom is that short text loads but large responses or some websites keep hanging. Treat this as a clue, not proof that packet size is the cause. Also rule out DNS, the destination server and local routing. Don't change settings based on a generic value found online. First compare with another complete route from the subscription, then check for clear diagnostic advice in the client.

Choose based on the task. If the current network allows UDP, the client supports the complete configuration and the same task consistently works better on that route, Hysteria2 or TUIC may be a good fit. If UDP is unreliable or the device often pauses apps in the background, a compatible configuration carried over TCP may be easier to use. There's no fixed ranking independent of the environment, and no single protocol is right for every device, network and application.

ROUTE TOPOLOGY

Route Differences: Direct, Relayed and Dedicated Paths

Consider the entry, transport path and exit separately

A direct route usually means the client connects straight to an access server in the destination region. The path is relatively simple, with fewer forwarding steps, but data still passes through local access networks, carrier backbones and interconnection points. A server that looks closer on a map may be reached by a longer route due to detours. The benefit of a direct route is a simpler structure, not a guarantee of the lowest latency. Check how the local network reaches the entry point and whether the entry can reach the target service, rather than relying on map distance or region names.

A relay route typically connects to an entry point first, which then forwards traffic to the exit. It may use more suitable interconnection paths and improve the experience on some networks, but it adds forwarding equipment, links and potential points of failure. A good entry point doesn't guarantee a good exit, and a reachable entry doesn't mean the rest of the route is uncongested. When troubleshooting, determine whether the log shows a successful entry connection or a completed request through the exit. Relaying doesn't automatically make a connection faster; the extra steps help only when the complete route is better than the original.

A dedicated-line label describes route organization, not a guaranteed experience

An IEPL dedicated line describes a route that includes a dedicated transport segment. It may reduce some uncertainty in public-network interconnection, but paths from the user to the entry and from the exit to the destination may still use public networks. A weak local Wi-Fi signal, a busy destination platform or limited device performance won't be fixed just because the route is labeled dedicated. Treat the dedicated segment as one part of the route, not a promise about every link in the access path. Check the service's route information and client list for the specific segments, entry points and configurations available.

Choosing a Region and Meeting App Requirements

The exit region determines the apparent source of a request to the target service, but platforms may also consider account region, billing details, device settings and session history. Changing exits doesn't guarantee a change in available content or remove app-side access restrictions. For Streaming and AI Tools, check results in the target app rather than relying only on an IP geolocation lookup. If a platform displays an error, first distinguish a network connection failure from a platform refusal; they require different troubleshooting. Repeatedly changing regions adds variables and can make the cause harder to identify.

The region in a route name usually refers to the exit; it doesn't reveal the entry point, physical data center, whether the IP address is exclusive or the full route. A native IP and a dedicated IP are different concepts: the former often describes an address's allocation or how platforms classify it, while the latter concerns whether one user exclusively uses that address. A region name alone confirms neither. This page makes no additional claims about these properties. If your work requires a particular IP type, confirm the specific route through a support ticket rather than treating marketing terminology as something you can verify from protocol fields.

To compare routes, use the same target service under similar conditions. Record whether the entry connection, page load, sustained transfer and application session all work. A one-off reachability test can rule out obvious failures, but it can't prove long-term stability. If one route consistently fails on your local network while another topology works, you can use the latter temporarily and submit the issue details. The Servers page lists regions and route types; this page explains the concepts rather than maintaining a complete node list that may change with the subscription.

Choose the route that meets the needs of your task and performs reliably, rather than automatically ranking dedicated lines above relays or relays above direct routes. The actual path, shared resources, time of use and target service all affect the result. Type labels can narrow down the options, but they can't replace testing or establish an unpublished bandwidth limit.

LATENCY / LOSS / CAPACITY

Connection Speed, Packet Loss and Peak-Time Congestion

Latency, throughput and page load aren't the same metric

Latency measures how long data takes to make a round trip; throughput measures how much data is transferred successfully over time. A page's first render also depends on DNS, handshakes, server processing and resource downloads. Low latency usually helps interactive tasks but doesn't guarantee faster large-file transfers. High throughput doesn't eliminate delays in cross-region interactions. A page with multiple domains and scripts can also load slowly because one third-party resource fails. Testing a single access address won't explain the whole experience. Measure connection setup and task completion separately rather than treating one number as a measure of every aspect of performance.

A client's route latency test may measure a probe, connection setup or the response from a specified address; the exact meaning depends on the implementation. Results from different clients may not be directly comparable. A route can have a fast probe but slow video loading without contradiction: the probe may target a different host, and video traffic also depends on the path from the exit to the content delivery network. Speed tests also use data and compete with other traffic for bandwidth. Avoid running them continuously during troubleshooting; the test itself may be causing call quality problems.

How Queuing, Packet Loss and Retransmission Are Connected

When more data arrives than a link can send promptly, network equipment queues it. Buffers absorb brief bursts, but a growing queue adds latency. Once the buffer is full, packets are dropped; reliable transport retransmits them, and congestion control may reduce the sending rate. That's why a background upload may not stop downloads completely but can still make web browsing and calls noticeably slower. The bottleneck could be a local router, upstream access or a remote link—not necessarily the proxy server. Pausing bandwidth-heavy tasks is a useful way to distinguish contention from a route failure.

Packet loss can also result from wireless interference, signal changes, device load or routing policies. A probe that gets no response doesn't necessarily mean business traffic is losing packets at the same rate; network equipment may give probes lower priority. Conversely, a clean probe doesn't rule out issues with the transport used by an application. Check real tasks, client errors and results on another local network. A probe screenshot without context rarely helps support distinguish an entry-point issue from a destination-side or local-environment problem.

Why Peak Hours Can Reveal a Bottleneck

At peak hours, more users compete for access, interconnection and exit capacity. A protocol can change transport behavior, but it can't create more path capacity. If throughput drops repeatedly on one route at similar times each evening, compare other route types, regions and a different form of local access. If all exits slow down at once, check home network load, Wi-Fi conditions and the local carrier connection as well. First determine whether the problem follows a particular route, then consider changing protocols. Repeated client configuration changes during congestion make it harder to establish a useful baseline.

Connection reuse can avoid repeated handshakes, but it can also concentrate the impact of a failure. If the underlying connection fails, multiple applications sharing it may all wait for recovery. Too many separate connections can increase authentication, encryption and system resource overhead. Whether reuse is appropriate depends on client defaults, the target app and route quality—not on a blanket instruction to enable or disable it. If there's no clear problem, keeping the configuration unchanged is usually more useful for long-term troubleshooting than trying advanced settings at random.

Useful performance notes should include the task, current route, protocol, access network, time of day and any background transfers. Change one condition at a time, then repeat the same task. For persistent problems, submit a support ticket with sanitized logs and steps to reproduce. Speed, uptime and fixed latency figures without evidence from the service shouldn't be treated as promises; general protocol principles can't replace real route performance.

CLIENT / DEVICE

Client Resource Use and Mobile Battery Life

Battery use depends on activity, not the protocol name alone

Client power use includes processor work, network traffic, system wakeups and background activity. Encryption is only one part of it. Continuous traffic keeps the wireless radio active, and frequent keepalives or probes can increase idle drain. If the device is streaming video, syncing files or uploading photos, the battery change can't all be attributed to the proxy client. For a useful comparison, keep screen use, tasks and network conditions similar, and check that no other background tasks have changed the workload. The battery usage percentage in system settings alone doesn't show how much extra power the client used.

The number of rules, domain sniffing, DNS handling and verbose logging can all affect resource use. Complex rules aren't necessarily wrong, but there's no need to add rules with unclear purposes just to make a configuration look comprehensive. Detailed logs are useful for short-term troubleshooting; leaving them on may increase disk writes and expose more connection metadata. Restore an appropriate everyday log level once the issue is resolved. If the device runs hot, check client CPU use, system network activity and other apps rather than assuming the connected client is the only source of heat.

Balancing Background Limits and Connection Stability

Mobile operating systems limit background activity to save power. If a client is suspended, the tunnel may need to reconnect and apps may briefly report connection failures. Relaxing background restrictions can sometimes help keep a connection alive, but may also prolong network activity. Adjust permissions only when background interruptions are an actual problem, and use the options provided by the operating system. Don't disable every power-saving feature on the device. If only one app is affected, first check that app's background permissions and network settings rather than changing the device-wide power policy.

Switching between Wi-Fi and mobile data changes the default route, DNS and address-translation state. The client may still show as connected even though the old connection is no longer valid; it may need time to verify the new path. Some apps recover on their own, while others need a new request. First check whether a regular web page works, then test the target app, and only then consider reconnecting the client. If switching networks seems to require reimporting the subscription, that's usually the wrong fix: the subscription provides configuration, not a way to repair the operating system's network handoff.

On Desktop, Keep Variables Under Control

On desktop, a common problem is proxy software and other networking tools changing settings at the same time. Office tunnels, virtual machine networks, security software and proxy clients may all modify routes or DNS. Settings may not be fully restored after a program exits, leaving some destinations unreachable. Before troubleshooting, note the current network mode and any essential work connections, then compare tools one at a time using their normal exit options. Don't remove system network services or run cleanup commands from unknown sources. For detailed installation and permission steps, see the Complete macOS Beginner's Guide.

VPN54 supports Windows / macOS / iOS / Android / Linux, with no device limit. The number of devices doesn't mean their configurations, system permissions or network conditions are the same. Account traffic is also governed by the plan rules, not allocated separately to each device. Get the client and subscription from the User Dashboard. Clients are available from the dashboard on all platforms except iOS; the iOS download requires an active plan. You still need an active service configuration to use the subscription.

Everyday settings should balance stability, resource use and maintainability. If everything works, there's no need to change the protocol, rules and network mode at once to chase theoretical performance. To compare options, save a working configuration, change one setting and make sure you know how to revert it. For desktop startup and connection checks, continue with Getting Started with Windows from Scratch, so platform installation issues don't get mixed up with protocol choices.

DIAGNOSTIC WORKFLOW

Find the Faulty Layer in Connection Logs

Establish a Baseline for the Network and Configuration

Before troubleshooting, make sure the device itself can access the network and check whether a captive portal needs sign-in. Then check your account's service status, remaining traffic and whether the subscription is up to date. An expired configuration, unavailable traffic and a protocol compatibility issue each require a different fix; a connection timeout alone doesn't distinguish them. Keep a note of a previously working configuration and pause other tools that modify routes. Don't update the client, replace all rules and change DNS at the same time, or you won't know which change fixed the issue.

When reviewing logs, look for the earliest relevant error, not just the final connection failure. A DNS error means the domain couldn't be resolved to an address. A timeout means the entry point or a later part of the route didn't respond in time. An authentication error points to credentials, configuration or protocol compatibility. A certificate error involves the secure connection's identity or the system clock. An application error may mean the request already reached the target platform. Interpret each message in context; don't run generic commands found through a search based on a single English word. Identify the stage that failed before choosing what to test next.

Use the Smallest Useful Comparison for Each Symptom

If no apps work, check the client mode and system routing first, then test another complete route from the subscription. If only one app is affected, check whether it follows the system proxy, is excluded by a split-tunneling rule or uses its own network settings. If a page loads but some resources don't, check which domains the failed resources use rather than testing only the home page. If only video or real-time communication is affected, investigate its transport and persistent connections. A text page loading successfully doesn't prove every type of traffic works.

If the same configuration works on another network, the issue may involve the current access network, Wi-Fi conditions or UDP availability. If another device works on the same network, check permissions, system time, DNS and routing on the affected device. If changing regions fixes the issue, that only shows that the route or destination-region conditions changed; it doesn't prove the original protocol was faulty. Keep the task the same for each comparison. Note what changed and what happened rather than just labeling a route good or bad.

Distinguish Platform Policies from Network Errors

ChatGPT failing to load can mean DNS resolution failed, a connection couldn't be established, page scripts broke, account verification is required or the platform displayed a regional notice. These issues don't all have the same fix. If the login page loads but the platform refuses access after sign-in, check the application session and account requirements. If a secure connection can't be established at all, start with network and certificate logs. Switching routes changes some network conditions; it doesn't override the platform's account rules. For unavailable streaming content, distinguish playback problems from regional content differences and account status as well.

When troubleshooting DNS, confirm that the active mode allows the client to handle DNS resolution. In system proxy mode, some apps may still use the operating system's resolver. In virtual interface mode, the client may route DNS locally or remotely according to its rules. Clearing the cache can rule out stale results, but it isn't a lasting fix for a recurring problem. Repeatedly clearing it without checking the resolution rules only changes the symptoms temporarily. If IPv6 is involved, check whether the address family chosen by the app follows the expected route. One successful address test doesn't prove every connection takes the same path.

Prepare a Useful Support Ticket

If you need help, submit a ticket through the User Dashboard. Include when the issue occurred, your platform, network type, client mode, route name, protocol and sanitized error details. Say whether it happened once or is ongoing, and whether another route or local network works. If you need to share a screenshot, crop out authentication details and subscription QR codes. This information helps distinguish entry connectivity, configuration authentication, transport failures and target-platform refusals—and is more useful than simply saying “can't connect.”

After a fix, restore your usual logging level and retest the task that originally failed. Switching routes temporarily to get back online doesn't mean the original issue is resolved. If changing a rule lets you browse, also check that work apps and local network access still function. For common account and billing questions, visit the Help Center; repeatedly changing protocol settings won't resolve a plan-status issue.

SELECTION / MAINTENANCE

Choose a cross-border route for your needs

Define the task first, then the constraints

Start by spelling out what you need to do. Web research depends on a quick initial load and consistent access; file transfers need sustained throughput; calls depend on stable latency and continuous delivery. Streaming also involves the destination region and platform policies, while AI tools may involve long responses, uploads and account sessions. These tasks place different demands on a route, so a single download test can't determine the best setup for everything. Also note the device platform, whether the network allows UDP, whether background operation is needed and whether any work connection must remain uninterrupted. These constraints define the available options.

Next, choose from configurations the client fully supports. Start by testing the default configuration and confirming the target app works, then compare another route topology or protocol. If the task is already reliable, there's no need to switch just because a name sounds newer. Keep the current working route as a fallback before replacing anything; don't delete every configuration first. Compare the same task and check for new background interruptions, local network issues or resource use. A protocol is only one part of a setup; maintenance effort also affects the long-term experience.

Different Priorities for Interactive Tasks, Transfers and Streaming

For work and calls, first ensure business traffic follows the expected route and preserve any network settings required by your organization. Don't route work traffic through a personal proxy unless you've confirmed that it's appropriate. If calls stutter during background sync, rule out bandwidth contention before comparing routes. For large transfers, check sustained performance and recovery after failures rather than just the initial speed. Before using UDP-based transport, confirm that the local network supports it. With multiplexing, check whether a large task affects other interactive traffic. No protocol eliminates all competition for shared resources.

For streaming, check the destination region, account and actual playback before assessing route performance. Platform catalogs and access policies can change; a region label doesn't guarantee specific content. AI tools also require you to distinguish network access from application permissions: loading a page doesn't guarantee that every feature is available. If a platform displays a notice, save the exact error and check account requirements rather than repeatedly refreshing or switching regions. For streaming, see the Streaming guide. For Netflix catalogs and route selection, see Choosing a VPN for Netflix.

Check Technical Options and Billing Separately

Your choice of protocol or route doesn't change how plan traffic is billed. VPN54 monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Traffic resets monthly on the activation date; mid-cycle upgrades are prorated based on the remaining days. Data add-ons are ¥158/300GB, ¥358/1000GB and ¥658/3000GB; they remain available until used and never expire. Choose based on your actual usage and data needs. A higher data tier doesn't imply an unpublished bandwidth or latency guarantee. See the Plans page for full details.

This service has no device limit, supports Alipay / WeChat Pay / USDT and offers a 7-day no-questions-asked refund. No email address is required; an account can be created with a username and password. Subscription URLs contain access credentials, so don't store them in public notes, code repositories or screenshots. Import subscriptions on your own devices through your account and other controlled channels. If you need help, share only sanitized materials. Encryption protects specific connections; it doesn't replace device updates, browser certificate checks or security settings on the destination account.

Long-term maintenance is about keeping configurations understandable, not accumulating more advanced options. Read the change notes before updating a client, check that your usual routes still work after updating a subscription, and retest important apps when your network changes. If an old setup works and a new one doesn't, revert first to restore the task, then compare the differences. To repeat the connection setup, return to the Quick Start Guide. To understand a failure mechanism, use the contents to find the relevant layer. Keeping installation, technical choices and support separate helps avoid repeating steps.