Protocols and routes
Technical reference

Data paths: understanding protocols and routes

What happens when you visit a website

When you open a website, the app looks up its address, establishes a connection, negotiates encryption and then exchanges data. With a proxy client, requests also pass through rule matching, a proxy entry point and a remote exit. A delay at any stage can look like slow loading, even when the underlying causes differ. A slow DNS lookup points to address resolution; a connection that starts quickly but then stalls is more likely a transport or application issue. Before judging performance, identify the stage where the problem occurs rather than blaming the protocol name.

A protocol is an agreement between a client and server about how they exchange data. The transport layer determines how data is delivered across the network, while the route is the actual path between entry point, backbone and exit. These layers can be combined, but they are not interchangeable. The same VLESS configuration can use different transports, and the same relay route can offer different protocol entry points. A name alone cannot tell you how fast or stable a connection will be; other factors determine the result.

First response and sustained throughput are different metrics

How responsive a webpage feels usually depends on DNS lookup time, the connection handshake and the first response. Sustained download speeds depend more on available bandwidth, packet-loss recovery, congestion control and the destination server. A client's latency test often covers only part of this path, and its test address may differ from the service you're using. A low-latency entry point may not have more bandwidth at its exit, and a faster one-off download doesn't mean short requests will feel more responsive. Decide what you need the connection for before comparing options; there is no single ranking that works for every use case.

Connection reuse can reduce the cost of repeatedly establishing sessions, but it also changes how failures affect you. If multiple requests share a connection, a brief interruption can affect several apps at once. Without reuse, each request may have to pay the handshake cost again. Support, whether the feature is enabled and how idle connections are managed all matter. A protocol's theoretical capabilities don't mean they're enabled in your subscription. Check the configuration supplied through your account panel and what your client supports.

Separate app restrictions from network issues

A working network connection only means data can reach its destination; it doesn't determine whether an app allows you to use it. Account region, service coverage, subscription status, content rights and a site's risk controls can all affect functionality after you connect. If an app returns a clear service error, switching protocols repeatedly is unlikely to change your account conditions. First identify whether the error comes from your browser, client or the destination service. This avoids unhelpful trial and error and makes it easier to explain the issue to support.

Privacy also needs to be understood in layers. Encryption on a proxy connection protects data between your client and the proxy server; a site's HTTPS connection protects the application traffic to that site. Changing your exit region does not automatically change your browser login, browsing history or device status. Certificate checks, system updates and account security still matter. VPNDP describes its encryption as “bank-grade,” but you should still check the encryption and identity verification in the actual configuration. A marketing label is no substitute for technical due diligence.

To establish a baseline, keep a configuration that works and note your current network, client platform, selected route and the issue in the specific app. Then change just one variable. Don't change the entry point, protocol, DNS method and routing rules all at once: even if the connection starts working again, you won't know which change helped. The comparisons below follow the same principle: identify the layer, change one thing at a time, then keep the setup that works on your current network rather than accumulating advanced settings with unclear purposes.

Shadowsocks and VMess: trade-offs in design and compatibility

Where Shadowsocks stays lightweight

Shadowsocks focuses on proxying, typically handling application streams and datagrams rather than simulating a complete virtual LAN. Its basic design is relatively simple, but simplicity doesn't automatically make it faster on every device. Encryption algorithm, implementation, system scheduling, connection count and route quality all affect performance. Older configurations can also differ from modern implementations. When reading technical material, check which encryption and session design it covers rather than treating every configuration with the same name as identical.

When choosing an encryption method, check that the client and server use the same one and whether your device supports the relevant hardware acceleration. An algorithm that is light on a desktop processor may not perform as well on a mobile device. Without reproducible data from your current device, ranking algorithms by name isn't useful. For subscription users, the safest option is to use the configuration supplied by the service and explicitly supported by your client. Changing the password, algorithm or plugin settings at random is more likely to cause authentication or decryption failures than improve performance.

VMess sessions and authentication

VMess combines user authentication, session handling and data encapsulation in its design, though the details also depend on the transport used with it. It can be deployed with different transports, so the VMess label alone doesn't tell you how many handshakes occur, how many encryption layers are involved or what throughput to expect. When troubleshooting a failed connection, check the authentication details, system time, client implementation and server configuration. A significantly inaccurate clock can affect time-sensitive authentication, but that doesn't mean every VMess issue is caused by the clock.

These protocols often use configurations with several interdependent fields. Importing a subscription reduces manual entry errors, but check whether your client has correctly recognized the transport and security settings. Seeing a node name in the app only means the entry was loaded; it doesn't mean the server accepted the connection. If it fails, identify the error category: parsing, connection timeout, authentication rejection and security negotiation errors each need a different troubleshooting path. Don't delete the entire subscription based on a single red icon.

Check datagram support across the entire path

An app using UDP doesn't mean the client will automatically send that traffic through the right exit. App interception, routing rules, client datagram support, the remote entry point and the destination service all need to work together. Some websites may load while voice or interactive apps fail because their traffic isn't being intercepted or the datagram forwarding path is incomplete. Check the traffic path first, then decide whether the protocol is suitable. Browser access alone doesn't prove that all app traffic is routed through the proxy.

From a maintenance perspective, there's no need to switch protocols just for a different name if your current setup is stable, the apps you need work and the client is still maintained. But if your device can't read fields in the subscription, or a transport combination keeps failing on your current network, choose another compatible option actually offered by the service. Keep the original connection as a fallback during migration. Test websites, file transfers and commonly used apps, then check whether connections recover in the background. The point of choosing a protocol is to reduce maintenance, not make everyday use depend on constant configuration changes.

If you see only some entries after importing, check the subscription update result and any protocol recognition warnings from your client. Your full subscription URL is an account credential; don't post it in public forums. When reporting an issue, share only the protocol type, platform and error category. If you need to include a screenshot, hide authentication fields. To go through setup again, follow the quick-start guide. You don't need to manually recreate the server configuration to use this technical comparison.

Trojan and VLESS: encryption layers and connection setup

How Trojan uses TLS

A typical Trojan deployment uses TLS to establish a secure channel, then handles proxy authentication and forwarding inside that channel. Certificate verification is central to understanding how it works. The client needs to confirm it's connecting to the expected server, not just that the connection is encrypted. The server address, the name used for security negotiation and the names covered by the certificate must match. These fields aren't always identical, so don't swap them based on guesswork. Keep the relevant subscription parameters intact, and don't disable verification as a routine fix.

TLS negotiation can be affected by system time, certificate validity, name matching and the certificate trust chain. If an error occurs at this stage, simply changing the destination website usually won't help. Check that your device's date and time are correct, update the subscription, then confirm your client still supports the required configuration. If other routes work but one entry keeps reporting a certificate error, save the error details and report it through the user panel. Ignoring the warning may let the connection continue, but weakens identity verification and isn't a long-term solution.

VLESS does not provide full encryption by itself

VLESS mainly handles identity and proxy data encapsulation; it is not a complete, standalone content encryption solution. Its actual security depends on the security layer and transport configuration used with it. A VLESS label in the interface describes only one part of the setup. When reviewing performance information, check what the outer layer is, whether connections are reused and whether traffic is relayed. Combining test results from different setups into a single “VLESS speed” figure often ignores the transport path that actually causes the differences.

This layered design allows for different combinations, but adds compatibility checks. The client must understand the identity parameters, transport and security negotiation fields, and the server must accept the same configuration. If a field doesn't appear in the client, that doesn't necessarily mean it was handled correctly. When you see an import warning, check the client's support for that specific combination, then use another compatible entry offered by the service. Avoid filling in unknown parameters from snippets you find online.

Why a protocol change can speed up the first page load

Connection setup involves more than the protocol handshake. DNS resolution for the entry point, routing detours, server load, session resumption and whether the app reuses an existing connection can all change how long the first page takes to load. Switching to another protocol entry often also changes the port, entry point or exit, so you can't attribute an improvement to the protocol alone. For a meaningful comparison, keep the region and route type as consistent as possible, then check whether the two options actually use similar data paths.

For websites and productivity tools with many short requests, reliable connection reuse is often more important than chasing a one-off peak download speed. But check how reused connections recover after idling: device sleep, network changes or server-side session cleanup can temporarily invalidate an old connection. If the first attempt stalls but a refresh works, check whether the client promptly reestablishes the session. Don't assume every timeout means there's not enough bandwidth; connection lifecycle management and throughput limits are separate issues.

Choose based on the complete configuration

Neither Trojan nor VLESS has a fixed speed rating. If your device supports the full configuration, connections establish smoothly on your current network and your apps work as expected, there's good reason to keep using that combination. If it fails only on one type of network, check whether the entry point is reachable and the transport is compatible before concluding that the protocol design is generally flawed. Server load and exit quality matter too. If needed, try another route using the same protocol to distinguish a protocol issue from a problem with one entry point.

In practice, prefer a configuration with all security fields intact, settings your client can display clearly and low maintenance overhead. When describing it to someone else, include the selected region, route type, protocol and transport combination rather than just an abbreviation. Find more information about VPNDP routes on the network page. Check the user panel for the configurations available on each route. Keeping these details makes troubleshooting easier and avoids repeating tests that have already shown a combination doesn't suit a particular network.

Hysteria2 and TUIC: trade-offs with QUIC

UDP underneath does not mean giving up reliable delivery

QUIC typically runs over UDP, but provides connection management, encryption, reliable streams and congestion control within the protocol itself. So it's not accurate to say that “UDP never retransmits.” Whether app data is sent as a reliable stream or a datagram depends on the specific protocol and implementation. Hysteria2 and TUIC both use QUIC-related capabilities, but they're not interchangeable: their authentication, forwarding and configuration differ, and clients must support each protocol separately.

QUIC's multi-stream design can reduce blocking between logical streams caused by ordered delivery at the transport layer, but it doesn't eliminate every kind of blocking. Streams may still share a congestion-limited link, the same device processor and the same exit. A large download that fills the available bandwidth can still leave webpage requests waiting. This distinction matters: a protocol can improve some transport mechanisms, but it can't create capacity on an already saturated network or replace sensible traffic routing.

Hysteria2 bandwidth settings: what they can and can't do

Common Hysteria2 implementations include bandwidth-related settings and choices for congestion control. The right mode depends on the client and server configuration. A higher bandwidth value isn't always better and isn't a guaranteed service speed. Settings well above your access link's capacity can increase queuing and packet loss, making interactive apps less responsive; overly conservative settings may limit available throughput. If you use a subscription, keep the supplied settings rather than copying values from another network.

On paths with packet loss, some transport strategies may keep sending data more aggressively, but the result depends on the source of the loss. Random link errors, wireless interference and congestion overflow are different problems. If full queues are causing packet loss, increasing the sending pressure may make things worse. Descriptions such as “suitable for lossy networks” indicate a potential use case, not a guarantee that the protocol will fix every network issue. Check how your apps perform and whether other devices are affected at the same time.

How TUIC handles connections and datagrams

TUIC also carries proxy traffic over QUIC connections, with its own approach to connection reuse and datagram forwarding. It can suit scenarios that need different app traffic to share a connection, provided the current network allows the required communications and the client supports the features. Hotels, offices and public networks may handle UDP differently, limiting session duration or preventing connections altogether. In that case, trying another available transport is more useful than repeatedly restarting the same connection.

When a device switches from Wi-Fi to mobile data, QUIC connection IDs provide a technical basis for handling path changes. Whether a session actually survives still depends on the client, server and how the operating system handles the network transition. The app may also have to reconnect when its address changes. A protocol's support for migration doesn't guarantee that you won't lose your connection. Test it during real network switches and after the device wakes from sleep rather than checking only whether a stationary connection can load a website.

Keep a working fallback

QUIC-based options are worth comparing on suitable networks, but they don't need to cover every situation. Travel, commuting and office use involve different access conditions, so you can keep another transport actually offered by the service as a fallback. After switching, verify the app you need rather than relying only on the client's connected status. If your device can't read a protocol entry, update to a supported client or use a compatible configuration instead of uploading your subscription to an unknown website for conversion. The benefits of a protocol depend on full compatibility and a configuration you can maintain.

Direct, relay and dedicated routes: how topology affects performance

A direct route isn't necessarily the shortest geographic path

A direct route usually means your client connects to the selected remote entry point without an extra relay node arranged by the service. “Direct” describes the service topology, not a guarantee that network operators will take the shortest route on a map. Peering arrangements, routing policies and how the destination network connects can all cause detours. A closer region isn't always more responsive, and entry points in the same region may perform quite differently because they use different access networks.

A direct route is easy to understand and has no extra service-side relay, but its quality depends more directly on the path from your local network to the remote entry point. If that segment gets congested at busy times, changing the encryption method usually won't help. First compare other entry points using the same protocol and see whether the issue is specific to one direction. If all remote entry points slow down, check your local Wi-Fi, broadband usage and access network before drawing conclusions.

A relay adds a hop, but may improve the overall route

A relay inserts a forwarding node between the client and the final exit, using a more suitable entry point to connect to the rest of the route. It adds a processing step but may avoid a poor peering segment, so “more nodes always means slower” isn't true. The result depends on how reachable the entry point is, how stable the link from relay to exit is and whether the relay has enough capacity. A relay alone doesn't guarantee quality; the route combination and network operations are what matter.

When troubleshooting a relay route, assess the entry and exit segments separately. A quick connection to the entry point doesn't mean traffic will reach websites smoothly after the relay. If the connection is up but sites in one region are generally slow, compare different exits. If connections to all exits fail before they are established, the issue is more likely with the entry point or local access. Identifying the stage where the problem occurs is more useful than simply reporting “the relay doesn't work” and reduces back-and-forth with support.

What an IEPL dedicated line does—and doesn't—tell you

IEPL generally refers to an international Ethernet private line service provided by a carrier, but a route label doesn't describe every segment from end to end. Your home network to the entry point, the private-line segment and the exit to the destination each have their own conditions. A dedicated line may improve backbone transport, but it can't eliminate local wireless interference, destination-side rate limits or exit congestion. Understand the type of route the label refers to; don't read it as a promise of fixed performance for every app at all times.

Choose an exit region that suits the service

The exit region determines the network location a destination service sees, but doesn't automatically change account ownership, content rights or payment eligibility. Business systems may work best with a consistent region, while streaming content is subject to both account and licensing rules. Frequent region changes may also trigger extra verification in an app. If your current region meets your needs, compare route types within that region first. This makes it easier to separate changes in performance from changes in service rules.

VPNDP covers 110+ countries / 230+ routes. Coverage gives you more regions to choose from, but isn't a measure of an individual route's quality. See all routes for available regions and route types, then test the connection with your target app. For work or study services you use regularly, keep a suitable primary route and a compatible fallback. You don't need to change exits every day just to use more regions; a consistent data path is often easier to maintain than constantly trying unfamiliar routes.

When comparing routes, note the network you're using too. A relay that works well on home broadband may not suit a hotel network, and results from a desktop on wired Ethernet don't necessarily apply to a mobile device on the go. Save the protocol, entry point and exit as a complete combination. Recording only the country leaves out important details; the next time something goes wrong, you may mistake different routes for the same one and draw the wrong conclusions about stability.

Packet loss and peak-hour slowdowns: find congestion instead of rerunning speed tests

Packet loss can happen at different points

Data may fail to arrive as expected because of wireless interference, overloaded queues on network equipment, a path change or restrictions on certain types of traffic by an intermediary. Each cause calls for a different response. Improve local connectivity to address wireless interference, reduce contention or change routes to deal with queue congestion, and consider another transport offered by the service if the traffic type isn't supported. A single client timeout can't tell you where packets were lost, and doesn't prove the remote service is unavailable.

Some devices deprioritize probe packets or don't respond to them, so a failed probe doesn't necessarily mean application data is being lost. Conversely, a stable probe result doesn't mean large transfers will work smoothly; probes may never hit the bandwidth bottleneck. Look at what happens in your apps: choppy audio, video buffering, file retransmissions and slow first-page loads each reveal a different part of the picture. Speed tests can help, but they shouldn't be the only measure of connection quality.

Why performance fluctuates more at peak times

At busy times, more users and apps compete for limited link capacity. Congestion may occur at a home router, access network, carrier peering point or service exit. As queues build up, data may keep flowing while latency increases, making interactive apps feel sluggish first. More severe congestion can eventually cause packet loss and dropped connections. That's why downloads may still make progress while a video call has already become choppy: each type of traffic responds differently to latency and jitter.

Cloud sync, system updates and large uploads on a home network can cause symptoms similar to peak-hour congestion. When upload capacity is saturated, even the acknowledgements and control data other connections need get stuck in a queue. Before troubleshooting, pause nonessential background transfers, check whether other devices are busy and then compare routes. If local contention is still present, switching remote protocols may only change the traffic pattern temporarily; it doesn't prove the actual bottleneck has been fixed.

Change one variable at a time

First record what happens on the same device, access network and target app. Then try another route in the same region and see whether the issue follows the entry point. If changing routes clearly helps, compare their topologies. If the results are the same, change the access network to check the local path. Only then consider protocol compatibility. Change one thing per test so you can explain the result, instead of changing several settings and ending up with a vague, hard-to-reproduce “it seems better.”

Test with tasks that match your real use. For office work, check document saves, file uploads and meeting recovery. For video, check continuous playback and how quickly it resumes after seeking. For development, check repository connections, package downloads and remote sessions. A single public speed-test target may tell you more about the relationship between that target and the exit than about your everyday apps. If only one website is slow, consider its server, content delivery and account conditions before assuming the whole route is at fault.

Change settings only to address a specific issue

Connection timeouts, path MTU, datagram size, connection reuse and congestion control can all affect performance, but they're not general-purpose speed switches. An MTU mismatch can sometimes make certain pages or larger transfers fail, though similar symptoms can have other causes. Change a setting only when the error pattern and comparison results support that direction, and keep the original value. Blindly copying a set of “optimized settings” usually makes the real issue harder to find.

If the issue is reproducible and affects multiple apps, open a ticket through the user panel and provide a concise summary. Note whether other routes work, whether changing access networks helps and whether the error occurs during DNS resolution, connection setup or ongoing transfers. Don't send a full configuration containing credentials, and you don't need to run repeated large data transfers to prove the issue. A clear comparison of variables is more useful than a pile of scattered screenshots and gives you a record to review later.

Platforms and battery use: consider the full load on your device

Protocol overhead isn't the whole battery story

Battery use depends on the processor, wireless connection, screen and app activity. Proxy encryption and data encapsulation add work, but background transfers, retries on a weak wireless signal and frequent network wake-ups can have an even bigger impact. You can't predict battery use simply by checking whether a protocol uses TCP or UDP. One option may avoid connection failures but process more data; another may require less computation but reconnect frequently on an unstable link. The actual battery impact can be the opposite of what you expect.

Processor use also depends on the client implementation, encryption acceleration, concurrent connections and packet handling. A desktop's spare capacity may not be available on a lightweight mobile device; increased temperature can also affect sustained performance through system scheduling. So compare protocol resource use only with the device and workload clearly specified. This page doesn't rank protocols by battery use without that context or treat a brief temperature change as evidence of a general problem with one protocol.

How traffic handling affects what you observe

A system proxy usually affects only apps that follow the relevant settings. A virtual network interface can capture more traffic, but needs extra routing, DNS resolution and packet processing. Even on the same route, the client may do different amounts of work in these two modes. If an app isn't going through the proxy, that doesn't mean the route is broken. Higher battery use after enabling broader traffic capture may simply mean traffic that previously bypassed the client is now being processed. Standardize the traffic coverage before comparing results.

Mobile background policies and keeping connections alive

Mobile operating systems may restrict background activity when the screen is locked or resources are low; clients may also send keepalives to maintain sessions. Sending them too often can wake the device more; waiting too long may let network equipment close the connection. Follow the settings supported by your client and service rather than applying a one-size-fits-all value. If the connection drops after the screen locks, first check whether the operating system is restricting the client, then check network changes and session recovery. Don't assume the remote route stops working in the background.

On Android, check the app and battery settings provided by your device, but note that menus vary. Change only the permissions the client needs; you don't have to remove restrictions for every app. iOS relies more on the lifecycle of system network extensions and app behavior, so desktop-style always-on assumptions don't apply. For step-by-step setup, see Set Up a VPN on Android From Scratch. This section explains why background restrictions can affect protocol testing.

Compare similar workloads, not momentary resource readings

When comparing resource use, keep screen state, access network, background tasks and target app as consistent as possible. Video playback and idle standby aren't the same workload, so their battery drain isn't directly comparable. First confirm that the app works, then check whether the connection is repeatedly being reestablished, the device is getting unusually hot or recovery is smooth. Higher processor use during a large transfer may be normal. If the client stays busy while idle, check for routing loops or repeated retries.

VPNDP supports Windows / macOS / iOS / Android / Linux, with unlimited simultaneous devices. Protocol support and available resources can still vary between devices. Use a suitable configuration on each desktop or mobile device; they don't all have to match. Find client downloads in the user panel. Sign in to get your subscription; access to installation packages depends on your plan being active. A clear, supported setup is usually easier to maintain than adding more background tools.

Choosing a setup: work backward from the target app to your configuration

For work and AI tools, prioritize session continuity

Remote work, online documents and AI tools often involve logins, short requests, long responses and file uploads. They need more than a homepage that loads; interactions must keep working. First fix the region your work requires, confirm the account conditions and service coverage, then compare response times, long-lived connection stability and upload recovery. If pages load but long responses get interrupted, check connection continuity and the service's status rather than choosing a route solely by homepage load time. For more on app-specific considerations, see the AI Tools access guide.

Keep your everyday work setup as consistent as possible. Keep a primary route that works and a compatible fallback actually offered by the service. If something goes wrong, try another route in the same region before deciding whether to change protocols. For services that require a fixed region, don't switch straight to an unfamiliar exit; that can mix network issues with account verification. Schedule background sync and large transfers around interactive work where possible so local bandwidth contention isn't mistaken for an unstable remote protocol.

Streaming and travel call for different considerations

For streaming, focus on sustained throughput, buffering recovery and the platform's regional rules. Confirm your account and content eligibility, then test playback; a brief download peak doesn't guarantee smooth streaming. This page doesn't make per-route content availability claims for VPNDP. For travel, keep a compatible fallback in mind: hotel networks may require access authentication, and public networks can have different traffic policies. Authenticate on the local network first, then connect through the proxy. This avoids mistaking an internet connection that isn't ready for a subscription problem.

Before you leave, install the client, import your subscription and confirm that you can sign in to the user panel. VPNDP doesn't require an email address to create an account; a username and password are enough. Keep your account credentials safe. Don't wait until you need to work to look for an installer on an unfamiliar website. For advice on hotel networks and short-term data needs, see VPNs for Business Travel: A Setup and Preparation Checklist. Its practical steps complement the technical guidance here.

Data plan and protocol choices serve different purposes

Choose a plan based on how much data your apps use, not the protocol name. VPNDP monthly subscriptions 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 by the remaining days. Data packs are ¥158/300GB, ¥358/1000GB and ¥658/3000GB; they don't expire and remain available until used. See the plans page for full pricing details. Protocol overhead, background sync and app retries can all affect usage, so don't estimate it from file sizes alone.

Payment methods: Alipay / WeChat Pay / USDT. The refund offer is a 30-day money-back guarantee; see the refund policy for the application rules. These service terms and protocol performance are separate considerations: a larger data allowance doesn't change how your network routes traffic, and changing protocols doesn't alter your plan's billing period. Check how often you use the service and how much data you need, then choose a connection setup for your access network. This keeps billing questions separate from technical ones.

Follow a repeatable verification sequence

In practice, first check that your local network works and your subscription is active. Then make sure the client has loaded its configuration. Choose a route for the region your work requires and test login, content loading and ongoing interactions in the target app. If something fails, categorize it in order: DNS resolution, connection, security negotiation, authentication or ongoing transfer. Change only one route or protocol setting at a time and record the result. A client showing “Connected” is the starting point, not proof that the app works.

Once everything works, keep your primary configuration and a necessary fallback; there's no need to run speed tests constantly. Recheck the relevant stage if your access network, device operating system or target app changes. No protocol can eliminate every congestion, compatibility or service restriction, and no route label replaces testing with the actual app. The goal is a data path you can understand and recover on your current device. To revisit the setup steps, return to the quick-start guide; to check specific regions, visit the network page; or submit a clear issue report through the user panel if you need help.