Protocol and Route Reference

How Protocols, Transports and Routes Differ

Break a connection into observable steps

When you open a webpage, the app identifies the destination, connects to the service, then exchanges requests and responses. With a proxy client, app traffic may first pass through a local proxy port or be handled by a virtual network interface. Rules then direct it to a remote node, which connects to the destination service. The process involves local traffic handling, DNS resolution, proxy authentication, transport and outbound access. A delay at any stage can make a page feel slow, but the right fix depends on where the delay occurs.

Protocols define how a client and server identify requests, verify identity and package data. A transport carries that data, commonly over TCP or UDP; TLS and QUIC provide mechanisms for connection security, reliable delivery or stream management. A route describes the networks and nodes the data passes through. Confusing these layers can make it hard to understand why changing protocols doesn’t fix a slow connection: the protocol may have changed, but the congested inter-network path and remote exit have not. The bottleneck is still there.

Slow connection setup doesn’t mean slow data transfer

A first visit to a website may involve waiting for DNS resolution, a transport connection, a secure handshake and the destination’s response. Once a connection is established, it may be reused, so later requests don’t need to repeat every step. If the first page loads slowly but browsing is fine afterward, setup overhead may be the cause. If downloads remain slow, check available throughput, packet-loss recovery and any speed limits at the destination. Don’t use a download progress bar as a measure of web browsing, or assume that a page opening instantly means a long transfer will be stable.

“Connected” usually means the client has established a tunnel or proxy session. It doesn’t prove that all apps are using the proxy or that the destination accepts the current exit. If one app won’t load, its traffic may not match the routing rules, it may use a different DNS path, or the service may reject the current access conditions. First confirm that the client received the app’s request, then check which rule handled it. Repeatedly switching nodes can make a configuration issue look like a route problem.

Before comparing, keep the test conditions consistent

For a meaningful comparison, keep the device, network, task and test time as consistent as possible, and change just one variable. If you also switch from Wi-Fi to cellular, change from a nearby region to a distant one, and select another protocol, you won’t know which change affected the result. Nodes with similar names may also use different entrances and exits. The protocol label in your client is only part of the picture. Record the region, route type and any additional transport encapsulation too.

This page explains general protocol designs; it doesn’t mean every VPNLay route supports every combination. Check the dashboard and client subscription for current support. VPNLay offers 120+ countries / 240+ routes. That describes the range of options, not identical topology in every country or guaranteed access to every destination. To check regions and route types, start with Global Nodes, then return here to understand what the labels mean.

Shadowsocks, VMess and Trojan

Shadowsocks: Encryption Methods and Implementations

Shadowsocks uses a relatively lightweight approach to proxying traffic and protects data between the client and server with a selected encryption method. It isn’t a particular route, and its name alone doesn’t tell you how much of your device’s resources it will use. Protocol versions, encryption methods and client implementations can affect authentication, data handling and hardware acceleration. Preserve all parameters supplied with your subscription. Applying an encryption setting from another guide to an existing node can prevent the client and server from communicating.

With supported hardware acceleration and a stable network path, lightweight encapsulation may reduce some processing overhead. That doesn’t mean Shadowsocks is always faster or more power-efficient. Additional plugins or transport layers can change the overall cost. On mobile, check whether the client keeps connections open, probes the network frequently or is restricted by background policies. Compare the full configuration, not a protocol family as if it were a standalone performance switch.

VMess: Configuration Matters More Than the Label

VMess has its own authentication and data-encapsulation mechanisms, and deployments may use different underlying transports. Nodes with the same name in a client may follow different connection paths: some establish a transport connection directly, while others add an application-layer transport. Extra encapsulation can allow more flexible deployment, but may also add handshakes, buffering and potential points of failure. When investigating a slow connection, distinguish an authentication failure from a failure to establish the underlying connection, or a successful outer connection with stalled forwarding.

These configurations often include a server address, port, user ID, transport type and related security options. The fields work together; a correct address alone isn’t enough. If the client reports unsupported fields or parsing warnings after import, first check that its core supports the combination in your subscription, then consider updating the subscription. Deleting parameters you don’t understand may let the configuration save but cause the connection to fail. See the Subscription Link Basics guide for how to get and update a subscription.

Trojan: TLS Is Part of Connection Setup and Verification

Trojan typically carries authentication details and proxy requests over a TLS-protected connection. Certificate validation, server-name matching and the state of the certificate trust chain all affect whether the connection can be established. An incorrect system clock, a mismatched server name or an issue with the local trust store can cause a handshake failure. Check the clock, subscription and client logs first. Disabling certificate verification isn’t a routine fix: skipping verification changes the security boundary.

Common TCP-based transports preserve byte order. If underlying data is lost, later data may have to wait for the missing data to be recovered, which can feel like a pause. Connection reuse avoids the overhead of repeatedly establishing connections, but multiple tasks may share the same underlying connection and its limitations. The name Trojan doesn’t guarantee low latency or high throughput. On a lossy link, reliable, ordered transport still has a recovery cost; changing the authentication layer’s appearance doesn’t remove it.

There’s no universal ranking for these options outside a specific environment. First confirm the configuration is supported, then compare connection success, initial response and sustained transfers for the same task. Keep conclusions specific to the device and network conditions tested.

VLESS, Hysteria2 and TUIC

VLESS: Authentication Isn’t a Complete Security Layer

VLESS keeps proxy authentication and request details relatively lightweight. It doesn’t provide complete data encryption on its own, so an external secure transport is needed to establish protection. When you see VLESS, check which transport and security options it’s paired with. A modern-sounding protocol name is no reason to overlook certificate verification or the source of the configuration. Whether a combination works depends on matching client-core support, server settings and subscription parameters—not simply whether the name can be selected in the client.

A lightweight protocol header may reduce some encapsulation overhead, but connection time is often shaped by DNS resolution, handshakes and network round trips. If the outer transport establishes a new secure connection, the reduced work in the authentication layer may not be the main factor. Connection reuse, session resumption and client implementation also affect the experience. Record cold starts separately from repeat visits. Don’t compare an established session with a freshly started client or attribute a page appearing instantly to the protocol alone.

Hysteria2 and TUIC: QUIC-Based Approaches

Hysteria2 and TUIC both use QUIC-based transport, but they are different protocols and their authentication fields aren’t interchangeable. QUIC typically runs over UDP and integrates encryption, reliable delivery and stream management into its connection design. Separate streams aren’t necessarily subject to the same ordered-byte-stream delivery constraints, which can reduce waiting between unrelated requests under some packet-loss conditions. Congestion control, link capacity and endpoint performance still determine the overall result.

UDP is only an underlying transport; it doesn’t make data reliable or mean an app can ignore loss. QUIC provides acknowledgements and recovery for streams that require reliable delivery, while proxy protocols have their own rules for handling datagrams. Interactive tasks may prioritize timely delivery; file transfers must preserve data integrity. When someone says “packet-loss resistant,” clarify whether they mean recovery efficiency, pauses in interactive use or sustained throughput. It doesn’t mean lost data has no cost.

Check whether the network supports the transport before changing its settings

Some access networks handle UDP differently from TCP. They may limit its speed, use short session timeouts, change routes or forward traffic unreliably. QUIC-based routes may then fail to connect, stop working after idling, or work at first and stall later. If a stream-based route works on the same network, use it as a comparison to help identify transport differences. A failed UDP-based option doesn’t by itself mean there’s a problem with your account, and a network that works well doesn’t guarantee the same result on every network.

Hysteria2 congestion-control and bandwidth-related settings, as well as TUIC connection-management and congestion-control options, depend on the implementation. Don’t set an adjustable bandwidth far above your actual access capacity just to aim for a higher number. A mismatch can increase local queueing and slow webpages, calls and other devices. If your subscription already provides parameters, keep the defaults. Make small, controlled comparisons only when you can reproduce the issue, understand the fields and revert your changes.

Choosing Direct, Relayed and Dedicated Routes

Direct routes depend on the path; relayed routes depend on the entrance and onward path

A direct route usually means the client connects straight to a remote proxy entrance, not that the physical internet path has no intermediate equipment. Traffic may still cross multiple carrier networks, exchanges and international links. A nearby entrance doesn’t guarantee a shorter path to the destination; peering between the remote exit and destination service matters too. When choosing a direct route, consider connection setup, stability over time and performance for your usual tasks and time of day.

A relayed route adds a forwarding step. The client connects to an accessible entrance first, which then forwards traffic over another link to the exit. This may improve peering between your access network and the remote destination, or shift congestion to the entrance or relay segment. More steps aren’t necessarily slower, and fewer aren’t necessarily better; performance depends on path quality and queueing at each segment. With a stable entrance and a well-chosen onward path, a relay may work better for long-running tasks than a direct route with significant detours.

A dedicated-route label doesn’t replace end-to-end testing

An IEPL dedicated route describes a type of dedicated transport used for part of the route. Your device to the entrance and the exit to the destination website may still use public networks. Better control over one segment doesn’t isolate the entire connection from public networks. Home Wi-Fi interference, a saturated local upload or a slow destination service won’t disappear just because you select a dedicated route. Identify whether the issue is on the access network, transport segment or destination side before switching route types.

A region name in a client usually identifies a node or exit region. It doesn’t tell you the physical data-center location, the route along the way or how every content platform will identify the connection. Websites may consider the exit IP address, account region and their own databases, so a region label is only a starting point. If you need a service in a particular region, check the platform’s rules and test the required feature. A route in that region doesn’t mean every service there will work.

Choose a route for the task and keep a useful backup

For everyday browsing and message sync, start with a route that has a short path and consistent initial responses. For long file transfers, check sustained throughput and whether the connection repeatedly reconnects. Interactive tasks depend more on latency variation and packet-loss recovery. A useful backup should differ meaningfully from your usual route, for example in its entrance or transport type, rather than just having a similar name. Then switching routes can help identify where the problem lies instead of merely landing on a temporarily working path.

Keep a brief record of the network, region, route type, task and symptoms. If performance is fine during the day but stalls in the evening, and different transport types behave differently, investigate possible congestion on a shared link. If all routes fail on the same Wi-Fi network but work after switching networks, focus on the local connection first. For VPNLay regions and route types, check the nodes page and client list. This page doesn’t infer specific cities or promise that one route will always outperform another.

Route labels describe; they don’t score. Record where traffic travels separately from which protocol it uses to decide whether to change the route or the transport next time.

Latency, Jitter and Peak-Hour Slowdowns

Response time, throughput and queueing are different metrics

Latency is the time an interaction takes; throughput is the rate at which data can be transferred over time; jitter describes how much latency varies. Webpages involve many dependent requests, so connection setup and short-response times matter. Video and large downloads rely more on sustained throughput. A route can download well while webpages still feel slow. It may have enough capacity but a long round-trip path, frequent connection setup or a slow destination service.

Buffer queues in a local router or upstream equipment can also increase latency. When files are uploading, cloud drives are syncing or other devices are transferring data, traffic may queue at the outbound connection and delay interactive requests. It’s easy to blame the remote node, but first pause background transfers and see whether browsing and calls improve. If they do, the bottleneck is more likely on the access side. Changing the remote protocol alone won’t usually fix a saturated local upload.

Packet loss can come from congestion or the access network

Packet loss can be caused by congested queues dropping data, but also by wireless interference, a weak signal, device load or changes along the route. Reliable transports detect missing data and recover it, which can cause pauses. TCP’s ordered delivery and QUIC’s stream management handle loss differently, but neither can overcome limited capacity. If the access network is persistently unstable, improving Wi-Fi conditions, moving closer to the access point or using a more stable connection is usually more useful than repeatedly tuning protocol settings.

Lost probe packets don’t necessarily mean app data is also being lost. Some network equipment gives probe responses low priority or doesn’t respond at all, while normal traffic still works. Conversely, successful probes don’t prove that the full path to a website is stable. Focus on the task itself: requests timing out, audio or video cutting out, downloads repeatedly slowing down, and whether these symptoms recur under the same conditions. A probe screenshot alone can’t establish the quality of an entire service.

Verify peak-hour issues across times and routes

Slowdowns during peak hours often happen because more users share access, peering or exit capacity, changing available bandwidth and queueing. If every protocol in one region slows down, suspect a shared path. If only one transport fails through the same entrance, check how the network handles that transport. Keep the destination and device constant while comparing different entrances or route types. Subtracting one daytime result from one evening result doesn’t make for a reliable conclusion.

For long transfers, focus on whether the task keeps progressing, not just its initial peak speed. A brief burst may come from caching, an initial burst allowance or the destination server’s behavior; a later slowdown doesn’t necessarily mean the client has failed. If only one download source is slow, try a similar task from another legitimate source. If all tasks are slow, investigate the route or local connection. For gaming, consider server distance, app routing and proxy support separately. See Gaming Latency and Packet Loss for related details.

When things stall, pause high-traffic background tasks and compare with a backup route. If that fixes the problem, keep narrowing down the variable. If not, save the error and task status, then troubleshoot by layer. Don’t reinstall the client and reset network settings at the same time.

Client Resource Use and Mobile Battery Life

Battery use comes from the whole processing chain

Mobile battery drain isn’t just about encryption. After an app makes a request, the client receives traffic, checks rules, handles DNS, encrypts or decrypts data, and passes it to the system network stack. The wireless radio also has to stay active. These processes all contribute during a sustained download. Background sync, health checks and keepalives can wake the device even when it seems idle. Before comparing protocol power use, keep foreground tasks, background apps, signal conditions and client modes similar; otherwise unrelated factors may dominate.

Support for hardware encryption acceleration affects processing efficiency. The client core, logging detail and rule-set size also influence resource use. Less protocol encapsulation doesn’t guarantee lower overall client usage. Continuous logging, frequent probes or complex rule matching may cost more than the differences in protocol headers. For everyday use, stick with the client’s recommended settings. Temporarily increase log detail to diagnose an issue, then restore the normal level.

Wireless signal and background policies can change the result

A weak signal can cause more retransmissions and wireless activity, increasing battery drain even when traffic is light. When a device switches between Wi-Fi and cellular, connections may need to migrate or be re-established. Some QUIC implementations support connection migration, but success still depends on the client, server and network state. This doesn’t guarantee a seamless switch. To compare battery use, start on a stable network, then test mobile scenarios separately.

System power-saving modes may restrict background activity, causing the client to stop processing while idle and resume when the screen turns back on. This can look like an intermittent route failure but may actually be due to app permissions or background policies. Check the system’s network permissions, background activity settings and client notices before blaming the server. Work-managed devices may have additional network policies; ask the device administrator which connection methods are allowed rather than changing management settings yourself.

Check how traffic is handled on each platform, then monitor resource use

On Windows, macOS and Linux, a system proxy may not cover every app. A virtual network interface can handle more traffic but may add routing and DNS processing. iOS and Android have different background mechanisms and expose different system capabilities to clients. Resource readings aren’t directly comparable across platforms. A more useful test is to use the same device and task, compare routes or transports, and note heat, disconnections and app retries.

If the device keeps heating up while idle, first check for downloads, backups or app updates, then see whether the client is repeatedly reconnecting. Incorrect authentication parameters, DNS loops or unreachable networks can cause ongoing retries. Temporarily pausing unnecessary background tasks is safer than blindly disabling security checks. VPNLay supports Windows / macOS / iOS / Android / Linux, with no device limit. Find the client in the user dashboard. Sign in to get a subscription; the iOS client is available with an active plan.

Battery-saving settings should still let tasks complete reliably. Limiting background activity too much can trigger more reconnects; adding too many keepalives can wake the wireless radio more often. Identify the actual issue, then keep only the settings you need.

Choose Routes Based on What You Need to Do

Web Browsing and AI Tools: Check That the Full Request Completes

Web browsing, online documents and AI Tools often involve short requests, ongoing responses and account verification. First check that the service allows access under your region and account conditions. Then test the initial response, continued output and behavior after reopening the page. A streaming response that stops unexpectedly may indicate a dropped connection, an idle timeout or a limit imposed by the service. A page loading doesn’t prove that a long-lived connection works; narrow the issue down to the specific feature and request stage.

These tasks usually benefit more from a stable, repeatable route than from chasing momentary peaks. Start with a route that connects reliably and keep a backup using a different transport. If you use split routing, make sure the relevant domains and authentication requests follow the expected route. Otherwise, the page and authentication service may use different exits. Before changing rules, understand their order and fallback behavior. Don’t send every unknown domain to a temporary rule and assume the setup is working without testing it.

Streaming and File Transfers: Check Sustained Throughput and Exit Conditions

Streaming needs a steady flow of data and is also affected by content-library region, account eligibility, exit recognition and platform policies. A node’s region label doesn’t guarantee that a particular title will be available or that a given resolution will always play smoothly. Check your account and content availability first, then test playback startup, seeking and sustained viewing. If only one platform fails while browsing and other tasks work, check that platform’s restrictions before changing the entire client configuration.

File transfers reveal sustained throughput, source-side speed limits and competition for local upload capacity. After choosing a stable route, check that the transfer keeps progressing and doesn’t crowd out interactive tasks. If downloads work but webpages slow down during uploads, check for upstream queueing and background sync. For more on streaming catalogs and playback conditions, see Netflix Regions and Bandwidth. For current availability, rely on testing at the time.

Gaming, Online Classes and Multiple Devices: Test Each Type of Traffic

Games are sensitive to latency variation and timely delivery, but a general-purpose proxy isn’t the same as a gaming accelerator optimized for a specific title. Launcher sign-in, game downloads and gameplay may use different connections, so a smooth update download doesn’t prove the route works well in a match. Online classes and meetings may also use separate channels for web authentication, audio and video. Test the features you actually need and confirm the client handles their traffic; a browser test alone can’t establish that every connection works.

When multiple devices share a network, route selection also needs to account for the combined load on a home or office connection. VPNLay has no limit on simultaneously connected devices, but that doesn’t mean the access network has unlimited capacity or that every device should run high-volume tasks at once. Keep interactive devices on a stable connection and schedule downloads for a suitable time. This is often more effective than moving every device to the same node. If one device has a problem, first check its permissions, rules and client status.

Choose your traffic plan separately from your protocol. Monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Data resets monthly on the activation date; mid-cycle upgrades are prorated for the remaining days. Data packs don’t expire and remain available until used. Check the Plans page for billing options rather than assuming a protocol comes with extra benefits. VPNLay offers a 30-day no-questions-asked refund. Payment methods: Alipay / WeChat Pay / USDT.

Narrow a connection issue down to a specific step

Can’t connect: Check the local network and configuration first

If you can’t establish a connection at all, first make sure the device has working internet access, the system clock is correct, the client has the permissions it needs and the subscription has loaded. Check the logs to see where it failed: DNS errors, connection timeouts, authentication failures and certificate verification errors point to different issues. Don’t lump every error under “node unavailable.” If you recently reset the subscription link, the old configuration may no longer work. Get a fresh copy from the dashboard and update it rather than repeatedly trying expired local settings.

If the configuration looks correct but keeps timing out, stay on the same network and try another available transport. Then keep the original configuration and switch to another available network. The first comparison helps identify differences in the entrance or transport; the second helps isolate local access conditions. After each change, test the same task and record the result before continuing. Changing DNS, routing and protocol all at once won’t tell you what fixed the issue, so you’ll have to start over next time.

Connected but having issues: Check traffic handling, DNS and destination access

If the client says it’s connected but only some apps have problems, first check whether the client logs requests from the affected app. If there are no entries, check system proxy coverage, virtual-interface mode and the app’s own proxy settings. If the request appears but matches an unexpected rule, check rule order and matching criteria. If it goes to the right node, investigate DNS and remote access errors. DNS resolution can happen locally or remotely, and the results depend on the mode; check the client’s actual settings.

If a page loads but an action fails, record the exact steps instead of just the website name. For example: a redirect fails after sign-in, a file transfer stalls after it starts, or a new request fails after an idle period. These details are more useful than “the site doesn’t work.” If some pages load but larger responses stall, packet size and fragmentation along the path may be factors, but don’t change interface settings at random. First compare different access networks and transports; make further changes only with evidence and according to the client’s documentation.

Keep clear notes and a reliable way to revert changes

Before reporting an issue, note the platform, client name, access network type, node region, route type, protocol and stage where it occurs. Include only log excerpts relevant to the error, and redact account IDs, subscription links, authentication details and other sensitive fields. A subscription link is an access credential; don’t post it in public discussions or screenshots. If you think it has been exposed, reset it in the dashboard and update every device instead of just deleting the message.

After the connection works again, save the confirmed settings and gradually restore paused rules and background tasks. Don’t switch every device to the same configuration just because one change worked once. First check that the issue is reproducible and the fix is stable. For help, open a ticket from the Support page and include redacted notes. You can create an account without an email address using a username and password. Support won’t need your password or full subscription details to troubleshoot a connection.

The goal of troubleshooting isn’t to try every option; it’s to rule out one possibility with each change. If you’re unsure about the setup, return to the Guides to check the main steps. For account, billing or general connection questions, see the FAQ. Separating reference material from hands-on steps helps prevent accidental changes and makes the next diagnosis faster.