VPNXG Protocols & Network Routes

Distinguish protocols, routes and apps

Break a connection into observable stages

A visit to an international website is not a single connection between your device and the page. The app first makes a DNS request; the client applies its routing rules, sends the request over your local network to an access node, and that node connects to the destination service. The page may also load images, scripts, login services and media. A delay at any stage can leave the page loading. When something feels slow, describing the specific symptom is more useful than labeling a protocol fast or slow.

A protocol defines how the client and server authenticate, encapsulate and transfer data. A route describes the network paths that data takes. The client handles rule matching, connection management and system integration. These layers affect one another, but none replaces the others. The same protocol can perform very differently on different routes; the same route can also behave differently with another client core or set of routing rules. For a useful comparison, keep other conditions constant. Otherwise, you can only judge the overall setup, not the effect of any one factor.

Latency, throughput and reliability are different metrics

Latency measures the wait between a request and its response. Throughput measures how much data can be transferred over time. Reliability describes how consistently those results hold. Interactive pages make latency more noticeable; continuous video playback needs sustained throughput; remote terminals and voice calls are sensitive to brief interruptions. A route that downloads quickly may still be slow to respond to logins, searches or code completion. Test with tasks that resemble your actual use instead of relying on one eye-catching result.

Connection setup time is also different from performance after a connection is established. A first visit may require DNS resolution, a transport connection and authentication. Reusing a connection can skip some of those steps. Browser caches, client connection pools and destination-side caches can all change how later visits feel. Compare both first and repeat visits, but don't mistake a cache hit for proof that one protocol is inherently more efficient—or blame every cold-start delay on route quality.

Where this technical guide ends and service configuration begins

This guide covers general design principles for Shadowsocks, VMess, Trojan, VLESS, Hysteria2 and TUIC. It does not mean every protocol is available in every region or on every client. Check your subscription and the protocols recognized by your client after signing in for the options actually available to you. General protocol characteristics are not performance guarantees for this service. If an option is missing after import, check for subscription updates and client compatibility. Don't construct service addresses or guess authentication parameters yourself.

To make troubleshooting repeatable, record your access network, target app, node region, route type, protocol and symptoms. Look for results you can reproduce, such as whether login completes, a long response gets interrupted or the connection recovers after standby—not isolated peak speeds. VPNXG offers coverage in 110+ countries across 160+ routes. That describes the range of options, not identical access conditions for every destination on every exit.

If you simply want to get connected, follow the steps in the quick-start guide. If you can already connect and want to compare options, continue with the sections below. Start with the symptom, then check the underlying explanation. Keep one confirmed working setup as your baseline, adjust one variable at a time and make sure you can restore the original settings. That keeps troubleshooting from introducing more uncertainty.

Trade-offs in stream protocols

Shadowsocks: lightweight encapsulation, varied implementations

Shadowsocks is built around proxy forwarding. Common implementations use authenticated encryption to protect data between the client and server. Its configuration concepts are relatively straightforward, but actual behavior still depends on the encryption method, client implementation and any additional transport layers. Configurations with the same protocol label are not necessarily identical. When your subscription provides the required settings, use them as given to avoid authentication mismatches or compatibility issues from manual changes.

A simple configuration can be a useful starting point on a resource-constrained device, but “simple” does not mean it will always use less battery. Hardware acceleration for the encryption algorithm, how often the app opens connections and any extra encapsulation all affect the result. Stream forwarding and datagram forwarding should also be considered separately: a working web page does not prove that an app relying on datagrams will work. Datagram support depends on the client and the networks along the route.

VMess: consider authentication and outer transport separately

VMess has its own authentication and data-handling mechanisms and can be paired with different outer transports. A configuration may show only the protocol name, while the actual path also uses WebSocket, TLS or another layer. Extra layers can help with deployment and compatibility, but they also add connection setup, buffering and processing costs. When comparing resource use, record the full combination so you don't mistakenly attribute the effect of an outer layer to the protocol itself.

Some VMess configurations are sensitive to the device's clock. A significantly incorrect system time can cause authentication failures or connection problems, so fixing automatic time synchronization is more targeted than repeatedly changing regions. Correct time does not rule out other issues: check whether your client supports the subscription parameters, whether the subscription has fully updated and whether the error occurs before reaching the remote server. Interpret diagnostic details by stage rather than drawing conclusions from a vague message.

Trojan: connection protection with TLS

Common Trojan deployments use TLS for transport protection, making certificate validation, the server name and system time part of the connection chain. Check certificate issues by verifying validity, name matching and the trust chain—not by disabling validation. Skipping verification changes the connection's security boundaries and can make a misconfiguration appear to work temporarily. For most users, keeping the verification settings supplied with the subscription is safer than editing those fields.

Using TLS does not automatically make a connection faster or slower. Initial setup usually involves negotiation, but connection reuse, server capacity and network round-trip conditions all affect actual wait times. If pages load smoothly on the same route but first-time logins are often slow, check DNS resolution, certificate negotiation and the platform's response. Sustained transfers depend more on congestion along the underlying route; the handshake alone cannot tell you how they will perform.

None of these protocols guarantees that an app will work. A destination platform may respond based on exit region, account status and its own rules, so verify route connectivity separately from whether the platform allows access. Start with a combination your client explicitly supports, then test with a real task. If a platform reports a region mismatch, check the exit and account conditions first rather than repeatedly changing encryption parameters. General principles can help narrow down the cause, but they cannot replace information returned by the service.

VLESS and QUIC-based transports

VLESS: lightweight authentication is not complete transport protection

VLESS is designed for lightweight authentication and forwarding; it should not be treated as a complete encryption solution on its own. Understand an actual deployment in combination with its security layer and transport. A field indicating that protocol-level encryption is not used does not mean the entire connection is unprotected. Conversely, a newer-sounding protocol name does not make every combination secure. Check the full configuration recognized by your client and use the settings provided by the service.

VLESS can be paired with different transports, so configurations using the same protocol may still differ in handshake, connection reuse and resource use. Calling a protocol lightweight usually describes one processing stage; it does not mean end-to-end latency will necessarily fall. If the remote route is congested or DNS resolution takes a long time, reducing local encapsulation work may not make a noticeable difference. First determine whether the bottleneck is processing, negotiation or network transfer, then consider whether simplifying that stage would help.

Hysteria2: congestion control meets network conditions

Hysteria2 is based on QUIC and uses its connection and stream management to carry proxy traffic. QUIC usually runs over UDP, but that does not mean it gives up reliable delivery: data that needs reliable delivery still uses acknowledgments and recovery. Its congestion handling, connection state and loss recovery differ from traditional TCP-based paths, so performance may vary under some network conditions. Judge any improvement with real apps; a protocol name cannot predict the result.

Avoid guessing at bandwidth parameters or setting them too high. If the client asks for expected bandwidth or a congestion-control setting, those values are inputs to its sending strategy, not a promise of bandwidth. Aggressive settings above your actual local capacity can increase queues, packet loss and delays for other apps. Start with the subscription defaults and only make evidence-based changes if problems persist. If you don't understand a parameter, leaving it at the default is usually more predictable than copying someone else's numbers.

TUIC: connection reuse has limits

TUIC also uses QUIC to carry proxy traffic, and its behavior depends on the client implementation, connection management and datagram handling. Reusing a connection can reduce some repeated work, but not every app request shares the same state, and a network change may still require a new connection. What a protocol can do, what a client enables and what a server supports are separate things. Don't turn possibilities in a technical description into guarantees about real-world use.

UDP-based outer transports also depend on whether the access network allows and reliably handles that traffic. Some guest networks support basic web browsing but handle datagram traffic differently. If this kind of configuration consistently fails to connect while a TCP-based one works, the outer transport is worth investigating—but it is not the only possible cause. Check client permissions, remote server status and configuration compatibility too.

Before comparing VLESS, Hysteria2 and TUIC, confirm they use the same region and route, then check the outer transport and client support. If your subscription doesn't offer a protocol, there's no need to convert configurations by hand just to use its name. Changing protocols cannot turn an ordinary public-internet route into a dedicated line or change how quickly the destination server responds. Treat protocol choice as a controlled variable when the route is already suitable but transport behavior still falls short—not as a universal fix for network problems.

For apps that need sustained responsiveness, watch for interruptions and recovery during a session—not just whether the connection button succeeds. For datagram-based apps, verify the actual traffic path; a web test alone is not enough. For differences between developer tools, see Choosing routes for AI coding tools, then relate the app's symptoms to the transport limits described here.

Connection setup and resource use

Why the first response depends on more than the protocol

Between clicking a link and seeing content, a device may resolve a domain, connect to a remote server, complete a security handshake, authenticate with the proxy, connect to the destination and wait for the server to respond. The connection status in a client usually covers only part of that process. So there's no contradiction when the client reports a successful connection but a page is still slow: reaching the access node doesn't mean the destination site has responded. Identify where the wait occurs—connecting the client, opening the page, submitting the request or receiving content.

Connection setup depends on round-trip paths. The more stages that exchange messages, the more sensitive they may be to round-trip delay, but the number of exchanges is not a fixed formula for user experience. Session resumption, connection pools, DNS caches and app behavior can all change the process. A fast page load may simply reuse an existing browser connection; a slow one may follow a device waking from sleep. Note the conditions for each test instead of comparing results from different states as if they were equivalent.

CPU, memory and connection count

CPU load mainly comes from encryption and decryption, data copying, rule matching and protocol processing. Performance depends on whether the system accelerates the relevant algorithms, how the client core handles buffering and whether heat has caused the device to throttle. Extra encapsulation layers usually add some work, but that doesn't necessarily make the experience worse: better connection management may reduce retries. Check device load and task interruptions instead of judging efficiency by how long the configuration looks.

Memory use depends on connection state, buffers, rule sets and logging settings. A browser loading several resources has more connection state to manage than a single static page; sync tools and developer environments may also run in the background. If the client's memory use grows over time, first distinguish more active tasks or retained caches from abnormal growth. Closing unrelated apps and checking again often gives a clearer answer than immediately replacing the entire subscription configuration.

Reuse, concurrency and over-tuning

Connection reuse can carry multiple logical requests over fewer outer connections, reducing repeated negotiation while making some requests share transport state. If that shared path becomes congested, multiple tasks may be affected; the extent depends on the transport and implementation. Reuse isn't always better, but there's no reason to disable it by default either. If the default settings work, don't change them just to optimize the nominal number of connections.

The same applies to concurrent downloads. More tasks can make better use of idle capacity, but they can also queue interactive requests from other devices on your home network. If download speeds rise while web browsing slows, overall resource allocation has changed; that doesn't prove the protocol has failed. Reduce competition from background sync and large file transfers, then test the target app again. For interactive work, leaving capacity for responsive traffic is usually more useful than chasing peak transfer speeds.

When a setting is complex, first work out whether it controls connection setup, sending behavior or data buffering. Then decide whether changing it is worthwhile. Change one setting at a time with a clear purpose, and note how to restore it. If a tweak only seems faster on an occasional visit and the result isn't repeatable, keep the default. The goal is an improvement you can explain and undo—not a more complicated configuration. Whether your real tasks keep working is the best measure of sensible resource use.

Mobile power use and background activity

Battery use is about more than encryption

Battery use on mobile devices depends on wireless signal strength, screen activity, CPU load, background wakeups and app requests. With a weak signal, the system may need to do more radio work to maintain communication; repeated app retries can also keep the device active for longer. So higher battery use while connected does not automatically mean the protocol's encryption is too costly. Before comparing protocols, make sure the network, foreground task and screen state are similar.

Maintaining a connection requires keeping state, but how often that happens depends on the implementation and settings. Frequent keepalives can wake the device more often; infrequent ones can let intermediate devices clear idle mappings, forcing a new connection when you return. There's no single right answer for every access network. If the default settings recover normally after standby, there's no need to shorten the interval. If recovery fails, first check whether the system suspended the app, then investigate connection maintenance.

Troubleshooting on Android and iOS

Android background behavior can be affected by power-saving policies and app background permissions. If the client connects in the foreground but requests fail after the screen locks, check whether background activity is restricted or the system is stopping its services. Work through the settings actually available on your device; there's no need to disable every power-saving feature. Allowing the client to run doesn't guarantee other apps will connect in the background—check their own restrictions too.

iOS manages network extensions at the system level, so leaving an app's screen does not necessarily stop its network extension. When troubleshooting, check the system connection state, errors recorded by the client and whether the target app has recovered. Changing access networks, waking from sleep and switching routing modes can all change the connection state. Toggling every setting makes the issue harder to reproduce. Instead, record what happened and in what order, then check whether the extension failed to resume, DNS resolution failed or the app kept an old connection.

Network changes and path migration

Switching from Wi-Fi to cellular data can change the local address, exit and intermediate network state all at once. Some transport mechanisms can preserve connection state under the right conditions, but that doesn't guarantee seamless recovery on every client and app. The app may need to rebuild its own session, and the platform may ask you to authenticate again. Check whether the task itself resumes automatically rather than relying only on the client's connection icon.

If every app fails after a network switch, first confirm the new network works, then reconnect the client. If only one or two apps fail, close their old sessions and test again. If a datagram-based configuration fails on one access network while another transport works, keep the working option as a fallback for that environment. One network-switching problem is not enough to conclude that a protocol type is unsuitable for every mobile device.

For battery comparisons, use similar tasks, networks and device temperatures, and check app activity in the system battery report instead of relying only on the battery icon. If the client logs and background behavior look normal but a video or sync app keeps transferring, the task itself may be the main source of battery use. For more Android troubleshooting tips, read Android background activity and per-app proxying. This page explains possible causes rather than ranking protocols by battery use.

Direct, relayed and dedicated network routes

Route labels describe the path, not its overall quality

A direct route usually means the client reaches a remote access node over the public internet. Traffic still passes through local carriers, backbone networks and interconnections; it isn't a physical link between just your device and the server. A relay route first reaches an access point, which forwards traffic to a later exit. An IEPL dedicated line uses dedicated transmission resources on the relevant link, but the path from your device to the access point and from the exit to the destination still matters. Treat route labels as descriptions of a segment, not the entire journey.

Adding a relay does not necessarily make a route slower. If the original public-internet path is congested or indirect, forwarding through another access point may provide a better onward route. On the other hand, a loaded relay or a longer path can add delay. What matters is where the data travels and how each segment performs—not how many technical terms appear in the route name. Keep the target app and access network constant to see the effect of a path change.

Distance, access segment and exit segment

Geographic distance sets a basic limit on propagation delay, but network traffic doesn't always follow the shortest line on a map. Interconnection arrangements, carrier policies and available capacity can send data along a longer route. Choosing a nearby region is a reasonable starting point, not a universal rule. A farther region with a better access and interconnection path may be more reliable for a particular task. Verify it with the target app instead of ranking regions by map distance alone.

The access segment runs from your device to the service's access point; the exit segment runs from the service's exit to the destination platform. If the first segment is smooth but the second is congested, the client may report a successful connection quickly while the page still takes a long time to load. Conversely, an unstable local Wi-Fi connection can cause repeated packet loss even if the exit is close to the destination. Breaking the path into segments helps avoid changing remote regions to fix a local problem.

Choosing a region and meeting platform requirements

A node's region determines how its exit appears, but destination platforms may use their own IP address databases, which do not always match the node's label. Platforms may also consider account region, content licensing and session state. If a platform reports a region mismatch, check the current exit and the platform's rules rather than assuming the region label in your client is wrong. An old session may retain its earlier assessment after you change exits, so verify in a new session.

For work involving extended interaction, watch for interruptions and recovery instead of checking only how quickly the home page opens. For continuous media, check whether the buffer stays filled. Route type helps organize a comparison but doesn't guarantee consistent performance at every time of day. See available regions and routes on the servers page. The configurations actually available to you are listed in your account panel; this guide does not assign latency or bandwidth figures to routes.

A practical order is to first meet the destination platform's region requirements, then compare route types within suitable regions, and finally compare protocols on the same kind of route. If you change the region, route and transport at once, you won't know what made a difference. Keeping a suitable everyday setup and a tested fallback is more reliable than constantly chasing routes with more elaborate names. New users can refer to Choosing a route by region, route type and use case.

Packet loss, queuing and peak-time congestion

Why data gets held up in transit

When a link receives more data than it can handle at that moment, packets queue up; once the queue reaches its limit, later packets may be dropped. Wireless interference, link errors and changes in device state can also cause loss. Packet loss therefore does not necessarily mean the remote node has failed, and added delay does not always point to insufficient server capacity. Consider when the problem occurs, the access network and which apps are affected rather than blaming every symptom on one cause.

At peak times, more traffic competes for shared links. Congestion can occur on your home network, access network, interconnection or at the destination platform. A configuration that works well at other times does not reveal which segment is congested. Compare different destinations and access networks: if every task slows down, look for a shared path; if only one platform is affected, investigate the route to that platform and the platform itself.

Recovery mechanisms and head-of-line blocking

Reliable transports recover lost data through acknowledgments, retransmissions and other mechanisms. Recovery takes time and can delay delivery of later data to the app. TCP byte streams deliver data in order, so a missing segment can hold up later data. QUIC can reduce some delivery blocking between independent streams, but ordering within a stream, shared congestion state and real link capacity still matter. A different transport can change recovery behavior, but it cannot make lost data disappear without being handled.

A saturated upload can also slow tasks that appear to be mostly downloads. Requests, acknowledgments and control messages need the upstream path too; when background sync or a large upload fills the queue, web interactions can become noticeably slower. In this case, changing nodes may do little. Pausing uploads is a low-cost, easy-to-interpret test. If the problem goes away, address local task competition before searching for a supposedly stronger encryption protocol.

Use symptoms to choose a troubleshooting path

If page text appears but images or video take a long time to load, different resource domains, DNS routing, split-tunneling rules or the media-server path may be involved. First check whether only specific resources fail, then see whether the client sends those requests through the expected exit. Consider a shared link only if all resources pause intermittently. Partial page loading does not prove the network is entirely healthy, and one failed image does not mean the whole subscription is unusable.

If a connection works but larger transfers repeatedly stall, consider whether the path handles packet sizes differently. Tunnel encapsulation adds data, and a path that does not handle packet-size discovery correctly can allow small requests while disrupting larger transfers. This is one possible cause, not a reason to change packet sizes whenever something stalls. Without clear evidence, keep the default settings and note whether the issue recurs on different networks; that is more reliable than copying parameters from the web.

Start troubleshooting locally: confirm the original network can reach basic services, pause competing tasks, check the system time and client status, then compare a known working route to the same destination. Next, check whether only one transport or region fails and whether the issue depends on the time of day. Record each change and its result. Don't change DNS, protocol and region all in one test; even if service returns, you won't know what to repeat next time.

If you contact support, include your access network type, when the issue occurred, the target app, node name and steps to reproduce it. Describe the comparison tests you've already tried. Remove subscription URLs, authentication fields and account details from diagnostic records; never share your full configuration. Continue troubleshooting through support tickets in the account panel. Server-side status becomes much more useful when it can be matched with client observations than a context-free report that things are slow.

Build a selection process around your use case

Web browsing, AI tools and developer workflows

For everyday browsing, start with a configuration that meets the region requirements and is supported by your client's default settings. Check whether logins, searches and page resources all work. If the home page loads but a login redirect fails, check the redirect domain and session requirements before changing the entire transport setup. If you switch between many sites, first-response time and connection recovery both matter. Clear routing rules and fewer conflicting network tools are usually more helpful than repeatedly tuning low-level settings.

AI chats, code completion and command-line tools may use streaming responses, long-lived connections or different proxy settings. Browser access does not prove that an editor or terminal uses the same exit. First check whether the app reads the system proxy, needs its own network settings and fails during authentication, connection setup or the response. Verify each app separately because their configuration options differ; a browser test cannot tell you how every developer tool behaves.

If a streaming response stops midway, the cause could be the network path, platform load, account requirements or the app's timeout policy. Reproduce the issue with the same destination and client, then compare a fallback route. If only one tool fails, check its error message. Don't paste access credentials into public diagnostic pages or share request headers. For developer workflows, knowing which connections use the proxy matters as much as choosing a protocol.

Streaming, real-time communication and mobile use

For streaming, first meet the content region and account requirements, then check whether playback stays smooth over time. If playback starts quickly but buffers repeatedly, investigate sustained throughput and competing tasks. A platform message about region or account restrictions is not evidence of insufficient bandwidth. Check actual access to the destination platform; a protocol cannot replace content licensing. See the streaming support page for ways to verify access, then compare routes using the guidance in this page.

Voice calls, remote desktops and interactive tasks are more sensitive to changes in wait time and brief interruptions. Test a real session rather than just downloading a file. If an app needs datagrams, first confirm the client and configuration actually carry that traffic. For mobile use, also test recovery after locking the screen and switching networks. A configuration that downloads continuously may not be the best choice for low-latency interaction; one that connects quickly once may not recover reliably after standby. Test the full workflow you actually use.

Start from a baseline and make changes you can undo

First make sure the subscription has fully updated, then use a configuration your client supports by default to verify the basics. Keep the target app and access network constant, then compare region, route type and protocol one at a time. When a problem occurs, record it and switch back to the baseline. If the baseline also fails, broaden the troubleshooting scope; if only the new configuration fails, check the condition you just changed. This process makes useful findings easier to keep than changing everything at once.

Choose subscription capacity separately from technical performance. Monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Data resets monthly on the activation date, and mid-cycle upgrades are prorated based on the remaining days. Data add-ons are ¥158/300GB, ¥358/1000GB and ¥658/3000GB; they remain valid until used and never expire. A higher data tier does not prove that a protocol is faster. See the plans page for full details.

VPNXG supports Windows / macOS / iOS / Android / Linux, with unlimited simultaneous devices. No email address is required; create an account with a username and password. Sign in to get the client and subscription from the download section in the account panel. Installers are available according to the active plan shown in the panel. Our privacy policy states that we keep no logs, and the service offers a 7-day no-questions-asked refund. Base technical decisions on verifiable real-world tasks; these service details are not performance guarantees.