Protocol and Routing: A Technical Reference

Connection Layers and Diagnostic Boundaries

Break a connection into steps you can check

When you open a web page, the app first identifies the destination, then passes data to the operating system's network stack. With a proxy client enabled, some or all connections may follow its rules, pass through your local network to a service entry point, and then reach the destination through an exit server. DNS resolution may happen locally or be handled remotely by the client, depending on its mode and rules. A page failing to load does not necessarily mean the protocol is broken. DNS, routing rules, entry-point reachability, the remote exit or the website itself could all be responsible. Start by identifying which layer the request reached rather than cycling through similarly named routes.

Protocols, transports and routes are different things. Names such as Shadowsocks and Trojan describe how data is encapsulated, authenticated and forwarded. TCP and UDP describe the underlying transport; direct, relayed and dedicated routes describe the network path. The client is another layer: it determines which subscription fields a device can parse, how it handles network traffic and how it reports errors. The same protocol can perform very differently over different routes, while the same route can behave differently across clients because of system permissions or implementation details. Record these variables separately before comparing results, so you don't attribute every difference to the protocol.

Separate connection setup from ongoing data transfer

Connection setup is the process from the initial request to the point where application data can be exchanged. It can involve DNS resolution, a transport handshake, authentication and, in some cases, encryption negotiation. Ongoing transfer happens after setup and depends on congestion control, packet-loss recovery, window size, device processing power and the destination service's response. Short requests in chat apps tend to reveal setup overhead; large downloads are more likely to expose throughput limits. A setup that loads a page quickly won't necessarily download files faster. Conversely, a smooth download doesn't prove that reconnections after a network change will be quick.

Latency, jitter and throughput are also distinct. Latency is the time a request and response take; jitter is how much that time varies; throughput is the rate at which data can be transferred over time. Video buffering can absorb some jitter, while remote desktops may show it directly as lag between mouse input and screen updates. A probe result in a client usually reflects a particular target and test method, not the complete process of loading a website. A shorter response time in the list is only a clue; verify the result with the apps you actually use.

Compare under the same conditions, not by protocol rankings

For a meaningful comparison, keep the device, network, destination service, operating mode and time of day as consistent as possible. Change only one protocol or route variable at a time, and note whether the connection succeeds, the first response feels smooth, the session stays up and the device gets noticeably warm. If you need logs, look for categories such as DNS resolution failures, handshake failures, certificate errors and connection timeouts; there's no need to share full logs. Logs, subscription links and account identifiers may contain sensitive information. Redact credentials before contacting support and include only the details needed to diagnose the issue.

If you haven't imported a subscription yet, read How to get, import and update a subscription link. A successful import only means the client can read the configuration; it doesn't prove every connection is using the selected exit. To verify the route, compare the client's activity log, the app's actual response and any change in your public exit location. This method works on both desktop and mobile, and provides the basis for the protocol and route comparisons that follow.

Design Trade-offs of Common Protocols

Shadowsocks: lightweight forwarding and client compatibility

Shadowsocks is a family of encrypted proxy protocols that typically handles authentication, encryption and forwarding with a relatively lean design. Its security depends on the protocol generation, encryption method and client implementation. It can carry TCP traffic and also supports UDP forwarding, but client support, server configuration and local network conditions all need to line up. Don't choose based on the name alone; check that your current client supports the method in your subscription. If the client reports an unsupported cipher after import, that's a compatibility issue. Update to a supported client or use another compatible configuration provided in the user panel instead of removing authentication fields yourself.

Lightweight doesn't automatically mean lower battery use on every device, and it doesn't make other settings irrelevant. Hardware acceleration, connection count, DNS handling and the system's traffic-routing mode all affect resource use. For everyday browsing and documents, a complete configuration with a mature implementation is often easier to maintain than adding layers of encapsulation. Apps that require UDP need separate testing; a web page loading successfully doesn't prove that voice or real-time data will work. When a subscription provides valid settings, keeping the original configuration is usually more reliable than assembling one from scratch.

VMess: authentication and system time

VMess has its own authentication and data-protection mechanisms, and connection behavior is also affected by the outer transport configuration. When reading a configuration, distinguish the protocol itself from additional transport settings such as TLS and WebSocket. A client that recognizes VMess may not support every combination. If the device clock is significantly out of sync, some authentication flows may fail. For authentication errors, first check automatic time settings and whether the configuration is still valid. There is no universal time tolerance: implementations, service settings and protocol handling vary.

Trojan and VLESS: distinguish authentication from encryption

Trojan typically uses TLS to protect the connection, with authentication and proxy forwarding handled inside the encrypted channel. Certificate verification is essential: the certificate domain, validity and trust chain must meet the client's expectations. If you see a certificate error, check the system clock and whether the subscription has expired or been modified, then get a valid configuration from the user panel. Permanently disabling certificate verification to make a connection work weakens server identity checks and can hide the real configuration issue. A shared protocol name doesn't replace correct certificate and transport settings.

VLESS focuses on a lean authentication and forwarding framework and does not encrypt payloads on its own. Common deployments rely on an outer secure transport to protect data. Assess security using the complete configuration; fewer protocol fields do not mean every setup offers the same protection. Likewise, extra encapsulation does not necessarily improve reliability. It can add negotiation, client compatibility and maintenance overhead. Server-provided transport settings work together as a configuration. Changing the domain, path or security settings at random may prevent the entire connection from being established.

There is no universal ranking for these protocols outside the environment they're used in. For long-term use, client compatibility, a complete server configuration and understandable error messages usually matter more than a protocol's popularity. If regular browsing works but one app fails, check its routing rules and requirements before assuming the protocol lacks support. If every app fails during the handshake, check the configuration, device clock, certificates and entry-point network. Troubleshooting by failure stage reduces unnecessary switching and gives you a clear baseline for comparing TCP and QUIC-based options.

When to Use QUIC and UDP: Conditions

UDP isn't inherently unreliable, and QUIC isn't free of overhead

UDP provides datagram transport, unlike TCP, which gives applications an ordered, reliable byte stream. Protocols that need reliable delivery can implement acknowledgments, retransmission and congestion control on top of UDP. QUIC is a transport protocol that builds secure connections and stream management over this kind of transport. When discussing Hysteria2 or TUIC, don't assume that using UDP means application data will be lost, or that it guarantees higher speed. Reliable delivery still requires state tracking and recovery, which use processing resources; it also depends on whether the network path allows UDP.

QUIC's independent streams can reduce blocking between streams caused by ordered delivery, but packet loss can still affect the congestion window and shared bandwidth. Missing data within an individual stream still needs to be recovered. So, “avoids head-of-line blocking” doesn't mean “packet loss won't affect performance.” The proxy implementation's mapping of internal connections to outer streams, connection reuse and datagram handling can also change the result. Understanding the transport helps explain what you see, but it doesn't replace testing the specific client and server combination.

Hysteria2: congestion control and bandwidth settings

Hysteria2 is based on QUIC, and connection performance depends on the congestion-control strategy, path quality and configuration used by the implementation. Some configurations include bandwidth settings. These should reflect sustainable network capacity, not an ideal peak. Settings that don't match actual conditions can increase queueing and packet loss or make other apps less responsive. If the server generated your subscription configuration, use its settings by default. If you need to adjust something, record the default behavior first and change one setting at a time rather than modifying several parameters at once.

On paths with noticeable packet loss, some transport strategies may improve sustained transfers, but no approach works better on every network. Switching to Hysteria2 won't fix local Wi-Fi interference, an overheating device or a slow destination service. Another common case is that web browsing works but a candidate connection over UDP can't complete its handshake. Check how the network handles UDP, test over another network and keep a verified TCP-based option as a fallback.

TUIC: connection reuse and implementation matter

TUIC also uses QUIC to carry proxy connections and includes mechanisms for authentication, stream forwarding and UDP handling. It may reduce repeated outer-connection setup through connection reuse, but the benefit depends on how you use it. Frequent short connections and a single long-lived session have different connection-management needs. Configuration fields, authentication methods and compatibility requirements can also change as implementations evolve. Don't mix and match snippets from different sources. If you see an unsupported field or authentication failure, check the user-panel configuration and supported clients instead of guessing what each parameter means.

During a mobile network change, QUIC connection IDs and path migration are designed to make it possible to keep a session alive, but the proxy implementation, server settings and system network extension may not fully support migration. You may still need to reconnect, and the app itself may ask you to authenticate again. When evaluating a QUIC-based option, test stationary use, network switching and recovery after the screen turns off separately. Don't generalize smooth performance in one situation to every use case. If the client only reports a generic timeout, compare different network connections before deciding whether the issue is protocol compatibility or an unreachable path.

Connection Speed and Resource Use Compared

Identify which stage is adding overhead

Connection setup overhead can come from several steps: DNS resolution, the round trip to the entry point, transport negotiation, encryption and authentication, and the connection from the exit to the destination service. Reusing an existing connection can reduce some of these steps; starting the client, changing networks or letting a session expire may trigger them again. When checking page-load speed, distinguish the first visit from repeat visits and account for browser caching. If one option has already warmed up while another is just establishing a connection, the comparison isn't fair. You don't need elaborate testing tools; consistent conditions are often enough to rule out common mistakes.

Ongoing resource use mainly comes from encryption and decryption, data copying, interaction between the system and user space, connection state management and retransmission. Hardware acceleration for a particular cipher may let a seemingly more complex secure transport run more efficiently. On the other hand, global traffic routing can send many background requests through the client and increase total load. If a device gets noticeably warm, first check actual data use, background syncing and the client's operating mode before blaming the protocol. A process name or a one-off CPU reading doesn't reveal long-term efficiency.

More connection reuse isn't always better

Connection reuse lets multiple internal requests share an outer connection, reducing repeated handshakes, but it also makes those requests share some connection state and path resources. If the outer connection is congested or unstable, several apps may be affected at once. Reuse mechanisms handle reliable streams and datagrams differently, so you can't infer everything from a setting's name. If the default is stable, there's usually no need to enable more complex reuse for a theoretical benefit. If short connections are slow, compare the default and adjusted settings on the same route, and check that long-lived connections haven't become less reliable.

Log verbosity can also affect resource measurements. Keeping detailed debug logs on for a long time may increase disk writes and processing load, while accumulating account and browsing information. For diagnosis, follow the client's instructions to enable more detailed logs temporarily, then restore your usual settings once you have enough information. Memory use shown by system monitors may include caches and connection tables; it doesn't necessarily indicate a leak. More useful signs are continued growth under the same workload, memory that doesn't fall after the task ends, or a visibly sluggish system. If you see these, share a redacted description of your setup with support.

State your findings with their conditions—for example, “On this device and Wi-Fi network, this route works better with the same app”—rather than claiming one protocol is best overall. If you keep notes, record the device platform, client source, network connection, target app and failure stage; don't add speed figures you haven't measured reliably. These notes make it easier to troubleshoot after network conditions change and help support determine whether the issue lies with the client, local network or remote path, instead of repeating trial and error based on popular protocol names.

Direct, Relayed and Dedicated Routes

Route labels describe the path, not a guaranteed experience

A direct route usually means the connection from the client to the remote service entry point doesn't pass through an additional relay arranged by the provider. It doesn't mean there are no routers along the physical network path or that the route is always the shortest. Carrier interconnection, egress policies and the return path all affect detours and congestion. A geographically closer region can be a useful starting point, but map distance alone isn't enough to draw conclusions. Different entry points in the same region may connect to different networks and perform differently. The key is to look past the label and consider your current network and actual destination.

A relay adds a forwarding step between the client and the final exit. It may replace a difficult-to-control route with more manageable segments, or add overhead through the relay's location, forwarding load or extra detours. More hops don't always mean slower, and fewer don't always mean more reliable. If your local network has a good connection to the relay and the path beyond it is strong, the overall experience may beat a direct route. But congestion at the entry point can affect every exit that uses it. When troubleshooting a relayed route, distinguish entry-point issues from exit-path issues.

Assess a dedicated route against the actual bottleneck

A dedicated route usually means that a particular section uses more controlled transport resources; IEPL is a common route label of this kind. It can change conditions on that section, not every part of the end-to-end path. Your local Wi-Fi, home router, device and destination website still have their own limitations. Even with stable international transport, packet loss on the local connection can still make apps lag. First check whether the issue is concentrated on the international segment, then see whether a dedicated route covers that bottleneck. Don't read “dedicated” as a promise of consistent speed across all apps and times.

Match the exit region to the destination service

When accessing international websites, the path from the exit server to the destination also matters. A fast response from an exit to your device doesn't mean it's close to every website. Content delivery networks may choose a server based on the exit IP and DNS location; account region, platform policies and deployment locations can also affect results. AI tools, video platforms and remote-work systems don't all have the same requirements. Choose an exit that meets the destination service's regional requirements first, then compare routes in that region. Don't simply pick the shortest probe time and assume it works best for every app.

Outbound and return traffic may take different routes, which is one reason a connection can work while transfers remain unstable. Route observations from the client cover only part of the journey and can't fully show where the remote response travels. If several exits using the same entry point fail at once, check the entry point and local network first. If only one exit has trouble with a specific service, look at the path from that exit to the destination and the service's policies. Grouped comparisons narrow the problem more effectively than randomly changing regions, without assuming every issue is caused by peak-time congestion.

VPNWD covers 120+ countries and 170+ routes. Check the Servers and routes page and user panel for specific regions and available configurations. Broad coverage gives you more options; it doesn't mean every region suits every task. For everyday use, keep a verified primary route and a backup that uses a different path. A backup is useful when it provides an alternative route—not when you repeatedly switch between options with similar names that share the same entry point. Record both protocol and topology to see the difference.

Packet Loss and Peak-Hour Congestion Troubleshooting

First distinguish congestion, interference and delays at the destination

Congestion usually occurs when more data enters a network segment than it can forward promptly. Queues build up, increasing latency, and packets may be dropped when the queues fill. You might see downloads continue while page clicks, voice calls and remote controls all become sluggish. Peak hours can expose competition for shared capacity, but they don't explain every problem that happens at night. A busy destination website, local Wi-Fi interference or a background backup can produce similar symptoms. Start by checking whether the issue changes with the app, device or network connection.

Packet loss isn't always caused by congestion. Wireless interference, roaming between access points, route changes, interface errors or packet sizes that don't fit the path can all delay or prevent delivery. Reliable transports try to recover missing data, but recovery takes extra time and bandwidth. If you experience brief interruptions, check whether they coincide with a network switch or signal change. If other devices in the same location are affected too, investigate the local network first. If only one client is affected, check its permissions, configuration and operating state.

Narrow it down from the local network to the entry point to the destination

Pause background tasks that use the network and check whether regular browsing is affected too. On Wi-Fi, try a location with a stronger, more stable signal; if possible, compare using a wired connection on a desktop. Next, keep the target app the same and compare entry points or route topologies to see whether the issue follows a particular route. Finally, compare different destinations through the same exit. The point isn't to collect complex data, but to isolate variables step by step: a local network that works, one failing entry point among several, and a single website failing across every route all point to different causes.

Don't treat a single probe timeout as proof that application data is being lost. Some devices give probe packets lower priority, and some intermediate network nodes don't respond to those requests. A silent node in a route trace doesn't prove that it is consistently dropping app traffic if later destinations still respond normally. More useful signs are interruptions in the app itself, retransmission-related errors and whether the issue repeats under the same conditions. If you use system diagnostic tools, keep the full output for troubleshooting rather than drawing conclusions from the most noticeable timeout line.

Packet size and the limits of DNS troubleshooting

Tunnel encapsulation uses some of the available transmission space, and different paths may support different packet sizes. If path MTU discovery isn't working properly, small requests may succeed while larger transfers stall. Client settings such as MTU can matter, but copying a fixed value from the internet can create new problems. Start with the client's default settings and switch networks to see whether the issue follows a particular path. Make changes only in line with official instructions or support advice. Afterward, test regular browsing, file uploads and long-lived connections so a fix for one app doesn't break others.

DNS problems can show up as domains that won't load, slow resolution or connections to an unsuitable service location. If a domain doesn't resolve, changing the transport protocol may not help. Check the client's DNS mode, which rules handle the domain, and whether other network-filtering tools are active on the system. Disabling all routing rules isn't necessarily the right answer: it changes the path for many requests and can make the original issue harder to reproduce. Back up the configuration, review activity for the affected domain and make targeted changes. Never share raw account or subscription data publicly.

Change protocols only after checking the path. If TCP-based connections remain impaired over the same route, and UDP is reachable and supported by your client, test whether a QUIC-based option improves the task. If every option fails on the local network, fix the local connection first. Once service is restored, keep the findings that hold up; there's no need to leave every temporary test setting in your configuration. A solution you can explain, reproduce and roll back is better for long-term use than a pile of unverified tweaks.

Platform Differences and Mobile Battery Use

Battery use depends on wakeups, transfers and recovery

Mobile battery drain isn't just about encryption and decryption. An active wireless radio, background keepalives, frequent reconnects, DNS requests and log writes can all prevent a device from entering a lower-power state. It's normal for an active transfer to use more power. Pay closer attention if the device gets noticeably warm when you're barely using it, or keeps opening connections with the screen off. Check background sync, automatic speed tests and connection keepalive settings before blaming a protocol. Reducing unnecessary activity is often more effective than looking for the theoretically lightest encapsulation.

When the wireless signal is weak, the system may use more power to maintain the connection and retransmit data; a moving device may also switch networks repeatedly. QUIC-based options can reduce transfer delays on some paths, but their processing and keepalive behavior can add work too. TCP-based options may also cause extra wakeups if they disconnect and reconnect frequently. To compare battery use, keep screen brightness, app activity and signal conditions similar, then check the system battery records during actual use. A short-lived process reading doesn't predict long-term battery life.

System network extensions affect background behavior

On iOS, related connections typically run through a system network extension, and background operation and resource use are managed by the system. A connected status doesn't guarantee that every app request is routed as expected; check the rules, DNS and network extension state. Android background limits, battery optimization and device-specific system policies can also affect client recovery. If the connection drops when the screen turns off, first check whether the system is restricting the client's background activity, then follow the client's official instructions. Don't grant every app unrestricted permissions just to keep a connection alive; change permissions only when they're relevant to the issue.

Check traffic-routing mode on desktop devices

On Windows and macOS, the system proxy usually affects only apps that follow those settings; traffic-routing modes may cover more connections. If a browser works but a standalone app doesn't, they may be using different paths rather than the protocol lacking support for that app. On Linux, terminal environment variables, desktop proxy settings and routing configuration may also be independent. First confirm whether the app's traffic reaches the client, then check the remote connection. When multiple proxies, virtual networks or security filters are active, routing and DNS conflicts deserve particular attention.

Test recovery from sleep and network changes as separate scenarios. After a device wakes, the original connection may still appear active even though the underlying path has changed, and the app may keep an expired session temporarily. Try reconnecting in the client, then reopen the affected app to distinguish tunnel recovery from app recovery. If you have to restart the entire device every time, collect logs to check the network extension or system service rather than making restarts part of your routine. Back up the configuration and avoid installing multiple network tools with overlapping functions.

VPNWD supports Windows / macOS / iOS / Android / Linux, with no limit on the number of devices online at once. Each device can use a mode and route suited to its platform; there's no need to force the same protocol everywhere. Download clients from the Downloads section of the user panel. Sign in to access your subscription; available installers depend on your active subscription permissions in the panel. For a first-time desktop setup, follow the Windows setup and verification guide, then use this chapter to account for platform differences.

Choose a Protocol and Route for Your Use Case

Web browsing, AI tools and long-lived connections

For everyday browsing and documents, start with a complete configuration, a compatible client and a reliable connection setup. Keep the default settings, choose an exit suited to the destination region, and check both the first page load and continued use. AI tools often stream responses over a connection that needs to stay open, and access can also depend on account eligibility, service regions and platform policies. If a page loads but a conversation won't finish, check login status, the request path and the streaming connection separately. An exit change alone doesn't guarantee that the service will work. For more on this use case, see our AI Tools guide.

Remote work and real-time collaboration depend more on jitter, brief interruptions and recovery. A candidate route needs to do more than connect; it should also provide acceptable responsiveness during editing, calls or remote desktop sessions. Video meetings may use more than one transport, so check that UDP forwarding and routing rules meet the app's requirements. If your work system requires an organization-provided network tool, follow your organization's policies and check whether overlapping tools cause routing conflicts. Your provider's protocol choice doesn't replace workplace access controls, and changing credentials or certificates isn't a way to bypass an app's requirements.

What to check when streaming video or transferring large files

For video, first make sure the platform's region and content permissions are met, then check continuous playback, seeking and quality changes. Seeing a title in the catalog and playing it smoothly are separate issues: the first may depend on account and exit-location detection, while the second relies more on sustained throughput and route stability. Don't treat a page load as a complete playback test. For large downloads or sync jobs, check whether sustained transfers slow down interactive tasks. If needed, use the app's own transfer limits to leave capacity for browsing, calls and chat rather than trying to saturate your entire connection.

On mobile paths with noticeable packet loss, test Hysteria2 or TUIC if the client supports them and UDP is reachable. When network conditions change frequently, keep a verified TCP-based option too. A useful backup should differ in entry point or transport path, not just have a different exit label. Save anything you're editing before switching, then check whether the target app needs to reconnect. If a task works only in a particular region, keep the region consistent while comparing routes and protocols; otherwise, a change in regional policy could be mistaken for a change in transport performance.

Build a maintainable configuration you can roll back

Start with the default configuration. Identify the target app and regional requirements, then test connection setup, continued use, recovery after the screen turns off and network changes. If something fails, revisit the connection layers and determine whether the issue is with DNS, the entry point, authentication, the exit or the destination service. Change one variable at a time, record the result and decide whether to keep it. A combination that reliably gets the job done is a good primary setup; there's no need to rebuild it repeatedly to chase new protocols. If a subscription update changes configuration fields, use the client's supported update method rather than keeping expired authentication details by hand.

Choose a plan separately from a protocol. VPNWD monthly plans: ¥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 add-ons cost ¥158/300GB, ¥358/1000GB and ¥658/3000GB; they remain available until used and never expire. Choose based on your usage and habits, not the protocol name. See Plans and pricing for details. VPNWD accepts Alipay / WeChat Pay / USDT and offers a 60-day no-questions-asked refund. No email address is required; create an account with a username and password.

For long-term use, keep your configuration understandable. If the primary route has a problem, switch to a backup to resume your task, then investigate using the same destination and network connection. Once the issue is resolved, remove temporary changes that aren't supported by evidence. If you need help, share a redacted description of the client setup and failure stage; never post your subscription link publicly. When you're done, return to the Guides to review installation and verification, or visit the Servers page for region and route details. Protocols are just transport tools; the final measure is a connection experience you can understand and verify.