Protocol and route technology reference

A layered look at protocols, clients and routes

Same name, different paths

A web request can pass through the application, the operating system's network interface, the client, an entry server and the destination service. A proxy protocol defines how one part of that connection authenticates, encapsulates and forwards data; it does not determine the entire route. Nodes using the same protocol may still differ in entry point, exit network, transport and congestion. Before comparing connection quality, establish whether you're comparing protocol implementations or two entirely different network paths.

The client turns subscription parameters into an actual connection and also handles DNS resolution, rule matching, connection reuse and system-level routing. A subscription delivers configuration; it is not an acceleration technology in its own right. Updating one may change node addresses, certificate details or routing rules, but it won't fix a weak Wi-Fi signal or make a destination website respond faster. Understanding this distinction helps avoid blaming every issue on an expired subscription or repeatedly importing the same configuration.

Break the problem into observable stages

A connection can be broken down into resolving the entry address, reaching the entry server, authenticating, connecting to the destination and receiving an application response. A page that stays blank could be stuck at any of these stages. If DNS resolution fails, the client may never start the protocol handshake. If authentication fails, the route itself may be reachable. If the destination is slow, the proxy tunnel may be working normally. When troubleshooting, note which stage failed instead of simply writing “the node doesn't work.”

Routing rules determine which requests go through the proxy and which use the regular network route. Being able to open a website in a browser doesn't mean every app takes the same path; enabling the system proxy doesn't mean every app follows its settings. A virtual network interface can cover more application traffic, but its scope still depends on the client, platform permissions and rules. To check the route, use the application you actually need and look for the corresponding connection in the client.

Keep service coverage separate from technical conclusions

VPN94 covers 100+ countries with 190+ routes, supports Windows / macOS / iOS / Android / Linux, and allows unlimited simultaneous connections. These describe service coverage, not a guarantee of any route's throughput or reachability. Check the account panel and your client for current nodes, available protocols and client capabilities. The protocols discussed here provide a framework for technical comparison; not every node necessarily offers every combination mentioned.

Protocols should also be considered separately from transport and encryption layers. VLESS, for example, describes proxy interactions, while the outer transport and security settings affect how the connection behaves. Trojan typically relies on TLS for transport security, but certificate validation still depends on configuration. Node names often leave out these details, so a short label can't reveal the complete technology stack. For a closer look, check the protocol and transport fields reported by your client instead of guessing from an icon or name.

A short, contextual log is more useful than a pile of speed-test screenshots. Note your network, whether you're on a wired connection, the application, selected node, protocol and symptoms. Specify whether the delay happens on first load, during sustained transfers or when resuming after idle. Before sharing, remove account details, subscription URLs and authentication data. Clear notes help with self-diagnosis and help support distinguish between local access, the proxy connection and the destination service.

Design trade-offs in streaming protocols

Shadowsocks and VMess

Shadowsocks uses a relatively simple proxy wrapper to forward traffic. Common implementations protect data between client and server with encryption and authentication. Its behavior depends on the chosen cipher, implementation and transport, so you can't infer resource use from the name alone. Its strengths often include a mature ecosystem and straightforward configuration, making it a practical choice where compatible clients are already in use. Check that both client and server support datagram forwarding if you need it.

VMess includes authentication and its own data-handling logic within proxy sessions. It is often used with different outer transports, so connection quality depends on the protocol implementation as well as the encapsulation and server deployment. One underperforming VMess node doesn't mean all nodes with the same label will be slow. If your current setup is stable, consider switching for a compatibility requirement or a reproducible issue—not just because one protocol name sounds newer.

Trojan and VLESS

Trojan typically runs over a TLS connection, with the outer secure transport providing encryption and the protocol handling authentication and proxy requests. The certificate, domain and server settings must match. Disabling certificate verification may hide an obvious configuration error temporarily, but it also removes normal checks of the server's identity. If you see a certificate error, check your system clock, subscription and node settings rather than treating verification bypass as a routine performance tweak.

VLESS keeps its own data handling lightweight; its security depends on the outer security mechanisms in use. Seeing VLESS doesn't mean your data is automatically protected, nor does it guarantee lower battery use than another protocol. The outer transport, connection reuse and implementation can all change the outcome. For a reliable setup, import the complete configuration from your provider instead of copying only the protocol name and assembling security or transport options you don't understand.

TCP reliability and the cost of waiting

These protocols are often used with TCP-based transport, but a protocol name does not map one-to-one to an underlying transport. TCP provides an ordered, reliable byte stream, so the receiver delivers data in sequence. When packets are lost along the route, later data may have arrived but still has to wait for the missing part to be retransmitted. That reliable delivery matters for web and file transfers. When many tasks share one ordered stream, however, a delay can hold up data that wasn't lost.

Extra encapsulation is usually there for compatibility, deployment or connection management; fewer layers aren't automatically better. Another transport layer may add handshakes and processing, but it may also suit the network conditions or server setup. Removing an encapsulation blindly could break the connection format required by the server. Adjust advanced client settings to address a specific issue, change only options you understand, and keep a copy of the original configuration so you can restore it.

For everyday use, start with a setup that works well on your platform, validates certificates correctly and shows clear connection logs. If browsing and persistent connections are stable, there's no need to keep switching just to chase a protocol name. To check which combinations a particular node supports, see Server and Network Route Details and the account panel. Treat this article's technical categories as a guide, not an inventory. Choose a protocol to solve a problem in your current setup—not to collect names.

Hysteria2 and TUIC: transport considerations

QUIC changes how transport is organized

QUIC runs over UDP and combines secure handshakes, reliable data streams and connection management at the transport layer. UDP itself doesn't guarantee delivery, but that doesn't mean QUIC-based application traffic is inherently unreliable; reliability can be implemented at a higher layer. This distinction helps avoid equating “uses UDP” with “unreliable” or “uses QUIC” with “faster on every network.” The underlying datagrams still need to get through.

QUIC can carry independent streams within a single connection. If data on one stream needs retransmission, other streams don't have to wait for an ordered transport-layer byte stream. But all streams still share the available link capacity and congestion conditions. Weak Wi-Fi, a backed-up exit queue or limited server resources won't be fixed by multiple streams. QUIC can reduce certain kinds of head-of-line waiting; it can't remove the physical limits of a network or guarantee a consistent experience for every app.

Hysteria2 congestion control must suit the network

Hysteria2 uses QUIC and has transport and congestion-control features designed for proxy traffic. Implementations may offer bandwidth-estimation settings or use different congestion-control paths; check what your client supports. Setting bandwidth-related options higher won't automatically increase throughput. An inaccurate estimate can lead to longer queues, packet loss and interference with other traffic. If you aren't sure what a setting does, keep the defaults supplied by your subscription or client.

Hysteria2 is worth comparing on networks with random packet loss or route fluctuations, but results depend on the route. If the network restricts UDP, you may see failed handshakes, dropped connections after idle or interrupted transfers. Keep another working transport option as a fallback, and check the local network before tuning parameters. Repeatedly changing congestion settings won't make an unreliable underlying path reliable.

TUIC connection handling and implementation differences

TUIC also uses QUIC to carry proxy traffic, organizing communication around connection reuse, streams and datagram forwarding. Its behavior depends on the client implementation, server configuration, route quality and application. For many short connections, connection persistence and reuse can affect the time to first request. For sustained transfers, congestion control and server capacity matter more. The fact that both TUIC and Hysteria2 use QUIC doesn't mean they behave identically.

QUIC connection IDs provide a basis for handling route changes, but migration depends on implementation, configuration and peer support. When a device switches from Wi-Fi to a mobile network, an app may still need to authenticate again, and the operating system may suspend background activity. Migration support doesn't guarantee uninterrupted service in every app. To compare switching behavior, check whether your actual task resumes, not just whether the client still shows its connection as active.

Test with real tasks, not just a successful connection

A successful handshake in the client confirms only that authentication and the initial connection have been established. Datagram forwarding, large responses and recovery after idle may still be affected by network equipment or path MTU. Test ordinary browsing, sustained downloads and apps that need datagrams separately to see whether the issue is limited to a particular type of traffic. A continuous high-volume test can mask idle-recovery problems: constant traffic refreshes connection state in network devices and changes the conditions you're trying to observe.

When choosing one of these protocols, consider both compatibility and resource cost. QUIC often relies on more user-space transport processing, which can become noticeable on less powerful devices, with many concurrent connections or at high throughput. A good implementation may also reduce certain delays and improve responsiveness. A claim that one protocol is a must-have, without context about the device and network, won't generalize. A suitable choice should deliver acceptable, repeatable results during normal use, after idle and when the network changes.

Connection setup, throughput and resource use

First load and sustained transfers measure different things

Loading a page for the first time can involve DNS resolution, a proxy handshake, a connection to the destination and an application request. A sustained download is a better test of whether an established connection can transfer data consistently. The results can feel quite different: one route might respond slowly at first but download steadily, while another opens pages quickly and then fluctuates during a transfer. “Fast” needs to describe a specific task; otherwise, it's unclear what's being compared or whether you should change the protocol or the route.

Connection reuse lets later requests share an existing connection and avoids the cost of setting up a new one, but it can also make multiple requests share the same point of failure. Distinguish between a fresh launch, a warmed-up connection and a connection that's been idle for a long time. Browser and DNS caches, along with existing destination connections, can all affect results. Repeatedly refreshing the same page often measures cached content and an existing connection—not a true first-load experience. Note these conditions when recording results.

Encryption isn't the only source of resource use

A client handles more than encryption and authentication: it also encapsulates packets, matches rules, resolves domains, forwards traffic through virtual interfaces and writes logs. At high throughput, memory copying and user-space processing may matter more than the size of a protocol header. With many short connections, connection management and rule evaluation may be more significant. Hardware acceleration, operating-system networking and client code paths vary, so the same protocol can use resources differently across platforms. Don't extrapolate desktop results to mobile devices.

Memory use also depends on what the client is doing. Nodes and rules in the subscription need storage; domain and connection caches grow with use, and active connections hold buffers. Memory not dropping immediately after a connection ends doesn't necessarily indicate a leak—the runtime may keep space for later requests. Look for steady growth under similar workloads, effects on other apps and whether the problem recurs after a restart during a particular task. One isolated memory reading tells you little.

Set up a repeatable comparison

Before comparing, stop unrelated high-volume tasks and keep your network location and destination service consistent. Then change the selected node or protocol. Don't change routing mode, DNS settings and protocol all at once: even if performance improves, you won't know which change helped. After each change, repeat the same tasks—open a page, use the connection continuously, then test recovery after idle. If the destination service is variable, cross-check with a similar one instead of running more and more concurrent speed tests.

If CPU use rises while throughput stops improving, check whether the virtual interface, complex rules or client implementation is a bottleneck. If the device is idle but every destination is slow, look more closely at local access and the route. If only one service is slow, first check destination-side throttling, regional routing and app retries. Switching protocols shouldn't be your only troubleshooting method: it may change the entry and exit as well, temporarily avoiding the actual issue without identifying it.

A useful technical note gives a conclusion with clear conditions, such as: “On this Wi-Fi network, the selected node is steady during sustained transfers, but reconnects after idle.” That's more useful than “this protocol is fastest” and easier to retest when network conditions change. For traffic costs, see Plan Pricing; repeated speed tests aren't routine maintenance. Testing should help you make a choice. Once you have enough to decide, stop and observe the connection under your real workload.

Mobile battery life and background behavior

Wake frequency may matter more than the protocol name

Mobile power use comes from the processor, wireless radios and screen. When a proxy connection stays active in the background, keepalives, DNS requests, app notifications and retries can all prevent the device from sleeping for long. So battery life can't be judged by whether a protocol is “lightweight.” A protocol with low processing overhead may still use more power overall if the connection keeps dropping and retrying. A stable network and sensible background behavior often matter more than switching protocols.

Keepalives maintain connection state in network devices and help detect a failed path. An interval that's too short can cause more background wakeups; one that's too long may let network equipment drop an idle connection. There's no single setting that suits every network. Client defaults are usually a reasonable starting point. Adjust them only when you've observed a specific idle-recovery problem and understand which type of connection the setting applies to. Simply shortening the interval isn't a universal fix.

Troubleshoot background limits and network changes separately

If the connection works in the foreground but drops only after the screen locks, first check whether the operating system restricts background activity or the client lacks a required network permission. If it fails only after switching between Wi-Fi and a mobile network, the cause is more likely to be a route change, reauthentication or recovery of an old connection. Both issues can occur at once, but they need different troubleshooting. Test recovery after locking the screen on a fixed network first, then test a deliberate network switch. This helps distinguish system suspension from a lack of protocol migration support.

Low Power Mode, data-saving settings and manufacturer background policies can all change network behavior. Before relaxing restrictions, understand that doing so allows more background activity; it doesn't automatically improve route quality. Grant the client only the permissions it needs, and leave other system protections in place. If the app itself is suspended in the background, an active proxy connection can't keep all of its activity running. To identify where a connection drops, check whether other apps lose connectivity at the same time and whether the client must reconnect when it resumes.

Compare battery use under similar workloads

When comparing battery use, keep screen brightness, foreground app, signal strength and activity as similar as possible. Video and text browsing use different amounts of data, while system updates and photo syncing can add substantial background traffic. System battery reports may group some network-extension overhead under other items, so the percentage shown beside the client isn't the whole story. Look at overall battery change, device temperature, how often the connection retries and whether the same task produces a noticeable difference.

Split tunneling can keep traffic that doesn't need a proxy off the connection, but accurate rules matter more than having lots of them. Splitting an app that relies on several domains across different routes may cause retries or authentication issues; sending all traffic through a proxy can add unnecessary processing and data transfer. Start with a complete ruleset that matches your client, then adjust it to address a specific issue. Afterward, check that the app works and connection logs match expectations. “Connected” in the client isn't enough to confirm success.

On mobile, keep a reliable default for networks you use regularly and a compatible alternative. If the device gets hot, background traffic keeps growing after the screen locks, or logs show repeated reconnects, first stop unnecessary diagnostic logging and check background tasks. Get clients through the user panel; subscription access is available after you sign in. Check the panel for current iOS requirements. Follow the Setup Guide for installation and permissions; this chapter covers how to choose and evaluate a setup.

Direct, relayed and dedicated route topologies

Consider the entry, transport and exit separately

A network route can be understood in terms of its entry point, transit across networks and exit. The entry is where your device connects first; transit is how traffic travels through the networks that follow; the exit is the source address the destination service sees. Geographic distance is only one factor—carrier peering, routing policies and congestion can all change the path. A country or region in a node's name usually describes its exit, not necessarily its entry point, so map distance alone can't tell you how well a connection will perform.

Direct connection usually means your device connects to the selected server entry without a separate, explicit proxy relay. Internet traffic still passes through multiple network devices and carriers. A simpler route may involve fewer deployment steps, but a poor connection between your local network and the remote network can still cause fluctuations. Direct doesn't mean low quality, nor does it mean there are no intermediate hops. Judge its suitability against your current network and tasks rather than the label.

Relays change how traffic reaches a remote exit

A relay adds a forwarding entry between your device and the remote exit. Traffic first reaches a more suitable access point, then travels over the onward network. The extra step may add some baseline delay, but it can also avoid a poor public peering route. That's why a relayed route can be more stable on some networks. Its value depends on how well the entry, transit and exit work together—not simply on adding another server or counting forwarding hops.

An IEPL dedicated line generally refers to an international Ethernet private-line segment within the transport path. For subscription users, this describes topology; it doesn't guarantee end-to-end exclusive capacity. Your local Wi-Fi, the connection from your device to the entry point, server resources and the route from the exit to the destination may still be shared or congested. Even a stable dedicated segment can't prevent issues elsewhere, so the label isn't a promise of consistent performance across all times and applications.

Outbound and return paths may differ

Network routes aren't always symmetric. Data sent by your device and responses from the remote server may travel through different carriers and peering points. Downloads may work while uploads fail, or requests may go out quickly while responses take a long time. You don't need to identify the exact faulty device to make sense of this, but don't treat a one-way test as representative of the entire route. If you contact support, describe whether uploads, downloads or interactive tasks are affected; that's more useful than reporting only a latency reading.

An exit region also doesn't guarantee that a service will show content for that region. Services may consider account details, payment information, device location, caching and exit-network attributes. If the content doesn't change after switching nodes, that doesn't necessarily mean the route didn't change. Conversely, a different result from an IP lookup doesn't guarantee an app will show content for the same region. For streaming or work accounts, follow the service's rules and distinguish content-region issues from connection problems rather than repeatedly switching routes and triggering authentication checks.

Start by comparing routes with the same topology, then compare across types. Keep a default and an alternative for the networks you regularly use, and focus on how real tasks perform during working hours. When reading the IEPL and Network Route Guide, note that available routes are shown in the account panel; examples don't tie a particular region to a fixed topology. Node names help you find options, but a sound comparison needs repeatable checks of entry reachability, sustained transfers and access to your destination.

Troubleshooting packet loss and peak-hour congestion

Packet loss doesn't always come from the remote route

Packet loss can happen on Wi-Fi, at a home router, between carriers, at a server entry or along the exit route. Radio interference, device power-saving, router load and full link queues can all show up as pauses or video buffering. More retransmissions don't automatically mean the remote node is at fault. First check whether ordinary browsing on the current network also shows problems, then test another access network. This helps establish whether the issue starts before traffic enters the proxy.

Congestion means a link can't handle all incoming data in time. Packets may queue, then be dropped when buffers fill. Queueing increases delay, so interactive tasks can slow down before packet loss becomes obvious. A sustained download that saturates your local upload can also interfere with ordinary requests and acknowledgments. Peak-hour slowdowns may compound with heavy traffic on your home network. Pausing background transfers and testing again is an easy, informative first check.

Separate small requests that work from large transfers that fail

If simple pages load but large images, uploads or sustained transfers often stall, consider path MTU, datagram forwarding or differences in destination handling. Virtual interfaces and tunnels add encapsulation overhead; if path MTU discovery is blocked, certain types of traffic can stall. That doesn't mean you should change the MTU every time this happens. First check that the problem reproduces across destinations, then follow your client's documentation or support advice instead of using arbitrary settings to mask congestion.

If only one app has a problem, start with its error message, account status and connection logs. A request rejected by the destination is different from a failed proxy handshake. A domain matching the wrong rule is different from the whole route being unavailable. If every app is affected, check local access, client status and the node. Narrowing the cause by scope is more effective than reinstalling the client at random and preserves useful diagnostic information. Repeatedly clearing settings may change the symptoms temporarily while making the original conditions impossible to confirm.

Verify peak-hour slowdowns across different paths

If a connection works during quiet hours but slows at busy times, that may indicate congestion on a shared link or exit. But peak demand at the destination website can look similar. Keep the destination constant while comparing different entries or transit routes, then keep the route constant while comparing destinations. If every route to one service is slow but other services work, the destination is a stronger suspect. If all external access slows on the same network, check local access and the carrier route before switching protocols again.

Changing protocols affects how transport handles the current route; it can't add capacity to a saturated link. A more aggressive sending strategy may sustain throughput temporarily, but it can also cause longer queues and more packet loss. A more conservative strategy may reduce peak speeds while keeping interactive traffic smoother. What matters is performance for your task, not a bigger number on a speed-test screen. For video quality issues, see How Bitrate, Bandwidth and Video Quality Interact to distinguish buffering from content quality settings.

When contacting support, note your network, device platform, selected node, affected task and reproduction steps, along with the comparisons you've already tried. Share only the necessary log excerpts and remove subscription URLs, usernames and authentication data. Contact support through the user panel ticket system. While the cause is unclear, you can use a tested alternative route to keep working and retain the original notes. Restoring service and identifying the cause can happen in parallel; repeatedly restarting and hoping for the best isn't necessary.

Choosing protocols and routes for your use case

Web browsing, documents and AI tools need responsive connections

Web browsing and online documents rely on quick first responses, short requests and connections that stay open. AI tools may also stream generated content, so loading the page doesn't guarantee that responses will continue smoothly. Start with a route that authenticates reliably on your regular network and recovers well after idle, then check for interruptions during generation. If an app reports an error, check the destination service and account requirements too. Not every response problem is caused by the protocol, and repeatedly switching exits isn't a substitute for finding the cause.

For these tasks, start with a well-supported client and a compatible default setup. If the first visit is slow, check DNS and connection setup. If ongoing responses stop, check route stability, background restrictions and connection recovery. QUIC-based options are worth comparing if the current network supports them. Choose based on whether requests complete reliably on your device—not on claims that a protocol suits every AI tool. Reassess when the task, device or route changes.

Streaming, downloads and real-time tasks have different priorities

Video and large files depend more on sustained throughput and how much it fluctuates. A brief fast transfer doesn't mean an entire video or download will be smooth. Playback also depends on the platform's encoding, content delivery, account access and device decoding. Check whether buffering continues to increase or picture quality changes repeatedly as the network fluctuates, then compare routes. An IEPL label doesn't guarantee a particular content region or picture quality, and automatic quality selection isn't a pure speed test.

Meetings, voice calls and interactive tasks are more sensitive to fluctuating delay and datagram handling. Occasional long queues can be disruptive even when average latency is similar. Check that the client supports the forwarding mode the task needs, and avoid saturating your network with background transfers. A route that performs well for downloads isn't necessarily the best for real-time use. Test in the actual meeting or app, paying attention to audio continuity, response time and recovery after a network switch—not just file download speeds.

Choose a subscription after checking technical compatibility

You don't have to use the same protocol on every device. A desktop setup might prioritize sustained transfers and work-app compatibility, while a mobile setup might prioritize background recovery and battery life. VPN94 allows unlimited simultaneous connections, but client features, system permissions and network conditions still vary by device. Keeping a stable configuration for each device is more reliable than copying advanced desktop settings to a phone. If available subscription options change, update and check compatibility before changing your long-term default.

Assess technical fit separately from billing. VPN94 monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Data resets monthly on the activation date; mid-cycle upgrades are prorated based on the remaining days. Data packs cost ¥158/300GB, ¥358/1000GB and ¥658/3000GB; they remain available until used and never expire. Choose based on your usage and data needs, not the protocol name. See the Plans page for details; plan tiers aren't speed ratings.

Use a clear decision order: check platform and protocol compatibility, confirm the network can reach the route, compare real tasks, then choose a default and a backup route. VPN94 requires no email address; create an account with a username and password. It has a no-logs policy, a 60-day no-questions-asked refund policy, and supports Alipay / WeChat Pay / USDT. These service details help you review subscription terms, but don't replace technical testing. If the terminology is unfamiliar, read A Quick Guide to Subscriptions, Nodes and Routing Rules, or return to the Setup Guide and follow the configuration steps.