Proxy Protocols and Routes Explained

A framework for choosing a protocol

Consider the app, protocol, and route separately

A typical connection involves several stages: the local app, client rules, proxy transport, access route, and destination service. When an app sends a request, the client first decides where to route the traffic, then communicates with a server using the selected protocol, and finally connects to the destination. A delay at any stage can make a page appear to hang. So if switching protocols makes a connection faster, that only shows that this particular combination changed the result; it does not prove that the protocol is always faster. Different subscription entries may also use different ingress points, egress points, or transport encapsulation. Before comparing them, check whether those conditions match as closely as possible.

A protocol defines how data is organized, authenticated, and transmitted. Route topology describes the network path the data takes. The difference between Shadowsocks and Trojan is not the same as the difference between a relay and a dedicated route: the same protocol can run over different routes, and one route can carry different protocols. A client’s “node” is often a label combining these details, not a complete description of a single device. When evaluating an option, note the region, route type, protocol, client, and network in use. That makes it easier to identify what actually changed.

Connection setup and sustained transfers are different metrics

Connection setup covers the time between requesting access and receiving a valid response. It may include DNS resolution, transport connection setup, authentication, and a security handshake. Sustained transfers measure whether data continues to arrive smoothly after the connection is established. A page opening quickly does not guarantee uninterrupted video playback, and a fast download does not guarantee responsive remote-terminal input. Browsers may reuse existing connections, bypassing some setup steps. Record first-time and repeat visits separately; a cached response does not measure protocol handshake performance.

Resource use also depends on what you measure. A client uses CPU and memory to handle encryption, protocol encapsulation, rule matching, and virtual network interfaces. Wireless retransmissions and frequent keepalives can also affect battery life. High resource use may come from many concurrent connections, complex rules, or background downloads—not necessarily the protocol itself. Keep app activity similar when comparing idle, browsing, and sustained-transfer states. A single task-manager screenshot rarely explains long-term battery drain or device heat.

Set the conditions before comparing

For a useful comparison, keep the device, client, network connection, and destination service as consistent as possible, then change only the variable you want to test. If you change the Wi-Fi network, node region, and protocol at the same time, even a clear improvement will not tell you what caused it. Start with a route that works, note its name and rule mode, then try alternatives with the same app and task. Specific observations—such as “long wait on a cold start,” “buffering during playback,” or “needs to reconnect after resuming in the background”—are more useful than simply saying it is “slow.”

Separate what you can observe from what you infer. A client reporting a successful connection only confirms that part of the route is established; a destination page loading confirms that this particular app request got through. If a node in one region cannot reach a particular site, that does not prove the entire region is unavailable. The destination may respond differently based on the egress address, account region, or session state. VPNHorse covers 90+ countries and 210+ routes; check the panel for the options currently available. Broad coverage gives you more choices, but does not replace testing your actual use case.

Choose in this order: check client compatibility, confirm that your current network supports the transport, compare connection quality for similar tasks, then assess long-term stability and battery use. A protocol name is not a performance guarantee.

This guide offers qualitative comparisons, not an overall protocol score or a fixed ranking independent of route conditions. If you are unfamiliar with advanced settings, keeping the subscription defaults usually makes troubleshooting easier than changing several options at once. If you are an experienced user, keep enough detail to reproduce your reasoning: what you changed, why you changed it, and how to restore the previous settings. That way, you can retest when your network conditions change instead of relying on an outdated label or assumption.

Trade-offs in stream-based protocols

Shadowsocks: focus on encryption and implementation

Shadowsocks is primarily used for proxy forwarding and encrypted transport, and common implementations also support stream and datagram traffic. Its structure is relatively straightforward, but “supports Shadowsocks” does not mean a client can handle every encryption method and extension. After importing a subscription, check whether the client reports unsupported methods, plugins, or fields rather than assuming compatibility from the protocol name. Modern and older encryption methods differ in security design and implementation. Use the parameters provided by the service; do not swap encryption methods yourself just to try to make a connection work.

With other conditions held roughly constant, simpler encapsulation can reduce processing overhead. Actual resource use still depends on the encryption implementation, hardware, and number of connections. For frequent small requests, connection management may matter more than encrypting large transfers; during sustained downloads, CPU and local network interface efficiency may become limiting factors. Shadowsocks datagram support also depends on the server, client, and rules working together. A web page loading does not prove that an app relying on datagrams is supported; test that app separately.

VMess: authentication, time, and transport all matter

VMess combines authentication with proxy communication. Client compatibility depends not only on the protocol name but also on the specific implementation and outer transport. If authentication fails, check whether the subscription has expired or the configuration is incomplete, and make sure the device’s system clock is correct. A significantly inaccurate clock can interfere with authentication or certificate validation. Turn on system time synchronization, then refresh the subscription. Do not keep editing authentication fields just because a connection timed out; manual changes can turn a working configuration into a different kind of error.

VMess can be combined with different transport encapsulations. Extra encapsulation may improve compatibility in some deployment conditions, but can also add handshakes, proxy relays, or connection-maintenance overhead. When comparing implementations, specify which transport is paired with VMess instead of treating every setup as the same. If a client generated the subscription entry, keep its original structure where possible. For everyday browsing and work, a stable connection and reliable connection reuse often matter more than a combination that merely looks more complex.

Trojan and VLESS: know which layer provides security

Trojan typically relies on TLS for transport protection, so server names and certificate validation must be handled correctly. Certificate errors can stem from an incorrect system clock, a server-name mismatch, a problem with the certificate chain, or an incomplete import. They should not simply be dismissed as a slow route. Skipping certificate verification weakens identity checks and should not be used as a routine fix. If the problem persists after refreshing the subscription, keep the error details and submit a support ticket. Do not permanently disable security checks and treat an occasional successful connection as a fix.

VLESS defines authentication and proxy forwarding behavior, but does not itself provide general-purpose content encryption; it needs to be paired with a supported security layer. Seeing VLESS in a configuration does not tell you whether the connection is adequately protected. Check the transport, security settings, and client support as well. Its design is streamlined, but that does not mean the actual route will be faster than other options. If the security layer, route, or server conditions differ, the protocol’s lower processing overhead may not determine the overall experience.

Understanding connection setup and resource use

These protocols often run over reliable stream transports. Reliability means lost data must be recovered, and later data may have to wait until missing data is retransmitted. Security handshakes, outer encapsulation, and connection reuse all affect the wait on a first visit. Compare new connections with requests over existing ones instead of judging from repeated browser refreshes alone. Protocol processing overhead is only one part of the total route cost. If network round-trip time, destination response time, or wireless interference is the main bottleneck, changing protocols may make little difference.

QUIC protocols and datagram transport

What Hysteria2 and TUIC have in common

Hysteria2 and TUIC are both based on QUIC, which relies on UDP for transport. QUIC implements secure connections, reliable streams, and congestion control in user space. It can reduce the way packet loss on one stream holds up delivery on other streams. That does not eliminate packet loss, nor does it make all app traffic unreliable. Reliable streams still need to recover lost data, and connections remain limited by available network capacity. Before choosing either protocol, make sure your current network and client can handle this type of transport.

Some networks handle UDP differently from stream-based transports. A connection may establish but perform poorly, or fail more often after sitting idle. The cause could be the access device, address-translation state, security policies, or traffic management by the network operator; the protocol name alone cannot pinpoint it. If reliable stream-based options work on the same network but QUIC options keep failing, keep one working option as a baseline and test the UDP path. Do not change authentication settings, region, and rules all at once, or you will lose a useful comparison.

Congestion control affects transfers and shared networks

Some Hysteria2 setups involve bandwidth estimates or sending-policy settings. These need to match actual access capacity and server policies. Setting a very high target does not add physical capacity; it can instead make local queuing, packet loss, or retransmissions more noticeable. Implementations may handle these settings differently, so follow the current client documentation and subscription defaults. Unless you have clear evidence of a specific problem, do not override an automatically generated configuration with aggressive settings found online.

TUIC also involves connection management, congestion control, and datagram forwarding. Its performance depends on whether the app uses reliable transport, how the client reuses connections, and which behaviors the server allows. Multiplexing can reduce some of the overhead from setting up separate connections, but the streams still share the same connection state and route capacity. A large background transfer can affect interactive foreground tasks. Support for multiple streams does not guarantee that every task gets its own network resources.

Less cross-stream waiting does not remove capacity limits

With reliable stream transport, missing data can delay the delivery of later content. QUIC tracks delivery state separately for different streams, which can reduce cross-stream blocking. But it cannot remove bottlenecks caused by weak local Wi-Fi, a saturated access link, or a congested egress route. Sending data more aggressively is not necessarily better for interactive tasks, either. Video calls prioritize timely delivery, while file transfers prioritize completeness and sustained throughput; each tolerates queuing and recovery differently.

Connection recovery and network switching need separate testing. QUIC includes support for connection migration, but whether a particular proxy protocol, client implementation, and network can use that capability must be verified. Using QUIC does not guarantee that every app will stay connected when you switch Wi-Fi networks. An app’s own long-lived connections, authentication sessions, and background restrictions may still require a reconnect. When testing, check whether the task resumes and whether the egress and rules are still as expected—not just whether the client icon looks connected.

Evaluate resource use and compatibility together

User-space protocol stacks, encryption, timers, datagram handling, and retransmissions all use device resources. The cost may be negligible on a powerful computer, but can affect battery life and heat during extended use on a mobile device, especially with a weak signal or high temperatures. That does not mean QUIC always uses more power or less power: completing a transfer faster can also shorten the time the device stays active. Compare the same task on a similar network with background activity held constant. Treat resource use as part of your choice, not a guess based on the protocol name.

QUIC is worth considering, but it should not be presented as a must-have for weak networks. First confirm that UDP works on your network, then compare task continuity, recovery behavior, and device resource use.

Direct, relay, and dedicated route topologies

Route labels describe the path, not the outcome

Route topology explains how data travels from your local network to a service entry point, then from an egress point to the destination. The region shown in a client usually relates to the server or egress, but it does not reveal the entire path. Different access networks can take different routes to the same region, and the same entry point can reach different addresses through a destination’s content delivery network. So the same region does not mean the same route, and a closer region does not guarantee a faster end-to-end connection. Judge performance by both entry-point reachability and the destination app’s actual behavior.

A direct route generally means the client connects straight to the relevant service entry point, without an additional service-side relay entry point. Its logical structure is simpler, but data still travels through access networks, backbones, and interconnection paths—it is not a physical straight line from your device to a server. Direct routing can avoid unnecessary detours when interconnection is favorable; under heavy load, it can still experience queues and fluctuations. Assuming that “direct” always means “lowest latency” overlooks routing and congestion along the way.

Relays add a route segment and create more routing options

A relay typically sends traffic to an access entry point first, then uses a service-managed link to reach a later node or egress. This adds a manageable route segment that may improve reachability from your local network or avoid a poorly performing public route. If the relay is poorly positioned, however, the extra distance and processing can add delay. A relay’s value comes from how it organizes the route, not from being inherently better than direct routing. Compare both the stability of the route into the service and the final response from your destination; an entry-point check alone is not enough.

A relay can also become a shared-capacity aggregation point. If several egress options rely on similar access resources and fluctuate at the same time, the cause may be a shared entry point rather than separate failures at each egress. Conversely, if only one destination is affected while other services work, do not assume the relay is at fault. To narrow things down, try different destinations over the same route, then different routes to the same destination. This can help distinguish a shared path, common entry point, or destination-side issue.

Understand dedicated routes by their coverage

A label such as IEPL usually describes a specific section of the route that uses a dedicated line. It does not mean the local Wi-Fi, user access segment, and destination network are all dedicated resources. A dedicated route can be useful for how a particular link is organized and how consistently it performs, but the full connection still depends on the entry point, egress, and destination response. Even with a dedicated-route label, test whether your app works consistently; do not treat it as a guaranteed end-to-end experience. Refer to the panel for current route names and options.

A dedicated route does not necessarily mean dedicated bandwidth. Whether resources are exclusive, whether speed limits apply, and how capacity is allocated all require clear service details; the name alone does not answer those questions. See the Locations page for VPNHorse route listings. Check the user panel for the specific options, types, and supported protocols. Do not pay more just for a more impressive label. Instead, consider whether the tasks you use regularly actually work more consistently, especially during peak hours, long sessions, and office work involving a fixed destination region.

How entry points, egress, and destinations relate

Destination services generally see the egress network address, not the relay entry point’s address. The entry point’s region therefore may not match how a service determines content region; pay attention to egress-related labels when choosing a route. Streaming, AI Tools, and account services may also consider account settings, session state, and destination-specific rules, so egress region alone does not determine access. If content does not change after switching routes, restart the app session and check its rules. Avoid switching egress locations repeatedly, as that adds more variables.

Packet loss and peak-hour congestion

Packet loss is a symptom; find where it occurs

Data can be lost over local Wi-Fi, in queues on access equipment, along an interconnection route, or during remote processing. Loss caused by wireless interference calls for a different response from packet drops caused by insufficient capacity: improve the local connection in the first case; reduce concurrent traffic, change routes, or wait for congestion to ease in the second. A spinning app alone cannot tell you which is happening. Check whether other devices and ordinary local network tasks are also affected, then see whether the issue is limited to a particular route or destination.

When reliable transport encounters packet loss, it has to recover the missing data. This adds delay and may trigger changes in sending behavior. If loss is frequent, the connection can still appear “connected” while useful traffic makes little progress. A video player may hide some fluctuations with buffering, while a remote terminal makes pauses in input immediately obvious. Connection icons and one-off test results are not enough to assess app performance. Describe what you observe at the app layer separately from transport recovery, then decide whether to change routes or investigate the local network.

Peak-hour slowdowns often involve competition for shared resources

During peak hours, home internet connections, network interconnections, service entry points, and destination platforms may all handle more concurrent demand. As requests build up along a route, data may spend longer waiting in queues, slowing page responses and interactions even without noticeable packet loss. The cause is not necessarily limited server capacity; congestion can also happen closer to the user or destination. Compare the same task across different routes and access networks instead of relying on the time-of-day label alone.

Local queues are easy to overlook. Background sync, system updates, or a large upload can saturate your upstream connection, leaving even small requests and acknowledgments waiting behind it. The result can feel like “the download is still running, but web pages won’t open.” Switching protocols may change sending behavior temporarily without resolving the resource contention. Pause heavy transfers and check whether foreground interactions recover. If they do, first adjust local activity or queue management on your router before deciding whether a long-term route change is needed.

Test results and real-world access may differ

System testing tools may use different packets from app traffic, and network devices along the path may respond to test requests differently. A nonresponsive intermediate node does not mean that all app traffic passing through it is being lost. A successful entry-point test also does not prove that a destination service is responding. Treat tool results as supporting evidence, not a final verdict. If a test looks abnormal but your app keeps working, prioritize what you observe in the app. If the app fails while tests succeed, continue checking rules, authentication, and the destination service.

Treat high latency, fluctuating latency, and reduced sustained throughput as separate issues. A long-distance route may always take longer but remain steady; a route with significant queuing may alternate between fast and slow; a destination speed limit may affect only a particular file or account. Calling all of these “slow” makes troubleshooting harder. Describe first-response time, sustained tasks, concurrent activity, and recovery behavior. Avoid submitting speed-test screenshots without context.

Address the bottleneck instead of piling on settings

If several apps fail only on Wi-Fi, start with the local connection. If all devices fail only on one route, compare other routes. If just one service is affected, check egress region, session state, and the destination. For QUIC options, also check whether your current network handles UDP reliably. Do not start by changing advanced settings such as fragmentation, buffers, or sending policies; those changes can mask the original cause and make it harder to reproduce. Keep the subscription defaults as a restorable baseline.

Assess peak-hour stability by repeating the same task under comparable conditions. One successful connection, a single large-file transfer, or one test result cannot prove that a route will perform the same way over time.

If changing routes genuinely improves performance, record the network and task conditions where the improvement applies. Routes may share an entry point, and destination platforms may change how they direct traffic over time, so today’s result should not be treated as a permanent ranking. For frequently used services, keeping a reliable primary route and a backup is more practical than looking for one route that outperforms all others in every situation. For further help, visit the Contact Support page to submit a ticket with reproducible details and comparisons.

Platform differences and mobile battery life

The same protocol can behave differently across clients

A client does more than handle protocol communication. It may also manage DNS resolution, rule matching, virtual network interfaces, and system-wide traffic routing. Even with the same subscription, platform-specific system interfaces, permissions, and background policies can change the experience. VPNHorse supports Windows / macOS / iOS / Android / Linux. Find downloads and subscription options in the user panel. When choosing a client, first confirm that it supports the protocol and transport you need, then consider its rules and your preferred workflow.

A system proxy and a virtual network interface are different traffic-routing modes on desktop systems. Some apps follow the system proxy; others use their own networking. A virtual network interface generally covers more traffic, but is also more likely to interact with existing network software, routing rules, or DNS settings. If your browser works but another app fails, first check whether that app’s traffic reaches the client instead of immediately switching protocols. A client connecting to a server and an app using that connection are two separate things to verify.

Background behavior on mobile affects connection lifecycles

Mobile operating systems schedule apps based on battery, background activity, and device state. Whether a client keeps running in the background, and whether the system lets its related services stay active, can affect reconnection after idle periods. If an app stalls after the screen has been locked for a while but recovers when you reopen the client, check background restrictions and client status before deciding whether the connection needs to be rebuilt. Android power management and iOS system tunnel behavior differ; do not copy setup steps from one platform to the other.

For initial permissions and installation, see the Android VPN setup guide for beginners and the iOS client and configuration profile guide. These steps address whether the system lets the client work properly; they do not rank protocols by performance. If permissions or background behavior are inconsistent, observed disconnects may have nothing to do with the transport. Finish configuring the system, then test candidate routes with the same task for a more meaningful comparison.

Battery use comes from processing and wireless activity

Encryption, decryption, and protocol processing use CPU, but mobile battery life is also affected by the screen, wireless signal, background sync, and app activity. A weak signal can increase wireless transmission and retries, while frequent connection setup can keep the network module active. A protocol that completes a task faster may shorten active time; another that sends keepalives frequently may use more power while idle. You cannot predict overall battery use from the encryption method or protocol complexity alone.

Compare battery use both while idle and during real tasks. First check whether an idle client connection generates noticeable activity; then observe the device while browsing, streaming, or working. Keep screen brightness, other background tasks, and network access as consistent as possible, and note whether the device is already hot or the system is changing its scheduling. The system battery screen can help, but you cannot attribute all app energy use to the protocol: rule updates, subscription processing, and other network tasks may also be involved.

Keepalive, logging, and rule complexity: know the limits

Keepalives can help maintain a connection or detect when it has failed. Both frequent keepalives and none at all have trade-offs: the former can increase idle activity, while the latter may let some network devices drop the connection sooner, requiring a new connection to recover. Most users should keep the defaults and adjust them only when there is evidence that idle connections are the problem, following the client documentation. Enable diagnostic logs only as needed, then return them to the normal level. This avoids irrelevant log output and unnecessary local resource use.

Choose a protocol for your use case

Web browsing and AI Tools: check that requests finish

A typical web page loads multiple resources. First visits depend on DNS resolution and connection setup; later browsing is affected by connection reuse and caching. When evaluating a route, check whether the page content, images, and interactions all load—not just whether the title appears. AI Tools may wait for a response or receive content as a stream. Check whether requests finish, long sessions stay connected, and the account and egress conditions remain consistent. A region label or protocol name does not guarantee that a destination platform will work.

When using tools such as Cursor and Gemini, check the app’s authentication, service access, and network transport separately. A desktop app may fail while browser access works because client rules do not cover it, or because it uses different domains or connection methods. First verify that its requests reach the proxy, then check the destination response. Change the protocol or route only if the transport is confirmed to be the problem. Repeatedly switching regions adds session variables and may make troubleshooting harder than sticking with one working egress.

Streaming: test sustained throughput and region separately

Video streaming requires a steady supply of data, but playback is also affected by a platform’s regional policies, account status, and content rights. A page that loads but will not play a video is a different issue from buffering during playback. For the first, check the message shown by the service and egress-related conditions. For the second, look at sustained transfers, local concurrent activity, and route fluctuations. Client usage labels can help narrow your options, but they do not guarantee playback for every account or title. Verify the result in the app and content you actually use.

Streaming can reveal instability in sustained throughput that short page requests may not, although player buffering can hide some fluctuations. Assess the full viewing session rather than a brief recovery after seeking. Streaming also uses more data, so protocol choice does not replace data planning. VPNHorse 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 based on the remaining days. See the Plans page for details.

Remote work: minimize unexpected route changes

Remote terminals, collaboration tools, and meeting apps have different network requirements. Terminal work depends on responsive input; file sync depends on completing transfers; meeting apps may rely on datagrams and their own recovery logic. A large-file download is not a substitute for testing every work scenario. For work, first identify a route and rules that function reliably, then check whether background sync interferes with foreground interactions. If you need to make a change, change one variable at a time. Avoid switching egress or traffic-routing modes repeatedly during an important session.

Work devices may already have organization-managed network access, certificates, or routing requirements. Follow the relevant policies and confirm whether other network tools can run at the same time. Multiple virtual network interfaces or proxy apps routing traffic can cause route conflicts and inconsistent DNS resolution. If only a work app fails, check its access requirements before forcing all traffic through the same route. Unlimited devices does not mean every device has to use the same protocol; choose based on platform compatibility and the task.

Use different criteria for occasional use and long sessions

Occasional use is more about easy access, recovery from idle, and conserving data. Long sessions call for consistent connections and stable performance during peak hours. Data packs cost ¥158 for 300GB, ¥358 for 1000GB, and ¥658 for 3000GB. They remain available until used and never expire. Billing and protocol performance are separate concerns; no protocol inherently uses less of your plan’s data. Read the data pack vs. monthly plan guide to assess your usage pattern and decide whether you need a larger data allowance.

Frame the result as “a better fit for this task, device, and network” rather than “the best protocol overall.” Access permissions, account region, and destination platform rules are still determined by the relevant service.

VPNHorse offers anonymous, no-logs service, unlimited devices, and a 60-day money-back guarantee. No email address is required; create an account with a username and password. Payment methods include Alipay / WeChat Pay / USDT. These are service details, not measures of protocol performance. Review plans and refund terms separately from technical performance, so you understand both the costs and rules and whether your usual tasks work reliably. Do not let one label stand in for a complete comparison.

Testing and troubleshooting

Start with a baseline you can restore

Before troubleshooting, note the client, network, rule mode, and route name, and check that the subscription is up to date and the account is in good standing. Do not delete all your settings before recording them; the original state is often essential to understanding the problem. If you changed advanced settings manually, save a local backup, then restore the defaults from your subscription. New users can revisit the Guides to check the import and permissions steps, rather than mistaking an installation or traffic-routing issue for a protocol compatibility problem.

Next, identify where the failure occurs: can the client start, read the subscription, and establish a server connection? Does app traffic reach the client, and does the destination return a valid response? Keep the original error category for each stage. Authentication failure is not the same as a timeout; a certificate error is not the same as a destination refusing access. Narrow down the issue based on where the error occurs, then choose the next check. This is usually faster and easier to reproduce than trying every setting from scratch.

Use cross-checks to narrow down the cause

Keep the device and app the same, then change one route to see whether the issue relates to the original path. Keep the route and app the same, then change the access network to see what local connectivity affects. Keep the network and route the same, then change the destination task to check for destination-specific issues. Re-establish the connection you are testing after each change; an existing session may still use the original path. If a candidate route changes both protocol and region, note both changes rather than attributing the result to just one.

If the client reports a connection but the app makes no progress, first check whether the app is covered by the rules, then check DNS resolution and the destination connection. In system proxy mode, some apps may not use the system proxy; that is a traffic-routing coverage issue. In virtual network mode, check for route conflicts and DNS issues. For initial setup on a PC, see the Windows guide to importing and testing a VPN connection. This page does not provide large blocks of generic configuration, since snippets detached from a specific platform and subscription can introduce new variables.

Different errors call for different troubleshooting steps

For authentication errors, check the subscription, account status, and system clock. For certificate errors, check the server name, certificate chain, and clock; do not disable identity checks as a long-term fix. If only apps that use datagrams fail, check client support and the UDP path. If problems begin after locking the screen, check background activity and recovery from idle. If all routes fail on the same network, check local connectivity and whether the client is routing traffic properly. If only one destination is affected, keep its error message and avoid reinstalling the client as a first step.

If some entries stop working after a subscription update, check whether the client reports an unsupported protocol, transport, or encryption method. A successful import does not mean every field was applied correctly; the client may skip entries it does not recognize. Use the import route provided in the user panel rather than an unknown conversion service. Subscription links are tied to your account, so do not post them in public forums or shared documents. If you need help, describe how you imported the subscription and what error occurred without sharing the full link.

Include reproducible details in tickets, but never share credentials

A useful troubleshooting report includes when the issue occurred, device and operating system, client name, network type, route name, rule mode, destination app, and error. Add the comparisons you have already tried. Details such as “other routes work on the same network,” “switching networks fixed it,” or “it only happens after resuming from the lock screen” are more useful than “it doesn’t work.” Before sending a screenshot, hide subscription URLs, authentication fields, account identifiers, and other private information. Review logs before attaching them, too.

Find the ticket form in the user panel. For common issues, see the Help Center. If a change restores access, record the conditions and confirm that sustained use, recovery from idle, and your usual apps all work—not just one page load. You can repeat the same process when your network conditions change. The goal is not to find a protocol ranking that never changes, but to build a reliable way to explain differences, preserve a baseline, and get back to work.