SpaVPN Protocol and
Route Technology Guide

Connection model: distinguish the protocol from the route

A connection is already at work before a webpage appears

A typical visit involves resolving a domain, connecting to a server, completing a secure handshake, sending a request, and receiving content. The client may first decide whether the request should use a proxy and, if so, which exit to use. A page that takes a long time to appear does not necessarily mean there is too little bandwidth: DNS delays, a failed handshake, or a slow connection from the exit to the destination can all occur before the page starts downloading. So when comparing speed, be clear about whether you mean page load time, sustained downloads, or recovery after a dropped connection.

A protocol defines how the client and server identify requests, protect content, encapsulate data, and manage connections. A route describes the network path the data takes. The same protocol can perform very differently on different routes, and routes in the same region can vary depending on the entry point, carrier network, and exit data center. A protocol name alone cannot predict how a route will perform on a particular local network. A region label can help narrow down options, but it is not a complete description of the path.

The transport layer and proxy layer are different choices

TCP provides a reliable, ordered byte stream. Lost data must be recovered, which can hold up later content. UDP carries datagrams but does not guarantee reliability or ordering; QUIC, which runs over UDP, can provide reliable streams, congestion control, and secure connections. Calling UDP simply “faster” or TCP simply “more reliable” overlooks the implementation above the transport layer and the conditions along the route. Assess the transport semantics an app needs separately from the transport used by a proxy tunnel.

For example, a browser might access a TCP-based website through a proxy tunnel, or send a request that needs datagram forwarding. If the client does not support forwarding, the server does not accept it, or routing rules do not send the request through the tunnel, some apps may not work properly. A successful connection test only confirms the specific flow it tested; it does not automatically verify DNS resolution, datagrams, background operation, or every app.

Narrow down the issue based on symptoms, not labels

First establish the scope: are all apps inaccessible, or just one website? Does the connection fail right away, or stall after running for a while? Does switching local networks fix it, or does switching exits? The clearer the scope, the more useful the next comparison will be. If regular websites work but one service refuses access, check that service’s region, account, and access rules instead of resetting the entire client configuration.

Keep the same layered approach when comparing options. Protocol compatibility, route stability, and destination service rules are separate questions, each requiring its own evidence. SpaVPN covers 100+ countries / 240+ routes. See the network page for available regions and route types. Coverage figures alone do not mean that every local network takes the same path to every destination. The comparisons below explain how things work; they are not fixed speed rankings for any region.

Stream protocols: design trade-offs and compatibility

Shadowsocks: check encryption methods and implementation compatibility

Shadowsocks is a family of proxy protocols. Common deployments use authenticated encryption to protect data between the client and server. Its configuration is relatively straightforward, but the name alone does not tell you whether a setup is compatible: the client’s supported encryption methods, key format, datagram support, and server settings must all match. Being able to import an older configuration does not mean the current client can use it fully. Choosing an entry already matched in your subscription is usually safer than assembling parameters by hand.

Resource use depends on the encryption algorithm, device instruction support, implementation, and concurrent activity. Calling a protocol “lightweight” does not mean it will use less power on every device, nor does it make authentication or misconfiguration unimportant. If only one type of request fails, check the client logs to see whether the issue is DNS, authentication, or datagram forwarding before switching protocols. This helps avoid mistaking a specific compatibility issue for a route-wide outage.

VMess and VLESS: separate the protocol from the outer transport

VMess includes authentication and data protection mechanisms, and real-world configurations can use different transport methods. The client and server must agree on authentication details and transport encapsulation; a device clock that is significantly off can also affect authentication. For an authentication error, first check automatic time settings, whether the subscription is up to date, and whether the entry was edited manually. Repeatedly tapping Connect will not fix mismatched credentials or unsupported encapsulation.

VLESS keeps proxy-layer authentication and request handling relatively lightweight. It does not provide content encryption in the traditional sense, so it should not be assessed separately from the secure transport layer around it. When you see VLESS, check whether it is paired with an appropriate security mechanism such as TLS, and whether the client supports that combination. Fewer fields are no reason to ignore the security layer; account for the outer transport, connection reuse, and handshake when considering real-world overhead.

Trojan: TLS settings are part of the connection

Trojan typically uses TLS to carry proxy requests, with certificate validation, the server name, and authentication credentials all involved in the connection. If the client reports a certificate mismatch, check the server address, server name, system time, and subscription source. Do not make disabling validation your go-to fix. A validation failure can result from incorrect settings or an interference page on the local network. Check each possibility based on the error rather than hiding the warning and carrying on.

For these protocols, the first connection may include a transport handshake, a security handshake, and proxy authentication. Later requests may reuse an established connection. When comparing protocols, distinguish a fresh connection from continued use; do not compare one protocol’s first connection with another protocol’s reused connection. Reuse can reduce the need to reconnect, but it can also make multiple requests depend on the same underlying connection. The actual effect depends on the implementation and workload.

Configuration limits: This article explains protocol mechanisms; it does not mean every combination is available in every region. Check the entries actually listed in your account’s subscription panel and confirm client support.

Start with an existing entry that is compatible with your client. If it works reliably for everyday browsing and office apps, there is no need to keep switching just because a protocol name is new. If a specific problem occurs, try another transport based on the stage where it fails. Change only one protocol or route setting at a time so you can tell what made a difference. No protocol has a universal ranking independent of device, route, and destination, and a protocol name alone cannot tell you how many resources it will use.

QUIC protocols: recovery and route conditions

What Hysteria2 and TUIC have in common

Hysteria2 and TUIC both use a QUIC-based approach over UDP, but they are not interchangeable protocols with the same configuration. QUIC combines secure connections, reliable transport, and stream management. Delivery can be managed separately for different streams, reducing the direct blocking effect of missing data in one stream on others. Congestion on the underlying route still affects shared bandwidth, so greater independence between streams does not mean each app has its own unaffected network resources.

QUIC connection setup can combine transport and security negotiation, with designs that may reduce repeated exchanges. Whether this helps depends on whether the connection is new, whether the implementation supports session resumption, whether the network allows the relevant packets, and whether the server accepts the flow. Do not turn a design capability into a guarantee that every connection will be faster, especially when DNS resolution and connecting from the exit to the destination also take time.

Assess congestion control and bandwidth settings in context

Common Hysteria2 configurations include bandwidth and congestion-control settings. Setting an unrealistically high bandwidth expectation cannot increase capacity on the local connection or remote route. It may instead make sending behavior a poor fit for the path, causing queueing, packet loss, or competition with other apps. A conservative setting could also limit the capacity you can use. Keep subscription-provided parameters unless there is a reason to change them. If you do need to adjust them, consult the client documentation rather than copying a screenshot from a different network.

TUIC also requires the client, server, and certificate validation settings to match. It can use QUIC’s connection and stream management, but the experience still depends on implementation scheduling, congestion control, and datagram handling. Field names can differ between clients, and a missing option in the interface does not mean you can substitute a parameter with the same name from another protocol. If importing an entry fails, first confirm that the client explicitly supports it.

Keep an alternative route available when UDP performs poorly

Some access networks have UDP forwarding policies, idle mappings, or transport quality that make long sessions unreliable. Symptoms may include a handshake that never completes, a connection that drops shortly after connecting, or trouble recovering after switching networks. Trying a TCP-based entry is a useful way to narrow down the issue. If the alternative is stable but QUIC entries repeatedly fail on the same access network, investigate the path conditions before assuming the device lacks performance.

Also consider the size of encapsulated packets. Tunnels add headers, and the maximum packet size a route can carry can vary. If small requests work but large responses or datagram-based apps stall, investigate path MTU discovery, fragmentation handling, and intermediate devices. Do not keep reducing related settings without evidence. Save the original values, check whether the client handles this automatically, and use reproducible symptoms to decide whether further troubleshooting is needed.

When switching mobile networks, QUIC’s connection ID mechanism provides a basis for migration. But a protocol’s built-in capability does not guarantee that a particular client will preserve an app session. App timeouts, operating-system background limits, or server policies can still end a request. A meaningful comparison checks whether the actual task continues after the switch, not just whether the client icon changes. For tasks that cannot resume, also check whether reconnecting is clear and manageable.

How to choose: If UDP works reliably and your client fully supports the entry, consider Hysteria2 or TUIC as options to compare. If UDP is restricted, keep a compatible stream-based entry as an alternative rather than ruling it out based on the protocol name.

Route topology: direct, relayed, and dedicated routes

Direct describes the route, not a guaranteed level of service

A direct route usually means the client connects straight to an overseas entry point, without an additional relay node operated by the service. The topology is simpler, but data still passes through the local connection, carrier network, international peering, and destination-region network. A shorter route does not necessarily mean a shorter physical distance or sufficient peering capacity. Direct connections can suffer when inter-network links are congested; when routing from the local network to the entry is good, they can also work well for everyday use.

Entry points in the same region may use different routes. A route that works well on home broadband may need to be reassessed on an office network because the starting point, access policies, and upstream network have changed. Route notes should include the local network used, not just the city. Location helps explain distance, but it cannot replace observing the actual network relationships or serve as the sole basis for ranking route quality.

A relay adds a leg, but can improve a critical segment

A relay accepts the connection at an additional entry point, then forwards data to a later exit. This adds processing and another route segment, but overall performance can still improve if the client-to-relay and relay-to-exit connections are better. Conversely, a busy relay entry, limited forwarding resources, or congestion on the next segment can create a new bottleneck. To judge whether a relay helps, look at which part of the route it changes, not just how many labels it passes through.

Relays also affect troubleshooting. A successful connection from the client to the entry does not prove that the link beyond the entry is working. If multiple exits share an entry, a problem may affect them all; if only one exit is affected, the issue may be on the route after the relay or at the exit itself. Keeping alternatives with different entries and exits can be more useful for diagnosis than saving several similarly named routes. Check route details to confirm whether they actually share an entry.

Understand dedicated routes as part of the full end-to-end path

An IEPL dedicated line describes a specific network transport arrangement. It does not mean that every segment from your device to every website is exclusive. The connection from you to the entry still uses local access, and the route from the exit to the destination service still has its own segments. Local wireless interference, device load, and destination response are not automatically eliminated by a dedicated-line label. Consider the actual entry, transport, and exit structure to understand what a dedicated line may improve; do not treat it as a promise of fixed performance at all times.

Latency includes propagation, forwarding, and queueing. A dedicated line may reduce uncertainty from inter-network links, but it cannot eliminate physical distance. When accessing an account service in a distant region, an exit that meets the service’s rules may matter more than the lowest latency. Real-time interactive apps, meanwhile, need both a reasonable route length and low variation. No route type is best for every destination on every access network.

When checking route information, first choose a region that fits the destination service, then see which route types are actually available there, and finally test them on the access networks you use most. Do not treat a city, protocol, and transport type in a route name as the same attribute: the city indicates location, the protocol describes communication, and topology describes how the path is organized. Each affects a different part of the connection.

An alternative route should address a specific problem. If you often see congestion during local peak hours, compare different transport types and entry points. If the problem occurs only with a destination service, compare exits in suitable regions. If your device does not support a protocol, try a compatible entry first. This gives you a smaller, easier-to-maintain set of options and a clear order for troubleshooting, rather than aimlessly rotating through every region.

Packet loss and congestion: identify the bottleneck

Packet loss can occur locally or farther along the route

Packet loss does not necessarily occur on an international segment. Local wireless interference, access device load, carrier congestion, relay queues, and the exit route can all contribute. First compare regular network access and proxy access on the same device to help distinguish local from remote issues. If both are affected, check the local network and background tasks first. If only a specific route is affected, narrow it down to that route’s entry, transport, and exit.

Packet loss triggers recovery behavior. Reliable streams may retransmit data and adjust their sending rate, while real-time apps may have audio gaps or frozen video. The average transfer speed can look normal even when brief bursts of packet loss disrupt the experience. So smooth performance is not just about how quickly a download finishes. Look for clustered delays, interrupted tasks, or apps that repeatedly reconnect. Different tasks have different tolerances for the same network fluctuation.

During peak hours, check for queueing and shared capacity

A common peak-hour problem is increased demand on a shared link, which makes data wait in queues. When queues get long, downloads may still progress while web responses and interactive apps slow down noticeably. Starting more speed tests adds competition and can obscure the original problem. Stop large file syncs and background downloads first, then check whether lightweight requests improve. This can help show whether the bottleneck is local upstream capacity or competition on the same access network.

If the issue continues after stopping background tasks, compare different entry points or route types at a similar time of day. Changing only the exit city may not help if the same constrained entry is still in use. Changing the protocol, region, and local network at once makes it impossible to tell which factor mattered. Control the variables and keep a regular website as a reference. Recurring trends are more useful than one unusually smooth session, though they still apply only to the network conditions observed.

Diagnostic tools have limits too

A probe request timing out does not necessarily mean that real application data is being lost in the same way. Some devices give probe packets lower priority, and intermediate nodes may not reply at all. Do not assume a fault just because one hop does not respond. Check whether traffic reaches later hops and review actual connection logs. A route probe may also show only one direction; return routing and application protocols may be handled differently.

For slow page loads, distinguish DNS delays from connection setup and content download delays. For fluctuating downloads, check local network usage, whether the connection is being re-established, and whether the destination server is rate-limiting. Speed-test sites also vary in load and regional availability. If one download source slows down while other tasks work normally, try another legitimate source for comparison before judging the route. This helps avoid blaming a proxy protocol for limits imposed by the destination server.

When to stop: If a change causes regular apps to misbehave, restore the original setting and note what changed. Troubleshooting is about finding the bottleneck, not changing every advanced option.

App timeouts can be easy to mistake for network problems. The network may only have a brief interruption, while the app’s conservative retry behavior leaves it stuck on a loading screen. First check whether a new, lightweight request works, then decide whether to restart the app. If restarting the entire client is the only way to recover, investigate whether the underlying connection went idle, the DNS cache is stale, or an operating-system background policy stopped the tunnel process.

When reporting an issue, describe when it occurred, the local network type, route name, destination service, failure stage, and comparisons you have already tried. Do not include account passwords or your full subscription. For tools and record-keeping tips, see How to Test Your VPN Speed. A precise description of what happened is more useful than saying “the protocol doesn’t work,” which does not distinguish DNS, handshakes, queueing, and destination responses.

Mobile devices and resources: battery use is not determined by protocol name

Wireless activity, encryption, and background tasks all use battery

Mobile battery use comes from several sources: keeping the wireless radio active, processing encryption and forwarding, maintaining connections, resolving domains, and syncing app data. The proxy protocol is only one factor. Continuous video, cloud photo uploads, and frequent notifications create a different workload from occasional web browsing. Even with the same entry, these tasks are not directly comparable. Match the task and network conditions before comparing the device load of different protocols.

With a weak wireless signal, the device may work harder to maintain data transfer. Frequent network changes can also trigger connection recovery and app retries. This extra battery use is sometimes blamed on a particular protocol. Before comparing, note whether you are on Wi-Fi or a mobile network, whether the screen stays on, and whether apps are running in the background. The operating system’s battery screen can offer clues, but traffic attributed to the client may actually come from other apps using the tunnel.

Frequent and infrequent connection maintenance both have costs

Keeping a connection alive requires balancing responsiveness against system resources. Very frequent keepalives can wake the wireless radio more often; very infrequent ones may let intermediate devices discard idle mappings, forcing the next request to reconnect. The right approach depends on the access network, client implementation, and system scheduling. Do not copy a fixed interval from a screenshot of another device. Use the client’s recommended settings first, and look into the available options only if you see clear drops after idle periods.

Background operation is also subject to system limits. If the connection drops when the device locks and returns after unlocking, the cause may be a battery-saving policy or the lifecycle of a network extension—not necessarily the route. Check that the client has the network permissions it needs and is not restricted from background activity, and see whether another app is also taking over network traffic. Grant only the permissions required for connectivity. Do not disable all system protections or install software from unknown sources just to troubleshoot.

Compare resource use by checking processor, memory, and temperature

Processor load can vary with the encryption algorithm, concurrent connections, datagram encapsulation, and rule matching. A device may also throttle performance as it heats up, making the same task slower later on. Memory use depends on connection count, caches, and rule size, so a reading taken just after launch is not conclusive. For comparisons, let the device return to a similar temperature and make sure no background sync or large task is running.

On desktop, the traffic interception mode matters too. A system proxy usually affects only apps that follow system settings, while a virtual network interface can handle a wider range of routing and DNS traffic. If a browser works but other programs do not, check whether those programs use the relevant proxy settings before switching regions. For macOS installation and permission steps, see the Mac VPN Setup and Subscription Import Guide.

To assess battery use, choose the same task, keep screen brightness, network, and background apps similar, and check system records along with any connection drops. Do not treat a brief change in the battery indicator as a precise experiment, and do not promise that a particular protocol will save a specific amount of power. A more practical goal is a reasonable balance between task completion, device temperature, and connection reliability—not a theoretical minimum divorced from how you use the device.

SpaVPN supports Windows / macOS / iOS / Android / Linux, with unlimited devices. Each device can use compatible entries, but plan traffic must be shared across them. Background tasks running on multiple devices can also compete for capacity on your home network. The device limit and your local Wi-Fi capacity are separate issues: unlimited devices does not remove router load or bandwidth competition between devices.

Choosing for your use case: define the task, then choose a combination

Web and office work: prioritize connection setup and continuity

Web browsing, document collaboration, and remote work often involve many small requests. Initial response time, DNS resolution, and connection reuse may matter more than sustained download speed. Start with an entry fully supported by your client and an exit region that meets the destination’s requirements, then check that pages load, forms submit, and documents save reliably. If existing connections work but new pages occasionally stall, investigate DNS and new connection setup before chasing higher download speeds.

In office settings, account session stability also matters. Frequently switching exits between regions may trigger extra verification from a destination service or interrupt work in progress. Keep a consistent exit for routine use, with an alternative for troubleshooting and recovery rather than picking a new one every time you open an app. Follow any organizational access requirements. A proxy protocol cannot replace account permissions or proper authorization.

AI Tools and streaming: region and account rules come before protocol choice

Whether an AI tool works depends on network connectivity as well as its supported regions, account status, and product policies. Reaching the server does not mean the account can use every feature. If you see a region notice, check the service rules and exit region first. If only streaming responses are interrupted, then investigate long-lived connections, idle timeouts, and network switching. For more on specific use cases, see our AI Tools access guide.

Streaming depends more on sustained delivery and buffering. Slow playback startup may be caused by DNS, account access, or content licensing; repeated pauses during playback call for checks on throughput, packet loss, and competing tasks on the same network. Available content depends on each platform’s regional rules. A protocol name alone cannot guarantee that content will be accessible. For details on how region and playback settings work together, see our streaming guide, and follow the platform’s own instructions.

Interactive tasks and large files need different metrics

Real-time calls and remote control are sensitive to fluctuation and interruptions, but may not need high sustained throughput. Check whether controls respond consistently, audio stays clear, and the connection recovers after a network switch. If an app needs datagrams, confirm that the client and entry support them. Large file transfers depend more on sustained delivery, resume support, and traffic limits. A quick initial connection does not guarantee a stable long download.

You can keep different options for different tasks, but avoid making the rules too complex to explain. Start with a clear default route and add split-routing rules only when an app has a specific need. Each rule should answer which requests it affects and why they use that exit. If an app misbehaves, simplify the rules and compare again. This is easier than adding exceptions on top of exceptions, and helps identify conflicts between rule matching, DNS routing, and exit selection.

Protocol choice should not replace plan selection. Monthly plans reset their traffic each month on the activation date, while data packs remain available until used and never expire. Consider whether your needs are ongoing, then check actual prices and traffic rules on the plans page. Unlimited devices means you can use the service on multiple devices; it does not mean traffic is unlimited or that simultaneous tasks cannot fill your local connection.

The best combination is one you can explain, verify, and restore easily. If a compatible stream-based protocol already handles your work, there is no need to switch just because a new name appears. If a QUIC entry works better on your local network, keep another usable route as a fallback. Treat protocols as tools, not rankings. This avoids repeated trial and error over names and keeps the focus on whether your actual tasks get done.

Testing and record-keeping: make your choices verifiable

Establish a baseline and keep a way back

Before making comparisons, save the working entry and original settings, confirm that regular network access works, and choose a common app to monitor. Do not update the client, change protocols, and switch access networks all at once. If several things change together, even an improvement is hard to explain. A baseline is not proof that one protocol is better; it gives you a state you can return to and prevents troubleshooting from making things worse.

When you start testing, record the local network, device platform, route name, protocol, and observed task behavior. Check the initial connection, then continued access, and finally recovery after locking the screen or switching networks. Each observation answers a different question, so avoid recording only a vague “works fine.” If you use a speed-test tool, note the test destination and background activity so the result has context. Numbers gathered under incomparable conditions are not useful for ranking protocols.

When something fails, narrow it down by the stage of the error

If an import fails, check whether the client supports the subscription entry instead of immediately editing the server address. For authentication failures, check for subscription updates, system time, and a complete entry. For certificate warnings, review security settings and the network environment. If the connection succeeds but an app fails, check traffic interception mode, DNS routing, and the destination service’s rules. Troubleshooting in the order events occur helps avoid mistaking a later app issue for an earlier handshake problem.

If only one access network fails, keep the same device and task and try another trusted network for comparison. If only one protocol fails on the same network, compare it with a compatible entry in the same region. If multiple protocols fail only through one exit, investigate the exit and destination service first. The goal is not to test every possible combination, but to rule out one category of cause with as few changes as possible. Decide whether another step is needed after each result.

Record format: Local network and device → route and protocol → specific task → stage of failure → single-variable comparisons completed → recovery method. Remove credentials, subscription links, and personal content before sharing.

Keep subscriptions and logs separate

Subscription links usually contain access credentials and should be protected like account passwords. Before sharing a screenshot, public post, or log, check for full links, identity fields, and personal browsing content. Anonymous, no-logs is a SpaVPN service commitment; it does not mean local diagnostic records on your device cannot contain sensitive information, or that other websites will not record account activity. Understand service policies, client logs, and destination-platform records separately.

Get the client and subscription through the user panel; retrieve your subscription after signing in. No email address is required—create an account with a username and password. Do not import your subscription into an unfamiliar website to check whether a protocol is correct, and never share full credentials with unknown tools. For tips on account security and using public networks, read our VPN Security Guide for Beginners.

Turn your observations into a long-term setup

After comparing options, choose a regular entry, a backup, and the situations each is suited for, then remove temporary rules you no longer need. Recheck your conclusions if your local network, destination service, or client implementation changes. A successful session only shows that the task worked under those conditions; it does not guarantee the same route in the future. A short record is easier to maintain than a long list of routes with no clear purpose.

Check plan rules as part of your setup. Monthly plans include ¥9.9/month for 60GB, ¥18/month for 250GB, and ¥28/month for 500GB. Traffic resets monthly on the activation date; if you upgrade mid-cycle, the price difference is prorated based on the remaining days. Data packs cost ¥158/300GB, ¥358/1000GB, and ¥658/3000GB. They remain available until used and never expire. Payment methods: Alipay / WeChat Pay / USDT. A 60-day money-back guarantee is available; see the refund policy for details.

If you still cannot identify the issue, check common symptoms in the Help Center, then send the information you have gathered through the support ticket portal. A description of the task, failure stage, and alternatives already tested is usually more helpful than a collection of speed-test screenshots. The goal is not to find an abstractly “best” protocol, but a connection setup that works on your current device and network, is easy to explain, and can be restored when something goes wrong.