Protocol and RoutesTechnical Reference

Separate the layers first, then compare protocol performance

Connection quality is not determined by the protocol alone

When discussing network acceleration, the most common mistake is attributing every difference in performance to the protocol name. In practice, a request travels through the local device, access network, client processing, entry route, cross-region path, exit route, and the destination service itself. The protocol controls only part of this chain: how the client and server establish a session, encapsulate data, and handle loss or congestion. If the entry point is unreachable, the access network keeps fluctuating, or the destination is limiting connections, simply changing protocols rarely delivers a stable improvement.

A more reliable approach is to divide the problem into the device, session, route, and destination layers. The device layer covers system permissions, background operation, battery policies, and client health. The session layer covers handshake completion, repeated reconnections, and whether the transport suits the current network. The route layer covers entry distance, cross-region paths, congestion, and packet loss. The destination layer covers whether a website, streaming service, or AI tool serves the current exit region. Identify the affected layer first; otherwise, adjustments become directionless trial and error.

Speed, latency, and stability are different metrics

Speed usually describes sustained throughput, latency is the wait for a request to make a round trip, and stability is whether that performance holds over continued use. Large downloads depend more on throughput; web browsing and remote work care more about request round trips; video calls and real-time voice are sensitive to both latency variation and packet loss. A route may transfer a large amount of data briefly yet feel sluggish because queueing changes, while another with a lower peak rate may suit work and calls better because its path is consistent and jitter is low.

So “fastest protocol” is not a conclusion that holds outside a specific use case. The transport method, system network stack, client implementation, and route quality all affect the result. The same protocol can perform very differently on different entry points, and the same entry point can behave differently on wired, public Wi-Fi, and mobile data. Keep the device, destination, and entry route fixed while changing one variable at a time. Changing the protocol, region, and client settings together may restore a connection temporarily, but it will not show which change helped.

Use a reproducible testing sequence

A useful diagnosis should leave a short record: the device and network environment, entry region, protocol, destination service, whether the issue occurred before or after connection, and whether the symptom changed after switching one item. No complex monitoring tools are needed; keep the conditions consistent. For example, if a page will not open, first confirm that the client reports an established session, then visit a stable public site. If the public site works but a specific service does not, the issue is more likely at the destination layer than in the protocol.

LeeVPN covers 90+ countries and 200+ routes, giving you plenty of entry options—but more choice makes a clear method even more important. Start with an entry point geographically close to your access location and with a shorter path, then choose an exit region based on the destination service. For regional and route-type comparisons, visit the Nodes and Routes page. If you are comparing monthly plans and data packages, review the Plan Rules first so data-cycle issues are not mistaken for client failures.

Layered diagnosis also reduces wasted effort. Clearing every configuration, reinstalling the client repeatedly, or cycling through many routes destroys useful clues. A better process starts with the least disruptive checks: verify the account and subscription, confirm entry reachability, observe the destination service, and only then change the protocol or system network settings. If each step answers “did the symptom change?”, troubleshooting becomes a reproducible process instead of guesswork.

Trade-offs of common protocols

Shadowsocks: simple structure, dependent on implementation quality

Shadowsocks follows a straightforward model: the client encrypts and encapsulates traffic, then sends it to a remote server for forwarding. Its ecosystem is mature, with relatively few configuration concepts, making it easy to understand on desktop and mobile devices. Because the processing chain is uncomplicated, it generally adapts well to devices with limited resources or situations where a lighter client workload is preferred. It is commonly used for everyday browsing, file transfers, and routine application connections without the management overhead of many optional fields.

Its limits are that real-world performance depends heavily on the client and server implementations, encryption method, underlying transport, and route quality. The same protocol name does not mean two routes have the same capability. A client with weak system network-extension support or poor background recovery may still require reconnection after sleep. Treat it as a simple, general-purpose session design—not as proof that simplicity is always faster on every network.

VMess: richer session data, more processing steps

VMess carries a relatively complete set of authentication and transport information in each session and can work with different underlying transports. Its strength is an ecosystem with many mature configuration combinations, making it useful where compatibility and multiple transport paths both matter. Because it has more parameters, keep the server-provided values when importing a subscription; do not manually rewrite fields whose purpose you do not understand. Some seemingly unrelated transport options determine how the client establishes a connection, and changing them can cause the handshake to fail outright.

Compared with a more compact design, VMess usually requires the client to complete more session-processing steps. Modern desktop devices rarely amplify this difference into an obvious usability issue, but during frequent reconnects, background restrictions, or high device load, the extra work may show up as slower recovery. Judge its suitability not only by whether one connection succeeds, but also by how reliably it recovers after network changes, device wake-up, and long periods in the background.

Trojan: compatibility through standard encrypted sessions

Trojan typically establishes connections through a standard encrypted session, keeping authentication and data transfer inside a mature encrypted channel. It suits networks that work well with standard encrypted connections and users who want a clear client configuration. The handshake requires the relevant encryption negotiation, so system time, certificate validation, DNS resolution, and server configuration all affect the result. If the connection breaks immediately, check these fundamentals before blaming insufficient route bandwidth.

Standard encrypted channels offer broad compatibility, but they also make handshake and certificate issues more visible. An incorrect device clock, a bad DNS result, or incomplete session handling by an intermediate network can prevent a connection from forming. Trojan is best suited to users with sound basic network quality who want a stable, broadly compatible transport. If the access network has severe packet loss, improve the route first; a protocol name cannot remove the cost of repeated retransmissions.

VLESS: lightweight authentication, capabilities defined by the combination

VLESS keeps authentication lightweight, while most transport capabilities come from the outer combination. It cannot be evaluated separately from its transport, encrypted channel, and client implementation. This design makes scenario-based combinations possible, but it also requires both ends to match. If the server uses a particular transport, the client must initiate the session the same way. Copying only the address while omitting the remaining fields usually does not produce a usable connection.

From a selection perspective, VLESS suits setups that prefer a lightweight session structure while letting service configuration manage the transport combination. Most users do not need to understand every subscription field; keeping the automatically delivered subscription is usually enough. Advanced users should compare “VLESS plus a specific transport” as a complete solution rather than judging speed from the VLESS name alone. Different outer combinations change the handshake path, resource use, and failure patterns.

Hysteria2 and TUIC: transport strategies for unstable paths

Hysteria2 and TUIC both place greater emphasis on keeping transfers continuous across fluctuating networks, packet loss, and mobile handoffs. They generally use modern datagram transport capabilities and take approaches different from traditional reliable byte streams for congestion control, multiple data flows, and connection migration. When packet loss is occasional, they may restore useful transmission faster than designs dependent on a continuous byte stream, especially on mobile networks, cross-region paths, and interactive workloads.

This advantage does not apply to every network. Some access networks handle datagram traffic conservatively, and public Wi-Fi may use short state timeouts for long-lived datagram sessions. The result can be a failed handshake, a connection that quickly expires, or unreliable background recovery. Hysteria2 and TUIC also depend on the client network stack and system scheduling; an immature implementation can offset their theoretical transport benefits.

Use the protocol table to narrow the options, not to create a fixed ranking. Real selection should account for the device, access network, route topology, and destination service. If a protocol is stable in the current environment, recovers after network changes, and works normally for the target app, there is no need to migrate simply because another protocol is newer. Mature selection prioritizes repeatability and maintainability over chasing changing names.

Connection setup and resource use

From tapping Connect to a usable app

Before a client shows “Connected,” it usually confirms system network permissions, resolves the domain, checks entry reachability, establishes a transport session, authenticates the protocol, and takes over local routing. Protocols arrange authentication, encryption, and data channels at different stages, so they fail in different places. If the client remains on “Connecting,” the entry point may not be responding. A quick authentication error means the server was reached but the account or subscription was not accepted. If it shows connected but the destination remains unreachable, check local routing, DNS, and exit conditions.

Connection setup speed should not be judged by subjective waiting after one tap. The system may reuse DNS cache or retain a previous session, and a freshly launched client follows a different path from one resumed in the background. More useful checks cover everyday states: first launch, recovery after sleep, Wi-Fi changes that require manual reconnection, and switching between mobile data and Wi-Fi. A solution that recovers reliably in these states is usually better for long-term use than one that connects faster in a single test.

Reliable byte streams versus datagrams

Reliable byte-stream transports preserve order and schedule retransmission when data is missing. This matters for file integrity and most web requests, but packet loss underneath can make later data wait for an earlier gap to be filled. Occasional jitter may cause only a brief pause; persistent loss on a cross-region path can repeat the delay, appearing as stalled page loads or a sudden drop in video buffering.

Modern datagram transport lets the upper layer organize multiple data streams more flexibly and choose recovery behavior based on congestion. Loss in one stream does not necessarily block the others, which can help with real-time interaction and parallel requests. It still cannot repair a bad route by itself: lost data must be resent, and the congestion window must adapt to available capacity. If the access network handles datagrams poorly, establishing the session may be the problem. Distinguish “more flexible recovery” from “faster on every network.”

CPU, memory, and the system network stack

Protocol resource use comes from encryption, data copying, buffer management, rule matching, and logging. Desktop devices usually have more processing headroom, so differences show up mainly during high-throughput transfers or many concurrent connections. Mobile devices also involve background scheduling and thermal controls. Complex split-routing rules, verbose long-term logs, and multiple network extensions may consume more resources than the protocol itself. When investigating resource issues, check whether the client loaded an oversized rule set, whether duplicate local proxies are active, and whether another app is also taking over the network.

Memory use is usually tied to connection counts, buffers, and rule data. Many browser tabs, cloud sync, system updates, and media apps create connections at the same time, requiring the client to maintain more sessions. If the device becomes hot or the system reclaims the app, close unnecessary background transfers, reduce diagnostic logging, and observe whether the symptom changes. Switching protocols may seem to help simply because it restarted the session and released old connections; the problem can still return.

How to think about encryption overhead

Encryption requires computation, but on modern devices the experience is often shaped less by whether traffic is encrypted than by whether the implementation uses system capabilities, whether data is copied repeatedly, and whether the route causes retransmissions. A healthy transfer performs the necessary work once; a lossy route sends the same content repeatedly, consuming more CPU, network capacity, and battery. The first way to reduce resource use is usually to choose a stable route, not to weaken connection protection.

Client implementations also differ. Some call the system network framework directly, while others include a user-space network stack. The former often integrates more closely with system permissions and power saving; the latter may offer more consistent cross-platform behavior. Neither approach is universally better outside its environment. Windows, macOS, iOS, Android, and Linux handle network extensions, background services, and routing differently, so the same protocol will naturally have different resource profiles across platforms.

To compare resource use, keep the same entry point and target app while observing startup, sustained use, sleep, and network switching. Do not run multiple clients that take over the system network, and do not repeatedly refresh large downloads during the comparison. The goal is not an artificial peak figure, but confirmation that the protocol can establish, transfer, and recover reliably on your device.

Mobile battery use and background recovery

Battery drain usually comes from wake-ups and reconnects

On mobile devices, network-tool battery use comes not only from encryption but also from frequent wake-ups, session rebuilds, repeated transfers under weak signal, and continuous background connectivity. After the screen turns off, the system reduces app activity. If a session must keep sending keep-alive messages or the access network frequently changes its address, the system may repeatedly wake the network extension. One wake-up may be negligible, but repeated wake-ups prevent the device from entering a low-power state.

Reconnect frequency depends on protocol state management and directly on Wi-Fi quality. When the signal alternates between usable and unusable, the client may repeatedly check whether the old session is alive and attempt a new one. A protocol with more flexible recovery may improve the experience, but if the root cause is unstable access signal, every protocol still pays the cost of retransmission and rebuilding the connection. Check system signal strength, background sync tasks, and client connection logs together rather than looking only at the protocol name.

Background behavior on iOS and Android

iOS typically manages tunnels through a system network extension. Once the app interface enters the background, the extension process operates under system constraints. The system controls available memory, runtime opportunities, and network switching, so correct implementation of on-demand connection and state recovery is important. If the interface is cleared while the connection remains, that does not necessarily indicate a client failure. Conversely, an interface showing an old status does not prove the underlying session is still active; rely on actual network access.

Android background policies vary by device customization. Battery-saving modes may limit client activity, and the system may terminate related processes under memory pressure. Allow the client in use to run in the background as needed, and avoid having multiple VPN-style apps compete for the system interface. If the connection breaks after every screen lock, check battery management and background permissions first. If it breaks only when switching from Wi-Fi to mobile data, check whether the protocol supports session migration or rapid rebuilding.

Address changes during mobile handoffs

When switching from Wi-Fi to mobile data, the local address, exit address, and available path all change. Traditional sessions are often tied to the original path and must be rebuilt after a change. Modern transports that support connection migration can try to preserve session context, but the new network must still allow the same traffic type. Successful migration avoids resending every application request; if migration fails, the client should quickly perform a full reconnect rather than hold an invalid old state.

Video playback is relatively tolerant of brief handoffs because the player usually has a buffer. Voice, remote desktops, and real-time messages expose handoff issues more readily. For mobile real-time interaction, test Hysteria2 or TUIC first and confirm that the access network handles datagrams normally. For web browsing mainly on fixed Wi-Fi, mature implementations of Shadowsocks, Trojan, VMess, or VLESS may be easier to maintain. Choose based on the mobile pattern, not on the assumption that a newer protocol suits every device.

Practical ways to reduce background load

First, disable unnecessary verbose logging and continuous diagnostics in the client, then check whether application split routing is overly complex. The more rules there are, the more conditions must be matched for each new connection; rule updates also increase network and storage activity. If stable connectivity is the priority, the service-provided default configuration is usually easier to maintain. If split routing is needed, start with a small number of clearly defined apps and add gradually rather than importing a large, outdated rule set from an unknown source.

Next, avoid making multiple apps perform the same job. When a system-level connection already controls traffic, a browser proxy, a separate development-tool proxy, and an app’s built-in accelerator can create multiple forwarding layers. More layers are not necessarily more stable; they add DNS, handshake, and troubleshooting complexity. If a mobile device runs hot, temporarily disable extra network tools, keep one client and one ordinary target app active, and observe standby and recovery behavior.

LeeVPN supports Windows, macOS, iOS, Android, and Linux, with client access centralized in the user panel. Platforms share the same account and subscription rules, but their background behavior will not be identical. To isolate a mobile issue, first test the same entry point on another device or desktop system. If other platforms work, focus on mobile permissions and background management. If every platform shows a similar issue on the same entry point, investigate the route and service status.

How direct, relay, and dedicated routes change the experience

Topology describes the path, not the protocol

The protocol defines how data is encapsulated and transmitted; route topology describes which networks and nodes carry it. They are often conflated, but they solve different problems. The same protocol can run over direct, relay, or dedicated routes, and one topology can offer multiple protocol entry points. Protocols affect handshakes, congestion recovery, and client compatibility; topology affects routing, carrier interconnection, cross-region exits, and the scope of failures. When speed fluctuates, first determine whether the protocol session is unstable or the path itself has changed.

A route name cannot fully represent every physical segment. The path from the user to the entry, entry to exit, and exit to destination may use different networks. Direct usually means the entry reaches a server in the target region without an additional service relay. Relay means traffic first reaches a nearby or better-connected node and then travels to the exit. Dedicated routes emphasize more controlled transport across key intermediate segments. The final experience still depends on local access and the destination service.

Direct: a simple path that depends on public interconnection

Direct routes have a simple structure: one less service relay means fewer queueing, processing, and failure points. When public interconnection is healthy and the entry point is suitably close, direct routing can provide natural latency and efficient throughput. It suits users with stable network conditions and good routing to the target region, and it provides a useful troubleshooting baseline. If neither direct nor relay can connect, the issue may be the device, account, or access network; if only direct fluctuates, inspect the public path.

Direct routes are more sensitive to carrier interconnection and cross-region routing. Public routes may change with network policy and congestion, and different access networks in the same region may take different paths to the entry. A direct route that performs well for one user may not do so on another access network. Direct does not mean low quality or permanently lowest latency; it simply removes a service relay while the remaining path is still shared by multiple networks.

Relay: a controlled entry in exchange for an extra hop

Relay routes usually send traffic first to a relay node with better access quality, then onward to the target region. This adds a processing step but may avoid poor public interconnection. The value of a relay is not necessarily a shorter path; it lets the entry segment and cross-region segment be selected separately. If direct access to a remote region fluctuates while the local path to a relay is stable, a relay may provide a smoother connection.

A relay also introduces new capacity constraints. Traffic through the same relay shares its compute, interfaces, and upstream path, so congestion can occur between the user and relay, inside the relay, or between the relay and exit. Compare different route types in the same region: if several exits fluctuate through one relay entry, the relay segment may be the issue; if only one exit is affected, the problem is more likely in the latter segment or near the destination.

Dedicated: controlled paths and a steadier boundary

Dedicated routes typically place key cross-region segments on more controlled network capacity, reducing uncertainty from public-route changes. Their main value is path consistency and clearer congestion management, not a guarantee of the highest peak in every test. For remote work, long meetings, sustained transfers, and jitter-sensitive apps, a stable path often matters more than short bursts of speed. A dedicated route still relies on public local access to the entry and remains subject to the device and destination service.

Dedicated capacity usually requires planning. When demand concentrates in one direction, queues can still form at the entry, exit, or destination even if the middle path is controlled. Evaluate a dedicated route for sustained stability during actual usage periods rather than testing it once while idle. If the connection is stable but a particular app remains slow, check the destination region, exit choice, and app itself instead of assuming the dedicated route changes every external condition.

Consider entry distance and exit region separately

The entry determines where the user connects first; the exit determines where the destination sees the traffic coming from. To reduce initial delay, choose an entry close to the current access location with good interconnection, then select an exit that fits the content region or service deployment. Choosing a distant entry solely because of the target region can make the entire path vulnerable to cross-region fluctuation. One benefit of relay and dedicated routes is separating “easy to reach” from “where the traffic needs to arrive.”

On LeeVPN’s Nodes page, narrow the list by region, city, and route type. Do not cycle through all 200+ routes in a short period. Choose the target region first, then compare nearby entries and different topologies. More routes require more disciplined filtering. Keeping one stable primary route and a topology-diverse backup is usually more consistent than choosing randomly each time.

The final rule for topology selection is to take responsibility for the actual path. Direct routes are a simple baseline, relays can improve cross-network and cross-region access, and dedicated routes suit tasks sensitive to jitter and path changes. No type is a permanent winner regardless of time, location, and destination. Record sustained performance in the same scenario to determine whether an extra relay is worthwhile or whether the dedicated path actually solves the current problem.

Packet loss and jitter during peak-hour congestion

Packet loss does not occur only at the far end

Packets can be lost on Wi-Fi access, local routing equipment, carrier networks, entry interfaces, relay paths, exit networks, or near the destination service. Loss caused by wireless interference usually comes with signal fluctuation and changes noticeably outside the current Wi-Fi environment. When a local queue is full, an upload can make other requests wait. Loss on a cross-region path is more likely to affect multiple devices and apps at once. First determine the scope of the impact rather than switching remote regions at the first sign of stuttering.

Reliable transport retransmits lost content, so users may not see an obvious error. More common symptoms are sawtooth speeds, occasional page stalls, broken-up voice, or a connection that slows after extended use. Datagram transport can use more flexible recovery strategies, but it also needs to resend critical content. A protocol can determine how packet loss is handled, not make the loss cost-free. With persistent loss, improving the path is usually more effective than adding concurrency.

Jitter affects real-time apps more than average latency

Jitter is the variation in wait time across consecutive requests. Even when average latency looks acceptable, sudden slow requests can interrupt voice and remote operation. Apps often use buffering to absorb variation, but larger buffers reduce real-time responsiveness while smaller buffers expose more network fluctuation. On-demand video can preload content and tolerate brief jitter; live meetings and cloud interaction have less time to wait.

A common cause of jitter is a constantly changing queue length. Requests pass quickly when the network is idle, but later requests wait when traffic arrives in volume. If a router or route uses oversized buffers, data may not be lost immediately but can sit in the queue for a long time, creating the feeling that speed continues while interaction becomes sluggish. Continued downloads alone do not prove a route suits real-time use; also observe voice, interaction, and small-request response times.

Where peak-hour congestion happens

Peak-hour congestion is not a fixed failure at one node; it is a period when multiple shared resources come under load. Home access, carrier interconnection, entry nodes, relay capacity, exit routes, and popular destination services may all queue. If multiple destinations slow down on the same access network, local access or carrier interconnection is more suspect. If only one regional route fluctuates, focus on that direction’s relay or exit. If other sites work while one popular service is slow, consider the destination’s own capacity.

Congestion also changes protocol behavior. Reliable byte streams reduce their sending rate as loss and queueing increase, and recovery takes time. Modern datagram protocols may use different congestion-control strategies and probe available capacity more aggressively. That can restore performance faster in some cases but may create more fluctuation on shared networks. No strategy can bypass a real capacity limit; they differ in how they discover capacity, back off, and recover.

Why local uploads can slow downloads

On a home or Wi-Fi network, cloud sync, photo backup, or file uploads can fill the upstream queue, forcing the acknowledgements needed by download requests to wait. The result looks like a remote download route slowing down, while the root cause is local upload saturation. Video calls are especially sensitive because they need stable upload and download at the same time. Pause large sync and backup tasks, then check whether interaction recovers. If it does, address the local queue and background tasks rather than changing protocols again.

The same issue can come from other devices on the local network. LeeVPN supports unlimited simultaneous devices, but “unlimited” describes the account’s concurrent-device rule, not an increase in local access bandwidth. Multiple devices updating, backing up, or streaming high-bitrate content still share the available network capacity. Before judging a route, check whether another device is continuously consuming upload or download bandwidth.

Distinguishing brief fluctuation from a persistent failure

Brief fluctuations usually recover on their own and affect part of a transfer or a single network handoff. Persistent failures recur when conditions remain unchanged. Record whether a connection can be established, ordinary pages work, real-time apps are affected, and the symptom changes after switching topology. This is more useful than a single speed result. If reconnecting helps briefly before the slowdown returns, queueing or path congestion may be involved. If the handshake never succeeds, return to entry reachability and session configuration.

Do not mistake a destination service’s content-delivery behavior for route packet loss. Streaming services adjust quality based on buffering and exit region; AI tools may wait because of server-side task complexity; file sites may manage traffic per connection. Cross-check with different types of destinations: if public pages, file transfers, and real-time interaction all fail, a route issue is more likely. If only one service fails, check its status and regional support first.

With persistent congestion, shorten the path, change the entry, or choose a more controlled topology instead of continually increasing concurrent requests. Concurrency can improve utilization on an idle route but intensify competition on one already queueing. The goal of a stable connection is sufficient sustained capacity for the app, not a completely full queue during a short test.

Combine protocols and routes by use case

Everyday web browsing and general use

Web browsing consists of many short requests, so smooth connection setup and stable DNS and small-response handling both matter. There is no need to pursue the most complex transport combination. Prefer a mature client implementation that recovers reliably on the current device. Shadowsocks, Trojan, VMess, and VLESS can all support everyday connections; differences usually come from the specific transport and route quality. Start with an entry near the current access location, then choose an exit region for the target site.

If pages occasionally stall while file downloads continue, focus on jitter, DNS, and queueing rather than throughput alone. If every client launch takes a long time, compare a design with a simpler handshake path. If the device often switches between networks, observe reconnect behavior. Keeping one primary route and one topology-diverse backup is usually easier than maintaining many random choices.

Remote work, meetings, and cloud collaboration

Remote work prioritizes continuity, low jitter, and stable upstream performance. A dedicated route or a consistently performing relay is worth testing first because it can reduce path changes across critical regions. Choose a protocol that runs reliably over long periods and recovers quickly after network changes. If the access network handles datagrams normally, test Hysteria2 or TUIC for real-time interaction. If the enterprise network works better with standard encrypted connections, Trojan or a mature VLESS combination may establish more easily.

Avoid running large speed tests while working. They consume shared capacity and can degrade meetings and remote desktops. A better validation is to observe the actual work apps: stable login, continuous voice, responsive screen control, and background file sync. If real-time apps fail while ordinary pages work, change the topology or entry first rather than modifying every client setting.

Streaming and long-running transfers

Streaming is more sensitive to exit region, sustained throughput, and steady buffering. Confirm that the target content is available in the selected region, then choose the corresponding exit. The protocol only needs to sustain the transfer; route capacity and exit quality usually matter more than handshake differences. Direct routes are simple when the public path is healthy, while relays or dedicated routes may provide smoother buffering when cross-region paths fluctuate. See the Streaming Access Guide for how destination services and regions relate.

Long file transfers also depend on recovery after a session interruption. Sleep, Wi-Fi handoffs, or the system reclaiming the client can force a transfer to restart. On desktop, prevent deep sleep during a task; on mobile, confirm background permissions. For long jobs, a route that remains steady over continuous use is more practical than one with a higher short-term peak.

AI tools and interactive development

AI tools involve short requests as well as streamed responses, file uploads, and web interactions. Perceived wait time does not come entirely from the network; model processing and server-side queues also take time. Confirm that ordinary pages and account login work before treating one slow response as a route issue. If only generation is slow while interface actions work, changing protocols may not help. If uploads, login, and streamed responses all disconnect frequently, compare more stable route topologies.

The exit region should match the tool’s service coverage and account settings. Switching frequently between distant regions may trigger another login or session check. Keep a regular region and consistent browser and client environment. For more scenarios, see the AI Tools Guide. Prioritize connection continuity and exit consistency rather than one-off page-opening speed.

Mobile use and public Wi-Fi

For mobile use, focus on network handoffs and background recovery. Test Hysteria2 and TUIC first when datagrams work normally, and use Shadowsocks, Trojan, VMess, and VLESS as compatibility comparisons. Public Wi-Fi can differ from home networks in DNS, session persistence, and datagram support, so a protocol that is stable on one network must be re-tested on another. When a connection fails, change the protocol type first and the entry point second instead of changing too many conditions at once.

Public networks may also require web-based authentication first. If the client takes over all traffic before authentication, the sign-in page may not open. Pause the connection, complete the network provider’s normal access process, and establish the session again. If it still fails afterward, check entry reachability and protocol compatibility rather than repeatedly reopening the authentication page.

Account and data rules are also selection criteria

Protocols and routes determine how you connect; plans determine available data and reset rules. LeeVPN monthly plans are ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB. Data resets monthly on the activation date, and mid-cycle upgrades credit the price difference against the remaining days. Data packages are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB; they remain valid until used and never expire. Compare monthly plans for steady usage, or consider a data package for long-term backup.

All plans support unlimited simultaneous devices and include 7-day no-questions-asked refunds. Payment methods are Alipay, WeChat Pay, and USDT. Account creation requires no email address; a username and password are enough to register. These rules are independent of protocol selection: changing protocols does not change plan data, and switching routes does not extend the billing period. See the Plans page for detailed differences.

The goal is not to find the theoretically most advanced protocol, but to define a maintainable combination: regular devices run reliably, key destinations are reachable, the primary entry performs consistently during actual use, and a topology-diverse backup exists. Once those conditions are met, avoid unnecessary changes. Chasing new combinations adds configuration differences and removes a stable baseline when failures occur.

Verify the connection and troubleshoot layer by layer

Check the account, subscription, and system status first

Start with the easiest conditions to verify. Confirm that the account can log in, the plan is active, and the client is using the latest subscription content. After upgrading a plan or changing a subscription, refresh the configuration in the client instead of continuing with an old local copy. Then confirm that the system granted the client the required network permissions and close other apps that take over the system network. Multiple clients can overwrite each other’s routes, producing a connection that appears successful while traffic takes an uncertain path.

If every route fails to establish, inspect the local environment first. If only one entry is affected, investigate that entry or path. If desktop works while mobile fails, check mobile background and network-extension permissions. If every platform fails on one access network but works on another, the original access network is more likely at fault. Narrowing the layer by scope is more efficient than switching through many nodes at random.

Use basic commands to verify the request path

Command-line tools can confirm whether a domain resolves, whether an encrypted web page returns a response, and whether an issue is limited to one browser. The examples below use public test domains and contain no account details, credentials, or real subscription addresses. A successful command only shows that the current request received a response; it does not prove every app and route is healthy. On failure, use the error to determine whether the problem is at DNS, connection, or certificate validation.

curl -I https://example.com
ping example.com

A response header from curl indicates that DNS resolution, connection setup, and a basic encrypted web session completed. If the browser fails while the command works, check browser proxies, extensions, and cache. ping may be ignored by the destination or an intermediate network, so no reply does not necessarily mean a web page is unreachable. Use it as a supporting observation of path changes, not the sole criterion. For a target that ignores probes but serves pages normally, trust the actual application request.

What to check when connected but unable to access

When the client shows connected, it only means the protocol session was established; it does not mean every system app is using that session. Visit an ordinary web page first and determine whether all destinations fail. If everything fails, inspect local routing and DNS. If only one app fails, check whether it uses its own proxy, has cached old network state, or is unsupported in the current exit region. Closing and reopening the target app can make it establish a fresh connection, but do not begin by clearing the entire client configuration.

DNS issues often appear as one domain failing to open while known services or other domains work. Disconnect and reconnect first so the system reapplies the client-provided DNS settings. If a fixed DNS service was configured manually, confirm that it is compatible with the current path. Do not stack multiple encrypted DNS tools with a system-level connection; requests may take different paths, making diagnosis harder.

Slows down after running for a while

A connection that starts normally and then slows is often related to queues, packet loss, background tasks, or session state. Pause downloads, cloud sync, and system updates, then see whether interaction recovers. Next, switch to a route in the same region with a different topology to determine whether one path is responsible. If reconnecting restores speed immediately but the slowdown returns later, check client logs for repeated reconnects, network changes, or session timeouts rather than assuming the brief recovery solved the issue.

If the slowdown occurs only during a regular evening window, compare direct, relay, and dedicated routes using the method above. A clear difference between topologies suggests path capacity; a simultaneous drop across all topologies also warrants checking local access and the destination service. Do not run large speed tests alongside real tasks during congestion, since the test itself consumes capacity and distorts the result.

Follow a fixed order when switching protocols

Protocol switching should not be random. If the current protocol cannot complete a handshake, compare a solution with a different underlying transport. If the handshake works but recovery fails after a network change, test an option better suited to migration or rapid rebuilding. If a fixed network remains stable, there is no need to switch merely because a name has been updated. Keep the entry region and destination unchanged for every test, confirm the symptom, and then continue. This isolates protocol effects from path effects.

If switching from a reliable byte-stream solution to Hysteria2 or TUIC still cannot establish a session, the access network may handle datagrams poorly. If switching back restores the connection, use a general-purpose protocol as the regular option on that network. If every protocol fails on one entry while other entries work, the entry or route is more likely at fault. If every entry and protocol fails, return to the account, permissions, and access-network layers.

When to submit a support ticket

If basic troubleshooting does not identify the cause, submit a ticket through the user panel. Include the device platform, protocol used by the client, entry region, failure stage, destination-service type, environment in which the issue began, and comparisons already performed. Do not submit passwords, subscription URLs, or other sensitive credentials. Notes such as “the same device recovered on another access network” or “the same entry behaved the same after a protocol switch” help support determine whether to inspect the client, entry, or route.

If the issue affects only one app, note whether ordinary web pages work. If it follows a usage schedule, say whether it recovers at other times. If a mobile connection breaks after screen lock, note whether foreground use remains stable. Clear stages and comparison results are more useful than a vague “cannot use it.” The ticket entry is in the User Panel; client downloads and subscription updates should also be completed there.

For more on desktop-platform differences, read Windows VPN Picks and Client Compatibility Compared and macOS Network Extensions and Compatibility Compared. For first-time mobile setup, see the Complete Android VPN Beginner’s Guide. Those articles cover platform-specific situations; this page keeps the shared framework for judging protocols, topology, and troubleshooting.

There is no fixed protocol or route choice that works apart from its environment. Identify the problem layer, then compare one variable at a time using the same device, entry, and destination. Once the protocol establishes and recovers reliably, compare route topologies; finally choose the regular setup based on sustained performance in real apps. This order turns vague connection complaints into technical judgments that can be recorded and reviewed.