Protocols and RoutesTechnical Guide

Decision order

Protocol selectionWhat to check first

A protocol is not a switch that determines speed on its own

Treating a protocol name as synonymous with “fast” or “slow” is one of the most common selection mistakes. A real connection combines the local network, client implementation, service entry point, transport path, egress region and destination service. The protocol controls only part of this: how the connection is established, how data is segmented, how loss is recovered, whether a reliable byte stream is required, and how much work the device must do to keep the session alive. Even two connections using the same protocol can feel completely different for page loads, sustained downloads and real-time communication if their entry distance, inter-network path or egress load differs. When a connection stutters, do not immediately blame the protocol or change several settings at once. Fix the destination region and test application first, then replace variables one by one to identify the source of the change.

Start with the application profile. Web browsing and document sync consist of many short requests, so quick connection setup and fast retries matter most. Long video sessions and large downloads depend more on sustained throughput and congestion control; occasional startup delay may not affect the overall experience. Voice, remote interaction and online collaboration are more sensitive to smooth latency, and even brief bursts of queueing can be noticeable. Mobile devices also introduce network changes and background suspension: moving from Wi-Fi to a cellular network can invalidate an existing session, while power-saving states may delay keepalives. A useful conclusion must consider the protocol together with these conditions.

Define the boundaries before comparing implementations

Shadowsocks, VMess, Trojan, VLESS, Hysteria2 and TUIC are not interchangeable parts of one simple category. Some have lightweight structures suited to resource-constrained devices; others carry richer session information for organizing connections in complex clients; some rely on mature reliable transport and are easy to reason about; others prioritize continuous sending and session migration on lossy paths. The same protocol name also does not guarantee identical client implementations. Cryptographic libraries, buffering, system network interfaces, kernel scheduling and application-layer multiplexing all affect resource use. When you hear that “a protocol always saves battery,” first ask which client, system state, access network and route were used, and whether the comparison kept the same route.

Configuration should follow the principle of making the smallest necessary change. Defaults are usually designed for a broad range of devices and networks. Increasing buffers, raising concurrency or changing congestion control does not necessarily make a connection faster. A buffer that is too small limits throughput, while one that is too large can increase queueing delay; more concurrency may fill a link or make a weak network even more crowded. For most users, a stable client preset followed by route testing is more effective than piling on parameters. Only investigate parameters after confirming that the issue is concentrated on a particular network or application.

Create reproducible comparison records

Useful records do not require complex tools, but they must preserve context. At minimum, note the access method, device platform, client, protocol, entry or egress region, test application and approximate time. Do not record only “fast” or “slow”; describe whether the symptom was first-load delay, prolonged loading, reduced picture quality, choppy audio or failure to recover after a network change. Different symptoms point to different layers: first-load delay may involve resolution, negotiation or the entry path; sustained loading suggests throughput or congestion; failure after switching networks points more toward session migration and system background policy. The more specific the symptom, the fewer variables you need to replace later.

Once you have a baseline, make the lowest-cost changes first: keep the protocol fixed and switch to a route in the same region to test for a single-path issue; keep the route fixed and change the protocol to see whether transport behavior changes; then try a nearby egress region to check for detours between the destination service and the egress. If every combination is abnormal on the same access network but works on another local network, return your attention to the local path. If only one application is affected while browsers and other apps work, check that app’s proxy support, cache, account region and connection reuse rather than changing protocols without a hypothesis.

Classic options

Trade-offs between Shadowsocks and VMess

Shadowsocks: a lightweight structure and clear data path

Shadowsocks is relatively easy to understand: the client sends application traffic to a local proxy, encrypts it, forwards it to the server, and the server connects to the destination. Its structure is simple, with little protocol overhead, so clients are generally straightforward to implement on desktop and mobile platforms. For everyday uses such as web browsing, documents, regular video and developer tools, the lightweight design makes behavior easy to follow and faults easier to attribute to the local proxy, remote entry or destination connection. It does not automatically mean the lowest resource use, because the final cost still depends on the encryption method, client network stack, connection count and system proxy mode.

Shadowsocks’ common limitation comes from the underlying transport. When it uses a reliable byte stream, packet loss triggers retransmission, and data that arrived later may still wait for an earlier gap to be filled. On a stable network this is simple and dependable; on a visibly unstable wireless path, the waiting can appear as web resources arriving in batches, video buffering suddenly stopping or file sync slowing in stages. The issue may not be encryption efficiency but the normal response of the underlying transport to loss. Switching to a higher-quality entry route is often more direct than repeatedly tuning encryption parameters.

Connection reuse is another easily overlooked factor. Browsers and modern applications access many domains in parallel. A client may establish separate remote connections for these requests or reduce handshakes through reuse. Reuse lowers the cost of short connections, but putting too many requests on one underlying connection can broaden the impact of a single lost packet. If the client offers a reuse option, do not assume that enabling it is always faster. When first loads are slow but sustained downloads are normal, compare reuse behavior while keeping the route fixed; when sustained transfers are also unstable, check route quality first.

VMess: a protocol with richer session semantics

VMess has a richer protocol structure than Shadowsocks, handling identity, time-related information and session data during connection setup. These richer session semantics let clients combine transport, routing and user settings within one system, but they also add processing steps. On desktop devices, these steps are rarely the main bottleneck. On older devices, mobile systems with strict background limits or workloads with many short connections, they may be more noticeable than with a lightweight protocol. “More steps” does not mean inherently slow; it means performance depends more heavily on client implementation and configuration quality.

With VMess, time state and configuration consistency deserve attention. If the device clock is significantly wrong or the client retains incompatible transport parameters after import, setup may fail. This differs from route congestion: congestion usually still allows a connection but causes waiting, jitter or lower throughput; a mismatch is more likely to fail consistently and remain broken after a network change. During troubleshooting, resync the subscription and confirm that the system maintains time automatically before replacing multiple routes. Do not manually assemble fields from unknown sources; use the protocol, transport and security parameters in the subscription as one complete set.

VMess is often used in feature-rich client ecosystems, making routing rules especially important. Whether traffic goes through the proxy, who performs domain resolution, whether local addresses bypass it, and whether the system proxy and virtual network interface are enabled together all change the actual path. “The protocol connects but websites do not open” may mean that resolution did not follow the same path or that the app bypassed the system proxy. In that situation, first use a browser to visit a known test site, then verify other apps step by step instead of masking a routing problem with repeated reconnects.

How to choose between them in practice

If your main needs are browsing, sync and regular video, and you want simple configuration with clear fault boundaries, Shadowsocks is usually easy to maintain. If the client already has a complete VMess routing setup or the subscription provides tested companion parameters, continuing with VMess is often safer than splitting the configuration yourself. Do not choose based on which protocol name sounds newer; check whether both the server and client offer mature implementations. A well-maintained traditional setup with a stable path often beats a newer setup with mismatched parameters.

Avoid cache interference when comparing. A page already cached by the browser does not represent a fresh connection, and video apps may have buffered content in advance. Choose an ordinary page you have not opened before, restart the client before testing, or use a request for response headers to confirm connection setup. Test commands only verify whether a path can work; they do not represent the full application experience:

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

curl can help distinguish “the request cannot be established” from “page resources load slowly.” ping only observes whether the target responds and how round-trip time changes; it cannot directly replace a speed test for the proxy path. Some targets do not respond to probes, so one failed command does not prove that a route is unavailable. Always combine these results with real applications, client logs and outcomes after replacing variables.

Modern combinations

How to choose between Trojan and VLESS

Trojan: building on mature secure transport

Trojan is typically built on mature secure transport, with authentication, encryption and connection protection handled together at that layer. Its value is not a standalone speed label, but the ability to reuse established security libraries in operating systems and clients while managing connection behavior alongside familiar encrypted sessions. Mature libraries are generally stable, but the handshake still exchanges required information. On routes with high round-trip time or noticeable packet loss, any setup process requiring multiple exchanges will be amplified. When Trojan’s first request is slow, check route round trips and domain resolution as well rather than blaming protocol encapsulation alone.

The certificate name, service address and client settings must match. If subscription fields are edited manually, the remote port may be reachable while the secure handshake still fails. Client logs will often show authentication, name or handshake errors rather than sustained timeout fluctuations. The appropriate fix is to fetch the subscription again, check system time and restore the original parameters—not to disable security checks. Weakening verification just to “get connected” makes diagnosis unreliable and is unsuitable as a long-term configuration.

Trojan’s sustained transfers are still affected by the underlying reliable transport. When loss occurs, retransmission and congestion-window adjustment control the sending rate; after the route recovers, throughput needs time to build again. If video starts normally but buffers continuously after local Wi-Fi weakens, move closer to the access point or switch networks and then retest the same route. If the local network is stable but Trojan routes differ significantly, focus on the entry path and egress load. A protocol name cannot erase the physical and operational differences between routes.

VLESS: flexibility through layered authentication and transport

VLESS keeps the protocol itself relatively compact and leaves encryption and transport security to the outer combination. This layering allows it to work with different carriers, but “using VLESS” does not fully describe a connection. Actual behavior also depends on the underlying transport, outer security, reuse, domain-resolution path and client routing. Therefore, record the complete transport combination when comparing VLESS. Looking only at the protocol label in a node name can easily turn outer-configuration differences into supposed protocol differences.

The advantage of layering is clear separation of responsibilities. Authentication failures, outer-handshake failures, underlying connection timeouts and application routing errors can usually be identified separately through logs. The cost is that the configuration fields must match precisely: the client must use the same carrier as the server, and names, paths and other outer-security fields cannot be changed arbitrarily. The subscription is designed to keep these fields consistent, so most users should obtain it from the panel and import it in full rather than copy individual node fields. VPNGa requires no email address for registration; a username and password are enough. Subscriptions and client access are managed together in the user panel.

VLESS is also often used with a virtual network interface, allowing apps without system proxy support to follow a unified path. Performance then depends not only on the protocol but also on the system interface, routing table and the way domain resolution is intercepted. If the browser works but one desktop app cannot connect, first check whether that app uses an independent network stack. If every app is affected, check that the virtual interface started successfully, that no other network tool is running at the same time, and that the default route was not modified twice. Multiple tools taking over the system network are harder to explain than most protocol issues.

Balancing connection setup and long-lived sessions

Short-lived connections care about setup cost; long-lived sessions care about staying stable. Trojan uses a mature secure session for authentication and protection, while VLESS depends on its outer combination. On a good route, the difference between them may be smaller than the difference between two entries. If your workflow includes many repository requests, web resources and API calls, check whether the client supports connection reuse and session recovery. For video, sync or remote desktop, focus more on sustained transfer and latency variation. Do not draw conclusions about long sessions from the speed of one page load.

A mobile network change alters the local address of an existing connection. Sessions that depend on traditional connection state usually need to be re-established, and the client’s reconnect policy determines how smooth recovery feels. Some clients retry immediately; others wait for the system to confirm network availability. If the client says “connected” but apps have no traffic after a network change, disconnect and reconnect manually to determine whether the session failed to migrate or the route is unreachable. If manual reconnection restores service immediately, the issue is more likely the client’s network-change monitoring than an unavailable remote protocol.

Read logs from the earliest failed stage. If the domain cannot be resolved, no later handshake can occur; if the remote connection times out, authentication never gets a chance to run; if the handshake succeeds but the app fails, continue with routing and destination checks. Do not capture only the final error line, which is often just a summary of an upstream failure. Connect nearby records for resolution, connection, handshake and forwarding by time to determine whether to change routes, restore the subscription or correct local network settings.

The choice can remain simple: if an existing Trojan setup is mature and stable, there is no need to migrate because the protocol name changed. When you need clear layering, unified routing and flexible carriers, consider a well-supported VLESS combination first. In either case, follow the configuration actually provided by the server. Sound protocol design cannot compensate for a route with persistent packet loss, severe detours or a congested entry.

Unstable paths

Transport ideas behind Hysteria2 and TUIC

Why use an approach different from traditional reliable byte streams

Traditional reliable transport emphasizes in-order delivery, congestion control and broad compatibility, making it suitable for many network applications. But on paths with high round-trip time, random loss or obvious wireless fluctuation, one missing segment can make later data wait even after it has arrived, which appears to the application as a sudden pause. Hysteria2 and TUIC build on modern datagram-oriented transport capabilities, combining encryption, stream multiplexing, loss recovery and congestion control in a framework better suited to independent stream management. Their goal is not to erase physical distance, but to reduce cross-request blocking and handle session state more flexibly when the path is imperfect.

This design also has boundaries. Datagram traffic may face stricter shaping on some local, enterprise or public-access networks; address changes, idle cleanup and datagram fragmentation can affect stability as well. If a traditional protocol works while Hysteria2 or TUIC does not, that does not directly prove a server fault; the access network may simply handle datagram transport differently. Conversely, these protocols may behave more smoothly on wireless or inter-network paths. The two categories are best kept as alternatives, not treated as universal replacements.

Hysteria2: sustained throughput and adaptation to fluctuation

Hysteria2 is most valuable for its transport strategy on unstable paths. It adjusts sending based on acknowledgements, loss and round-trip changes, while allowing multiple application streams to share a secure session. Compared with forcing everything through one strictly ordered byte stream, independent streams can reduce the spillover from one lost request to others. Video buffering, file sync and pages with many resources may feel more continuous as a result. But if the local link is already saturated, aggressive sending only lengthens queues; if the server entry or egress is congested, the protocol cannot create bandwidth.

When configuring Hysteria2, respect the bandwidth and congestion-control presets supplied by the server. Entering values far above the real link capacity can cause the sender to inject data too quickly, creating long queues in the local router or operator network. Downloads may appear fast while web interaction, voice and control requests become more latent. Values that are too low limit available throughput. Without reliable measurements, the subscription defaults are safer. If the client supports network-specific profiles, you can keep tested configurations for stable wired networks and fluctuating mobile networks, but keep the route fixed for each comparison.

Datagram size can also affect a path. When packets exceed what the path can carry, they may be fragmented or dropped. Some networks handle the relevant feedback incompletely, producing a pattern where small requests work but large pages or sustained transfers fail. Most users do not need to change low-level sizes manually. Use the pattern “simple pages work, larger transfers repeatedly stop” as a clue, then restore client defaults or switch the route or access network. Investigate finer parameters only when logs clearly point to datagram size.

TUIC: balancing quick sessions and mobile use

TUIC also uses the multipath capabilities of modern datagram transport, with attention to connection setup, stream management and recovery in mobile environments. Multiple application requests can travel as relatively independent streams, so loss on one stream does not force every other stream to wait. This separation matters on devices that load browser resources, maintain chat connections and sync in the background at the same time. Client and server implementations must still work together, and system scheduling, cryptographic libraries and background policy affect the final experience.

On mobile, do not judge TUIC only by foreground peak speed. More important questions are whether the system pauses the connection when the screen locks, whether it recovers when the screen wakes, whether a Wi-Fi-to-cellular change requires a full reconnect, and whether long use causes frequent processing wake-ups. Session migration can reduce some reconstruction after network changes, but the operating system may still freeze background processes. If the system already restricts the client’s background activity, no protocol can maintain a connection while its process is not running. Allow the client necessary background network access and avoid running multiple virtual network tools at once.

When a TUIC connection fails, first distinguish an unavailable datagram path from a configuration mismatch. The former often appears as the same configuration recovering on another access network while a traditional reliable-transport protocol still connects. The latter usually fails repeatedly on every network and comes with authentication or handshake logs. Keep the client and subscription fixed, then change the access network as a low-cost test. Keep the access network fixed and switch to a traditional protocol in the same region to check whether the issue is concentrated in the datagram path.

When is it worth switching to this class of protocol?

If a traditional protocol already meets your web, video and work needs on a stable network, there is no reason to switch just for a new name. If the symptoms center on random loss, mobile fluctuation or multiple apps slowing one another down—and both client and server offer mature configurations—Hysteria2 or TUIC is worth testing as a comparison. Keep the egress region, app and access network unchanged, and observe first load, sustained transfer, interaction response and recovery after network changes rather than recording only the peak. If improvement appears only on one access network, treat it as a network-compatibility finding, not a universal conclusion.

Fair comparisons must also include resource cost. Modern datagram protocols may trade more active acknowledgements, encryption and session maintenance for recovery capability, and wake frequency and processor use on mobile devices can vary by implementation. During continuous foreground transfer, every protocol must process data constantly; differences are easier to see in keepalive behavior while idle in the background. When comparing battery use, keep the screen, apps, signal strength and test duration similar, and check the system’s per-app battery statistics. One instance of heat does not prove long-term battery drain, because initial sync, video decoding and transmission under a weak signal also consume power.

Device behavior

Connection setup, resource use and mobile battery life

What happens during connection setup?

After the user taps Connect, the client does not immediately begin forwarding application traffic. It typically reads subscriptions and routing rules, resolves the service address, establishes transport to the entry, completes authentication and the secure handshake, creates a local proxy or virtual network interface, and then directs system traffic into the new path. Waiting at any stage can leave the interface showing “connecting.” Connection setup time therefore cannot be explained by protocol complexity alone. Slow resolution, a detour to the entry or a virtual interface occupied by another tool can produce similar symptoms.

Use client logs and simple comparisons to separate the stages. If the log remains at service-address resolution, check local resolution and the access network. If an address was obtained but the connection times out, check entry reachability and the route. If authentication fails after transport is established, resync the subscription and check system time. If the client reports success but apps have no traffic, check routing, the system proxy and whether domain resolution follows the same path. Stage-by-stage handling is more effective than repeatedly clicking Connect; frequent retries can also leave old and new sessions overlapping, making diagnosis harder.

Workloads with many short connections amplify setup cost. A web page may simultaneously request the document, images, scripts and APIs, while developer tools repeatedly contact repositories and dependency sources. If the client supports connection reuse or session persistence, it can reduce repeated setup, but more reuse is not always better. Binding too many requests to one underlying connection means one lost packet can affect more streams; keeping too many idle connections consumes memory and increases keepalive work. Defaults usually balance compatibility and performance, so compare reuse options only after confirming a clear short-connection bottleneck.

Processor, memory and system network interfaces

Protocol resource use comes from encryption, encapsulation, data copying, logging, rule matching and system-interface changes. Hardware acceleration for the cipher, the client’s language and network library, and whether a virtual interface processes data in user space often matter more than the protocol name. Desktop devices generally have more resources, but a client process may still work continuously at high throughput. Mobile thermal management is stricter; as temperature rises, the system may reduce processing capacity, which in turn lowers transfer speed.

Memory use depends on rule size, connection count and buffering. When a subscription contains many routing rules, the client must build matching structures; concurrent connections retain state; buffers are needed to smooth high-round-trip paths. Higher memory use does not necessarily indicate a leak, but continuous growth while idle or failure to drop after every reconnect warrants restarting the client and preserving logs to check for an implementation issue. Do not compare by running multiple clients at once: they may listen on the same local ports, modify the system proxy or compete for the virtual interface, invalidating the result.

A virtual network interface can cover more applications, but its processing path is more complete than ordinary system proxy mode. All routed traffic enters the client, so local-network access, system updates and background sync may be included. If you only need a browser and a few proxy-aware tools, system proxy mode may be lighter. If you need unified handling for apps without proxy support, virtual interface mode is more suitable. Choose based on coverage, not on the assumption that one mode represents a speed tier. After switching modes, confirm that local devices, print services and local development addresses remain reachable as expected.

What determines mobile battery use?

Mobile power use is not just encryption cost. The wireless module must wake from low-power states to send and receive data, and frequent small keepalives can be less efficient than concentrated transfers. With a weak signal, the device raises transmit power and retransmits more often. Apps refreshing in the background also keep the client active. The protocol affects keepalives and reconnects, but signal quality, app behavior and system background policy matter just as much. Before comparing battery use, eliminate differences in brightness, video decoding, location services and background sync.

Network switching is another significant cost. When a device repeatedly disconnects and reconnects at the edge of a Wi-Fi network, the client may repeatedly resolve, negotiate and rebuild routes. Session migration can reduce some of this work, but system network callbacks, domain updates and virtual-interface recovery still have to run. If you frequently switch networks in one place, disable automatic connection to poor access points that repeatedly compete for the device, and keep it on a more stable network. A stable path usually improves battery life, latency and throughput together, making it more effective than searching for a “battery-saving protocol.”

Background policy should be balanced. Fully restricting the client can pause the connection after the screen locks, forcing a rebuild when the app opens again. Unlimited background activity may let unnecessary apps keep generating traffic. A sensible approach is to allow the connection client the background activity it needs while checking which apps truly require background sync. VPNGa supports Windows / macOS / iOS / Android / Linux and has no device limit, but each device still needs settings optimized for its own system rather than copying desktop configuration to mobile unchanged.

Build a fair device comparison

When comparing protocol resource use, use the same device, client, route and similar application load. Restart the client and wait for background sync to finish, then observe idle use, web browsing and sustained transfer separately. Record processor, memory, network and battery trends shown by the system rather than capturing one moment. If a protocol continuously generates traffic while idle, check keepalives, health checks and subscription updates. If usage rises only during high throughput, that is normal data processing; judge it by whether other apps are affected.

State conclusions with boundaries—for example, “on this Android device under its current background limits, this client recovers slowly,” not “this protocol is slow on all mobile devices.” Client updates, the system network stack and access environment can all change the result. Include the device and environment in your records so future differences can be attributed to route, system or implementation changes. For complete installation and import steps, return to the quick start; this chapter explains why each stage affects the experience.

Transport paths

Direct, relay and dedicated route topology

Direct: fewer hops, but greater dependence on inter-network quality

A direct route sends traffic from the access network straight to the remote service entry, without an access relay explicitly arranged by the provider. Its advantage is a simple path with fewer forwarding stages. When inter-network connectivity from the local network to the destination region is good, direct access can provide naturally low latency and a clear fault boundary. The same simplicity is also its weakness: the provider has less control over how the local operator selects an inter-network path. Different providers, regions and even times of day may use entirely different upstreams, so peak-hour congestion is reflected more directly in the connection.

Direct access works well as a baseline. If a nearby egress is consistently stable on your local network, keep it as a regular route to avoid unnecessary relays. If the same egress varies widely across access networks, the issue may be in the inter-network segment between the local network and the entry. Changing protocols can alter loss recovery but usually cannot change the route itself. Switching to a relay entry or another egress region may actually change the path. Routes are organized by region on the node page; see Routes and Nodes for coverage.

Physical distance is not the only basis for direct-route performance. A geographically closer city may require a network detour, while a slightly farther entry with better interconnection may have smoother round trips. Narrow the choices by region first, then compare the same applications. Do not rely only on map distance or on one probe. Inter-network routing can change with operator policy and time of day, so keep a stable backup region for long-term use.

Relay: replace an unstable inter-network segment with a controlled entry

A relay route first sends traffic to a nearby or better-connected access point, which then forwards it to the egress. Its value is replacing the most volatile inter-network segment with a path the provider can manage. In environments where direct access detours or interconnection quality varies by operator, relays can often improve stability. The trade-off is an additional forwarding stage, along with capacity and scheduling requirements between entry and egress. If the relay becomes congested, every connection using it is affected.

To assess a relay, compare it with direct access to the same egress region. If the destination regions differ, application region, content delivery and destination routing also change, so the relay cannot be evaluated on its own. Keep the egress fixed and observe first loads, sustained video and interactive applications. If the relay is smoother at peak time but similar to direct access off-peak, it is mainly improving inter-network fluctuation. If it is slower at every time, the entry distance, forwarding capacity or detour may not suit the current access network.

A relay does not mean that every packet travels through more public networks. Providers use different entry and backbone arrangements, so there is no need to guess the internal topology from a name. A more practical approach is to check the route-type label, choose a nearby entry and validate it with real applications. If one relay suddenly becomes abnormal, try another entry in the same region. If the whole group is abnormal, change the egress region or protocol. Group-based checks prevent a single-route fault from being mistaken for a protocol-wide problem.

Dedicated: controlled paths and stable scheduling

A dedicated route generally means more controllable transport resources between entry and egress, with emphasis on path stability, capacity planning and inter-network quality rather than making distance irrelevant. Compared with an ordinary relay, it gives the provider more control over the middle segment and may deliver a more consistent experience during peak hours and across networks. The device-to-entry and egress-to-destination segments are still part of the complete path, so weak local Wi-Fi or congestion at the destination service cannot be solved by a dedicated route alone.

Entry selection still matters on a dedicated route. If the device must first take a long detour to another entry before reaching the stable middle segment, overall latency may be poor. Prefer an entry with good interconnection to the local access network, then choose the egress for the destination service. Real-time communication usually favors short paths and low jitter; long video and downloads favor sustained capacity; office and developer tools require a balance between first-load speed and stability. A dedicated route is a path resource, not a universal performance tier.

Route maintenance can also change the real topology. A provider may switch paths during entry maintenance, backbone changes or egress incidents. The client may show the same route name while the experience temporarily differs. When something changes, reconnect first to see whether a new session path was assigned, then compare another route in the same region. If the issue persists, record the time, access network, route name and symptoms before submitting a ticket. A clear record is more useful for locating the fault than saying “the dedicated route got slower.”

A practical order for choosing topology

Choose the egress region first because the destination service may assign different entries or content based on location. Then choose the route type to compare different paths from the local network to that egress. Compare protocols last to assess whether connection setup and loss recovery suit the current network. If you change region, route and protocol at the same time, you cannot know what caused a brief improvement. Stable selection is not about finding one perfect node; it is about keeping regular and backup combinations with clear use cases.

VPNGa covers 100+ countries / 190+ routes; see the current nodes page for route details. Coverage indicates the available choice, not identical performance for every region and local access network. Cross-border paths consist of multiple networks, and any segment can change. Keeping records, maintaining backups and adjusting by symptoms better reflects how real networks operate than relying on one fixed route.

Fault isolation

How to assess packet loss and peak-hour congestion

Packet loss does not come only from remote routes

When packets fail to arrive as expected, the result is observed as packet loss, but the loss may occur on local Wi-Fi, a home router, the access operator’s network, inter-network links, relay paths, the egress network or near the destination service. Wireless interference, edge-of-coverage signals, router queue overflow, link congestion and device sleep can create similar symptoms. One lost probe cannot locate the exact segment or prove a protocol fault. Narrow the scope layer by layer by changing the access network, keeping the route fixed and comparing multiple destinations.

Packet loss affects different transports differently. A reliable byte stream retransmits and preserves order, so an application may show a pause rather than corrupted content. Modern multiplexed transport can recover independent streams separately and reduce mutual waiting, but key data still has to be restored. Real-time apps may discard outdated data to keep the current interaction responsive. As a result, video, web pages and voice can show different symptoms on the same path. An occasional web delay does not mean voice must be choppy, and normal download speed does not prove stable interactive latency.

An overlong local queue can also look like remote congestion. When photo uploads, file sync or cloud backup fills the upstream, acknowledgements and interactive requests queue in the home router, slowing downloads and voice. Pause large local transfers and see whether the same route recovers. If it improves immediately, address local bandwidth competition and router queues instead of changing protocols. If all local tasks are stopped but only one route remains abnormal, continue with entry and relay checks.

Why does peak-hour congestion vary by time?

Peak hours mean more simultaneous use of access networks, inter-network links and content services, increasing queueing and loss on shared links. Congestion may occur in the local neighborhood access segment, operator interconnection or remote entry. A typical pattern is that the same configuration works at other times but repeatedly degrades during a fixed busy period; changing the local network or route type may produce a clear difference. Protocols can adjust sending and recovery, but they cannot replace insufficient shared capacity, so route and entry scheduling are usually more important than client parameter changes.

To assess a time-based issue, keep continuous records instead of switching randomly as soon as a problem appears. Record the current access network, route, protocol and application symptoms. Try another route in the same region to test for a single entry, then another route type to test the inter-network path, and finally another local network to test the access side. If every remote route is abnormal on one local network but normal on another, focus on local access or the operator. If only one egress group is affected, the remote path or egress load is more likely.

Speed-test tools can also mislead. A single-connection test emphasizes one session’s congestion behavior, while a multi-connection test fills the link with concurrency. Short tests can capture a burst of buffering; long tests better represent sustained transfer but are also affected by the test server. Speed figures on promotional pages cannot replace your own network conditions. See How to Run a VPN Speed Test for a consistent process with fixed tools, similar times and matching metrics. The goal is to compare changes, not chase a context-free peak.

Map symptoms to likely layers

When a connection cannot be established at all, check the subscription, resolution, entry reachability and handshake first. When it connects but every app is slow, check the local network, route and system routing. When only the first web load is slow, check resolution, short connections and reuse. When video starts quickly but buffers continuously, check throughput, loss and egress capacity. When voice and remote control are choppy but downloads are normal, focus on queueing, jitter and upstream competition. When service fails after a network change, check client reconnects, background permissions and session migration. Symptom mapping is not absolute, but it reduces directionless experimentation.

The destination service itself must also be considered. If multiple routes have trouble reaching the same destination while other sites and apps work, the service’s regional entry, account status or content delivery may have changed. Switching egress regions also changes the destination entry, so an improvement does not necessarily mean the original route is damaged. Use one route with several different destinations, then several routes with the same destination, to build a cross-check. Selection becomes less erratic only when route problems are separated from destination-service problems.

Logs, commands and privacy boundaries

When reporting a fault, include the error type, route name, protocol, access-network category, device platform, client mode and approximate time. Logs may contain service addresses, user identifiers or subscription details; remove authentication fields and complete subscription links before sharing. Do not provide personal information unrelated to the fault. VPNGa requires no email address for registration; a username and password are enough to use the service. The ticket entry is in the user panel and is suitable for a structured fault report.

Command-line tools can verify basic resolution and requests, but a single result should not be treated as a final speed test. The examples below use public example domains and contain no real credentials:

nslookup example.com
curl -I https://example.com
traceroute example.com

Available commands vary by system, and some networks do not respond to path probes. Successful resolution only means an address was obtained; a successful request shows that the application layer can establish a basic connection. A path probe shows a possible route, which may not be identical to the encrypted connection. Commands help locate a stage; they do not create an availability guarantee. When results conflict, rely on real applications, client logs and reproducible outcomes after replacing variables.

Practical decisions

Choose protocols and routes by use case

Web, office and developer tools

Web and office apps usually involve many short requests, domain resolution and API calls, so stable setup and clear routing matter more than an instantaneous peak. Start with a nearby entry that has good interconnection to the local network, using Shadowsocks, Trojan or a mature VLESS combination as a baseline. If first loads occasionally pause but sustained downloads are normal, focus on resolution, handshakes and connection reuse. If repositories, dependency downloads and web pages all slow down together, continue comparing route types. Relays or dedicated routes may improve inter-network fluctuation, but compare them against the same egress before deciding they are worthwhile.

Development environments also commonly need local-network and local-address access. After enabling a virtual network interface, confirm that local development services, container networks and local devices remain reachable as expected. Do not force every domain to a remote path and then try to diagnose local services from the other side. Keep client routing rules readable and save the original configuration before editing. If a subscription update removes custom local rules, use the client’s override or local-rules feature instead of editing generated subscription content directly.

Collaboration tools that must stay connected should be assessed for recovery after disconnection. Device sleep, network changes and background suspension can invalidate a session. If the app supports automatic reconnect, a brief recovery period is usually acceptable. If every recovery requires manual action, comparing the client’s system-interface mode and background permissions is more valuable than continuing to change egresses. The goal for office use is fewer unexpected interruptions, not the route with the highest startup peak every time.

Video, live streaming and large-file transfers

Video and large files depend more on sustained throughput, interconnection from the egress to the destination service and recovery after packet loss. Choose the egress based on the content region first, then compare direct, relay and dedicated routes there. Traditional reliable transport is usually sufficient on stable routes. If wireless fluctuation is obvious and both server and client provide mature configurations, compare Hysteria2 or TUIC. Watch or transfer a complete segment, recording frequent buffering, repeated quality changes and whether other interactive apps are slowed.

Do not judge a video route while uploading a large file. A saturated upstream makes acknowledgements and control requests queue, slowing playback as well. Pause background sync first and confirm local headroom before assessing the remote path. If only certain content on a video platform is affected, content delivery or account region may be involved. If all video and downloads decline on the same route, the path or egress capacity is more likely. For regional streaming notes, see Streaming access guide.

Long-term selection should include traffic usage. VPNGa monthly plans are ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB; traffic resets monthly on the activation date, and mid-cycle upgrades are prorated by the remaining days. Traffic packages are ¥158/300GB, ¥358/1000GB and ¥658/3000GB, valid until used and never expiring. Choose according to actual usage; see the Plans page for complete rules. The service offers a 7-day no-questions-asked refund, with Alipay / WeChat / USDT supported for payment.

Voice, remote desktop and real-time collaboration

Real-time applications are more affected by sudden latency spikes, upstream queueing and short bursts of loss than by low average speed. Prefer a short, low-jitter path and do not take a long detour for an egress name. When direct connectivity is good, keep the path simple. When local-to-remote inter-network fluctuation is obvious, compare relay or dedicated routes. Traditional options are predictable on stable paths; modern datagram options may reduce waiting between streams on unstable paths, provided the current network can carry datagrams reliably.

When testing a real-time app, observe voice, video and control feedback together. A download test cannot show upstream competition or queueing delay. Let the route sit idle, start a call, then gradually resume normal background tasks to identify which traffic causes jitter. If pausing uploads restores the call immediately, address local queues and sync schedules. If switching routes restores it, keep the original route as a backup for non-real-time work. Different use cases can reasonably use different routes; one connection does not have to handle everything.

Remote work also requires safe recovery after a session interruption. A connection change can make the destination service see a different egress, and some sessions may require verification again. Before an important operation, stabilize the route rather than switching egress repeatedly mid-task. After the client reports a successful connection, visit an ordinary page to confirm the path before entering the remote session. If a switch is necessary, save your work and exit sensitive sessions deliberately instead of retrying repeatedly while the connection is unstable.

Mobile devices and frequent network changes

For mobile devices, recovery and background behavior come first. When switching frequently between Wi-Fi and cellular networks, compare Hysteria2, TUIC and mature VLESS combinations that support session migration or quick rebuilding, while keeping Shadowsocks or Trojan as broadly compatible backups. If an access network does not handle datagrams well, switching back to a traditional option is more effective than repeatedly changing parameters. Keep the protocol set small and clear instead of filling the node list with duplicate configurations you cannot explain.

Battery settings should follow actual needs. If messages and sync must remain available, allow the client necessary background activity. If it is used temporarily in the foreground, disconnect after the task to reduce idle keepalives. Poor signal increases retransmissions, heat and battery use together, so moving to a stable access network is usually more helpful than changing encryption options. On mobile, “connected” on screen does not mean every app is always available; lock-screen recovery and actual requests after a network change are more valuable tests.

Android background policies vary widely, so check whether the system freezes the client. iOS network extensions are managed by the system; focus on recovery after lock-screen and network changes. Do not copy complex desktop routing rules directly to mobile, because mobile apps, local-network needs and background limits differ. VPNGa has no device limit, so keep platform-specific configurations suited to each system rather than sacrificing stability for a uniform setup.

Build your own stable set

After choosing your setup, there is no need to keep many similar nodes. Define a regular combination, a backup for unstable networks and a backup for the target region, and note each purpose in its name or description. Validate the regular combination at different times; periodically confirm that backups still connect instead of trying them for the first time during a fault. Routes and networks change, so update the stable set based on records and actual behavior—not simply because a new protocol name appears.

When reviewing an incident, return to three questions: at which stage did it occur, which variable restored service, and can the recovery be reproduced? If reimporting the subscription restores service, focus on configuration consistency. If a route in the same region restores it, focus on the entry or path. If changing the local network restores it, focus on access. If only one app is affected, focus on application routing and the destination service. Write conclusions as conditions like these so the next similar symptom can follow the same path.

This closes the loop between this technical guide and the quick start: the quick start covers the workflow from registration, plans and subscription to the first connection, while this page explains protocols, devices, topology and fault symptoms. For an objective route comparison, continue with How to Run a VPN Speed Test. To assess long-term subscription risk, see Guide to Choosing a Stable VPN Long Term. Establish a reproducible method before choosing a protocol or route; it is usually more reliable than chasing one speed-test result.