VPN Protocols and Network Routes

Connection Layers and Performance Limits

A web request does not travel along one simple, direct line from your device to the content. First, the app looks up the domain name and chooses a network interface. The client then follows its rules to connect directly or through a proxy. Data travels over a route to an exit point, which accesses the destination service; the response follows a route back to the app. A delay at any stage can feel like a slow connection, but each cause calls for a different fix.

First, distinguish protocols, transports and routes

A proxy protocol defines authentication, how destination addresses are represented and how data is encapsulated. The transport layer determines how data is delivered, for example as a reliable byte stream or through reliable delivery over datagrams. A route is the actual path made up of an entry point, backbone links and an exit point. These elements can be combined in different ways: the same protocol can use different routes, and a route can offer multiple protocol options. A protocol name alone cannot predict performance during peak hours.

Node names shown in a client are usually labels for easy identification, not complete technical specifications. A location may refer to the exit point rather than the entry point. “Dedicated line” may describe just part of a route; it does not mean every link between your home router and the destination site is dedicated. After identifying a connection by name, check its transport, client support and usage rules. Treat details you cannot confirm from the name as unknown rather than filling in the gaps yourself.

Page load time and sustained transfer are different metrics

Loading a page involves domain lookup, connection setup, encryption negotiation and a response from the server. Since small requests transfer little data, time spent waiting at each step can dominate. With a large download, the setup cost is spread across the transfer, making sustained throughput and packet-loss recovery more important. So a download can run smoothly while pages take a while to start. Likewise, quickly seeing text on a page does not prove a long video stream will stay stable.

Connection reuse can reduce the overhead of repeatedly setting up connections, but apps do not all use it the same way. Browser caches, existing connections and content delivery caches can also make repeat visits seem faster. If you compare routes by repeatedly refreshing the same page, you may mistake the effect of caching for a protocol advantage. Test fresh requests and sustained transfers with the apps you actually use. Compare different stages instead of looking for one number that claims to sum up the whole experience.

Latency measures round-trip wait time; jitter measures how much that wait varies; packet loss means data does not arrive as expected; throughput measures how much data a connection can transfer over time. These metrics affect one another, but they are not interchangeable. A low-latency route can be congested with shared traffic, while a high-throughput route can still feel sluggish in interactive apps. Start by identifying the problem your app is most sensitive to, then decide what to measure.

Encryption boundaries and app behavior

Proxy encryption mainly protects data in transit between your device and the proxy endpoint. The app's own HTTPS connection still matters: it protects content between the app and the destination service. These two layers serve different purposes. Using a proxy is no reason to ignore browser certificate warnings, and protocol encryption is not the same as account security. Subscription links and client configurations are access credentials. If they are exposed, follow the steps provided in the user panel.

Routing rules determine which requests go through the proxy. If your browser uses the proxy while another app connects directly under the rules, they may appear to have different exit locations as expected. Domain lookups may also take a separate route, so a connection toggle alone does not prove that all traffic is covered. To verify, check the rules, lookup results and connection logs for the specific app. Do not blindly change every system setting just to make the results look consistent.

The protocol determines how data is encapsulated, the route determines where it travels, and the rules determine which requests use that route. Keep these layers separate when troubleshooting to avoid conflating exit location, client settings and transport performance.

Design Trade-offs in Stream-Based Protocols

Shadowsocks, VMess, Trojan and VLESS often appear in client protocol lists, but they are not a ranking from basic to advanced. They differ in authentication, encryption responsibilities and compatible transports, and may require different deployment conditions. Compare the full configuration, not just the protocol field. A setup that works reliably on your devices is more useful than one with a newer-sounding name.

Shadowsocks and VMess

Shadowsocks wraps destination requests in a protected proxy connection, with a relatively straightforward design. Its actual behavior depends on the encryption method, implementation and underlying transport, so different configurations should not be assumed to perform alike. First check that your client explicitly supports the configuration provided in the user panel and identifies it correctly after import. Manually changing the encryption method for “compatibility” often leaves the client and server out of sync.

VMess includes authentication and message handling in its protocol design and can be used with different transports. Extra encapsulation can add processing steps, but resource use also depends on implementation quality, the number of connections and device capabilities. Incorrect system time may interfere with some authentication processes. If a connection fails, first check that your device time is set to update automatically and that the subscription imported completely. Then check the network instead of immediately assuming the route's exit point is unreachable.

For everyday browsing, client maturity often matters more than abstract differences between protocols. Reliable imports, clear error messages, sensible connection reuse and domain handling all affect the experience. If the same configuration fails in one client but works in another compatible client, focus on differences in implementation and settings rather than switching countries or upgrading to a larger data plan.

Trojan and VLESS

Trojan typically relies on TLS for a protected connection, making the certificate, server name and system time part of the connection process. It is not a bare tunnel that will necessarily work as soon as you enter an address and password. If certificate verification fails, do not hide the error by turning verification off. Check the subscription source, how the client identified the configuration and your device's time. If needed, send a redacted error message through a support ticket.

VLESS keeps the protocol's own responsibilities lean and is typically paired with an appropriate security layer and transport configuration. If a protocol field does not handle a particular function, that does not mean the connection lacks that protection; it may be provided by an outer layer. To assess security and resource use, review the underlying transport, TLS settings and client support together. Comparing VLESS configurations with different outer layers can lead to meaningless conclusions.

Even combinations that use TLS can perform differently because of connection reuse, application-layer encapsulation and server scheduling. An extra layer may be needed to suit a deployment environment, not to improve speed; removing layers does not guarantee a shorter cross-region route. The practical choice is to use a combination provided in the user panel and fully supported by your client, then test it with the apps you use. Do not infer performance from the number of configuration fields.

Reliable delivery and head-of-line waiting

When a proxy uses a reliable byte stream, lost data must be recovered, and later data may have to wait for the gap to be filled. This ensures the app receives ordered content, but packet loss adds wait time. When many logical requests share one underlying connection, a delay can affect more of them. Reuse saves connection setup time but can widen the impact of a shared problem. Decide whether it makes sense based on implementation guidance and how your apps perform.

These protocols are a useful starting point for comparing compatibility, especially on networks that restrict datagram traffic. But connecting is only the first step: check page load times, long-lived connections and recovery after a network change. Keep a verified configuration as a baseline rather than importing many configurations from unknown sources; doing so adds uncertainty about both errors and performance.

QUIC Protocols and Unreliable Networks

Hysteria2 and TUIC are often discussed for unreliable networks because they use QUIC-based designs. QUIC provides encryption and reliable streams over datagram transport, and can handle some transport functions in user space. That does not eliminate retransmissions or mean it will be faster under every kind of packet loss. Performance also depends on whether the network allows the relevant traffic and how both endpoints schedule it.

Hysteria2 and throughput

Hysteria2 is designed with transmission over less-than-ideal links in mind. Congestion control and sending behavior are key to understanding it. Some configurations let you specify an expected bandwidth, but that setting does not add bandwidth to your network. An overly aggressive value can create queues on your local connection, slow other apps and even cause more packet loss. When using a configuration from your subscription, do not increase this value based on how much you want to download.

If the network handles or restricts datagram traffic differently, Hysteria2 may fail during the handshake, fluctuate during sustained transfers or struggle to recover after a network change. A reliable byte-stream protocol working on the same network does not prove that Hysteria2 credentials are wrong. Keep the device and client unchanged, switch the access network and see whether the problem follows it. Then decide whether to try another protocol.

An unreliable network is not a single condition. Random packet loss, prolonged congestion, fluctuating wireless signal and route changes may occur together or independently. A sending strategy that helps with random loss may not suit an already saturated shared link. You can assess whether a protocol is a good fit only after identifying when failures happen and what changes. A single fast transfer does not prove reliable performance at all hours.

How TUIC organizes connections

TUIC also uses QUIC to carry proxy traffic. The experience depends on how connections are organized, congestion control and the client implementation. Multiple streams have independent ordered-delivery behavior at the transport layer, which can reduce some cross-stream waiting, but they still share the same physical link and congestion budget. If the access network is queued, independent logical streams cannot eliminate the shared delay. Multiple streams do not provide separate, interference-free bandwidth.

Connection recovery and session reuse can reduce delays on repeat visits, but whether and when these features are used depends on the implementation and server configuration. A capability in the protocol design is not a guarantee for every VPN34 connection. For interactive apps, check for interruptions, reconnections and response times. For one-off downloads, focus on sustained throughput and the effect on other apps.

Datagram support also needs to be understood in context. A protocol's ability to forward a type of traffic does not mean the client rules route the target app through that connection, or that the destination service accepts the current exit point. If an app cannot connect, check its network requirements, client forwarding support and whether the rules apply. Changing the protocol name in a list without checking whether traffic actually uses that connection is unlikely to help.

How to make a fair comparison

When comparing QUIC-based and stream-based protocols, keep the exit location, access network, test app and background activity as consistent as possible. If you change the remote exit to a closer region and switch protocols at the same time, any improvement may come from the shorter route. Even entry points with similar names may not share the same route. When you do not have enough information, limit the conclusion to “this entry point works better in my current setup.”

Consider device load as well. User-space encryption, data processing and retransmission scheduling use CPU time. Costs that are barely noticeable on a desktop may be more pronounced on a device in power-saving mode or with limited cooling. If sustained transfers cause noticeable heat, check background apps and wireless signal, then compare with another protocol on a similar route. Do not immediately attribute the heat to an inherent flaw in one protocol.

QUIC-based protocols are worth testing on unreliable networks, but they are not congestion fixes. Keep a compatible stream-based connection as a baseline. If a transport fails, first distinguish network restrictions from client compatibility and route issues.

Direct, relayed and dedicated routes

Network topology shows where a request enters, which links it travels over and where it exits. For users, reachability of the entry point, the quality of cross-region links and the route from the exit point to the destination service all matter. VPN34 covers 90+ countries / 250+ routes. For available entry points, see our guide to locations and routes. Coverage gives you more options; it does not mean every location performs the same on every access network.

Direct routes and their limitations

A direct route typically means your device connects to a remote proxy endpoint without an additional service relay. With fewer stages, it is easier to understand and troubleshoot, but public internet traffic still travels through carriers and backbone networks. No service relay does not mean the physical route is the shortest: inter-network links, international gateway routing and routes to the destination region can make a geographically nearby endpoint take a longer path.

When the public internet route from your local network to the remote endpoint is clear, a direct connection can avoid extra forwarding steps. If a public link gets congested during peak hours, a direct connection is affected too. Changing the encryption method usually cannot change the route selected by your carrier. Compare different entry points or route types and see whether performance changes with the route instead of repeatedly restarting the client on the same congested exit.

The final leg from the exit point to the destination service matters too. Even with the right exit location, you may see slow responses if the service uses a distant content delivery node. Domain lookup, server-side routing and account region can all play a part. So a successful connection test alongside one slow website does not automatically point to a faulty entry point. Test other destinations to see whether the problem is limited to the final leg to that service.

An extra relay can still improve the overall route

A relayed route first connects your device to a suitable entry point, then uses another link to reach the exit. Although the route has an extra stage, total wait time can be lower if the entry is closer to your local network and the subsequent links are better. The benefit comes from replacing a poor route, not from the idea that an extra relay is inherently faster. Congestion at the entry point or poor relay scheduling can also make performance worse.

When troubleshooting a relayed route, distinguish the entry point from the exit. If multiple exits share an entry and that entry has a problem, several locations may become unstable at once. If different entry points for the same location perform differently, that can help narrow down the cause. Client names may not reveal which connections share infrastructure, so similar names alone are not proof. A support ticket describing which entry points fail together is more useful than guessing how the servers are arranged.

An IEPL dedicated line covers a specific section of the route

An IEPL dedicated line typically carries traffic over a dedicated link across part of a cross-region route, reducing dependence on fluctuations along some public internet paths. Local access, entry-point processing, exit forwarding and the destination service still affect the connection. Congested home Wi-Fi, competition for entry-point resources or a busy destination site can all affect performance. Treat a dedicated-line label as topology information, not as a guaranteed latency or sustained speed across the entire route.

When choosing a route, first compare under similar conditions, using the same kind of app and a similar exit location. Then check how it performs at the times you normally use it. A brief connection during the day does not guarantee a smooth experience in the evening, and one evening failure does not prove the route is always unavailable. Keep a stable primary connection and a backup with a clear purpose. This makes it easier to tell whether a change comes from your local network, a shared entry point or the destination service, instead of treating the whole subscription as a black box.

Choose a location based on what you need to do. For region-restricted content, the exit location comes first; for regular web use, prioritize responsiveness and reliability; for sustained downloads, focus on how well the route handles traffic. Do not assume a route suits your destination just because its name includes “dedicated line,” or that a nearby location works well for every app. Topology helps explain results; it is not a substitute for testing or a leaderboard.

Packet Loss, Jitter and Peak-Hour Congestion

Network instability is rarely a simple on/off failure. Data may wait in a send queue, wireless signal may briefly weaken, or shared traffic may use up link capacity—all of which can cause an app to stall. Note where the symptom occurs: before the connection is established, while a page waits for a response, during a transfer or after a network change. Each stage points to a different problem. A vague report like “the node is slow” misses the most useful clues.

Where is packet loss occurring?

Interference on a wireless connection, distance from the router and a saturated upload link can all cause problems before traffic reaches an international route. If local services also stall on the same device, check the access network first. If possible, move closer to the router, pause background transfers or compare with another way of connecting. Do not start by changing protocol settings, or local and remote variables will get mixed together.

Packet loss shown at an intermediate hop by a route diagnostic tool does not necessarily mean forwarded traffic is being dropped. Network equipment may limit diagnostic replies while continuing to forward later traffic normally. If subsequent hops and the destination app work as expected, a missing reply from one intermediate hop alone is not proof of a fault. Compare diagnostic output with end-to-end requests, sustained transfers and app errors instead of focusing on the most striking line.

Packet loss that affects traffic triggers recovery and costs time and bandwidth. Reliable transports can recover the data, but users may still experience delays; real-time apps may instead discard outdated data to prioritize timeliness. A file download and a voice call can behave differently under the same packet-loss conditions because they have different goals—not because one app “isn't using the route.” Before troubleshooting, determine whether the app needs reliable delivery or timely delivery.

Congestion and queueing delay

When demand exceeds a link's capacity, queues start to grow. Your device may still show a high download rate, while new requests and interactive data wait in line and feel sluggish. This is easy to miss when the uplink is saturated by backups or sync tasks, because users tend to watch downloads instead. Pause unnecessary background activity and compare again to help identify local queueing rather than blaming the exit location.

Peak-hour problems are often related to shared-resource contention. They can occur on the access network, at interconnection points, at an entry point or at an exit. If multiple apps slow down at the same time and recover after you switch access networks, start by checking the access route. If only one destination service is affected, the server or final leg is a more likely cause. These symptoms can point you in a direction, but one change is not enough to conclude that a specific server inside the service is overloaded.

Larger buffers do not always improve the experience. A longer queue may reduce visible packet drops but increase waiting time; a more aggressive sending strategy may secure a larger share of throughput while making other apps less responsive. Do not change congestion control, buffers or concurrency just to chase a single throughput number. Start with the default settings, identify the bottleneck, and make only documented changes you can undo.

Turn observable symptoms into evidence

Record when the issue occurs, the access network, entry-point name, protocol, app and stage of failure. “The page loads, video plays for a while then stalls, and switching entry points fixes it” is more actionable than just “it's slow.” Do not include complete subscription links, passwords or access tokens in your notes. Keep only relevant log excerpts, and redact details that could identify your account or full requests to a destination.

Automatic selection has its limits. A client's probe may be no more than a lightweight request. It can give some indication of whether an entry point is reachable, but cannot predict sustained performance with a destination service. If automatic selection keeps changing the exit, some apps may prompt you to verify your session again. For long meetings, editing sessions or video viewing, a tested, stable entry point is often easier to manage than constantly chasing probe results.

“Low latency” does not mean “consistently stable.” Interactive apps depend on responsiveness and jitter; sustained transfers depend on pauses and recovery. For online gaming, see our comparison of gaming VPNs and accelerators for latency and packet loss.

Platform Differences and Mobile Battery Use

The same subscription can behave differently on different devices. Clients need to work with each system's network interfaces, background rules, domain lookup and traffic-routing methods. Devices also differ in processor, memory and cooling capacity. VPN34 supports Windows / macOS / iOS / Android / Linux, with no device limit. This describes the range of supported platforms, not identical network implementations or resource use on every platform.

Battery drain comes from sustained activity, not just encryption

Mobile battery use depends on wireless signal, background sync, keeping connections alive, encryption and screen time. A weak signal can make network activity itself more demanding, and frequent reconnections can repeatedly wake the device. Do not compare protocol battery use across different screen brightness, signal conditions and background activity, then attribute the entire difference to the protocol. Keep conditions as similar as possible to your normal use.

Keepalives help maintain a usable connection, but sending them too often can increase background activity; sending them too rarely may let network equipment clear an idle connection. The right behavior depends on the implementation and network. There is no single setting that works for every device. When using the settings from the user panel and the client defaults, first check whether idle connections are actually dropping. If there is no clear problem, do not change connection settings one by one for a supposed battery-saving benefit.

When a device switches between Wi-Fi and mobile data, its route and address may change. A protocol's support for migration does not mean the client, server and current network will always restore the connection seamlessly. If an app stalls after switching, check whether the client is reconnecting, then retry the app request. Avoid rapidly switching between several entry points, or it will be hard to tell what restored the connection.

How system-level routing affects performance

Desktop system proxy settings typically affect only apps that use the system proxy. A virtual network interface can route more traffic, but involves routing, permissions and domain handling. If an app does not use the proxy, that does not necessarily indicate a route problem. Follow the client instructions when choosing a routing mode and check the target app. Do not enable multiple network-routing tools that may conflict with each other.

Mobile operating systems may limit background activity to save battery. If the connection works in the foreground but takes longer to recover after the screen turns off, check whether the system restricts client background activity and whether the issue occurs only on a particular network. Do not turn off every battery optimization setting by default. First identify restrictions that apply to the client, make the smallest change recommended by the system, then check whether other apps or standby battery life are affected.

How to compare resource use

Observe resource use while idle, browsing normally and transferring data continuously. Frequent wake-ups while idle may come from probes, keepalives or another app; higher use during a transfer may be normal processing overhead. System battery reports can also attribute network activity to the client even when another app made the request. Higher battery use reported for the client does not mean it generated the same amount of traffic itself.

Download clients through the user panel; subscriptions are available after signing in. On Windows, macOS, Android and Linux, sign in to download. On iOS, available options depend on the subscription status shown in the panel. Choose a client based on compatibility and system support. Avoid configuration packages from unknown sources, and do not turn off necessary verification to save a small amount of processing.

No device limit does not mean shared routes have unlimited capacity. When several devices sync, download or stream at once, they share your local connection and account data. If interactive apps slow down as more devices connect, check your home upload capacity, background tasks and concurrent activity before blaming the protocol. For guidance on protecting credentials and using public networks, see the basics of account, subscription link and public Wi-Fi security.

Choose a Protocol and Route for What You Do

Start by identifying the task, then choose an exit location and transport. Whether the destination requires a particular region, relies on a persistent connection or handles real-time data matters more than the protocol name. Use a compatible, tested entry point as your baseline. Compare alternatives only when a specific issue keeps occurring. A configuration with a clear reason for choosing it is more useful than a long list of untested nodes.

Browsing, Work and AI Tools

Everyday browsing and office work depend on page startup, consistent responsiveness and reliable long-lived connections. A blank pause while a page loads may come from domain lookup, the handshake or the destination's response. A sudden disconnection while editing calls for checks on connection recovery and the app session. Assess these separately instead of using download results as a proxy for work performance. Both stream-based and QUIC-based protocols may be suitable; what matters is how the client and current network work together.

AI tool response times also depend on model queues, server-side processing, account permissions and regional policies. A page can load while a response takes a long time to generate, without any lack of network throughput. If a request is explicitly rejected, changing protocols is not the answer. First determine whether the error comes from the network or the service, then check the exit location and session status. Availability is ultimately determined by the destination platform and is not guaranteed indefinitely.

If you need to edit continuously or keep a session open, avoid frequent exit changes. A change of exit may prompt the destination platform to check your sign-in again, and rebuilding a session or loading cached content can skew comparisons. If your primary connection is stable, there is no need to switch because probe results have changed slightly. If a real issue occurs, try a previously tested backup and note how the app behaves before and after the switch.

Streaming, Downloads and Online Gaming

For streaming, first match the exit location to the content you want to watch, then check whether the route can sustain playback. A homepage loading does not mean its catalogue will be available, and a brief successful playback does not guarantee a stable full-length stream. Account region, licensing, exit detection and content delivery can all affect the result. Check the specific title and actual playback rather than assuming another service in the same region will behave the same way. For more details, see our guide to accessing streaming content.

Large downloads are useful for checking sustained transfers, but watch for their effect on other apps. If a download saturates your local network, slower page responses do not necessarily mean the route has suddenly failed. Reduce the app's concurrency or pause background downloads, then test interactive apps again. A QUIC-based protocol may work better for sustained transfers on some routes; a stream-based protocol may be more stable. Draw conclusions from tests under the same conditions rather than picking a winner in advance.

Online games, voice calls and remote control depend more on jitter and timely delivery. A standard international route may not suit a particular game's routing needs, and cannot guarantee improvement over a route that is already reasonable. First check that the client supports and routes the traffic your app needs, then compare actual gameplay. If you change exit regions but the game places you on a server farther away, performance may get worse.

Data plans set your usage budget; they do not replace technical testing

VPN34 monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Data resets monthly on your activation date. When you upgrade mid-cycle, the price difference is prorated for the remaining days. Choose a data allowance based on your streaming, downloads and sync habits—not on an assumption that larger plans include different protocol capabilities. Plan pricing alone does not show which entry point will work best on your network.

Data packs cost ¥158/300GB, ¥358/1000GB and ¥658/3000GB. They last until used and never expire. Your budget needs may differ depending on whether you use the service occasionally or continuously. See plans and data pack details for the terms. You do not need to use a large amount of data to test a protocol. First check whether you can connect and whether essential apps work, then monitor performance over time as needed.

This service offers a 14-day no-questions-asked refund and supports Alipay / WeChat Pay / USDT. No email address is required; create an account with a username and password. These are account and purchase terms, not evidence of route performance. Choose based on compatibility, routes and how your apps perform. If the service is not a fit, check the refund request rules in the Terms of Service rather than repeatedly changing system settings to make it work.

A Repeatable Testing and Troubleshooting Process

Good troubleshooting is not about trying every setting at once; it is about making each change explain the result. First note your access network, client, entry point, protocol and app symptoms. Then change the single variable most likely to be involved. Repeat the same task afterward and restore the original setting if needed. Even if the problem persists, this method helps narrow it down and avoids crediting a complex setting for a recovery that may have been incidental.

Start with the import and connection setup

If the client does not recognize an entry point, first check that you retrieved the full subscription from the user panel, used a supported import method and have an active account. Do not paste your subscription into a public conversion website or send the full address to a stranger. If the entry point appears but will not connect, identify whether the error occurs during domain lookup, handshake, authentication or certificate verification. These details are more useful than a screenshot of the node list.

If authentication fails, check the device time, import result and account status before changing network settings. If there is a certificate error, keep verification enabled and check the source and time. If only a particular type of datagram transport fails, try a compatible stream-based connection on the same network, then test another access network. Different errors call for different steps; repeatedly refreshing the subscription or reinstalling the client does not replace identifying the failure stage.

A “timeout” in a log only means the wait exceeded the implementation's tolerance; it does not by itself point to a server fault. A failed domain lookup, unreachable route or missing handshake response can all end in a timeout. Check the surrounding log entries and how other entry points behave. If every entry point fails, start with the access network and client. If only one fails, focus on that entry point and configuration compatibility.

After connecting, test the app you actually need

Once connected, first use a regular website to check that basic requests work. Then test the app you need and confirm the exit location. If web pages work but the target app does not, check whether the rules apply, whether the app uses the system proxy and whether the error came from the destination service. An explicit account or region message is not an ordinary network timeout and cannot be fixed by retrying endlessly. Follow the destination service's rules and guidance.

If interruptions happen occasionally, keep the entry point unchanged and check whether they coincide with background transfers, screen-off time, network changes or a regular time of day. Then change only the access network or the entry point and repeat the same task. If several variables change at once, even a recovery will not tell you why. Assess reliability over the process you actually use, not just by the client's connection icon or one lightweight probe.

A protocol comparison can reasonably end with “not enough evidence to tell.” If candidate entry points have different exits, routes and server loads, you can only say that one combination works better in your current setup—not that one protocol is universally better. Keep your conclusion within the limits of the evidence. That way you can reassess when network conditions change instead of defending an earlier judgment and overlooking new clues.

Document what happened and keep a way to revert

When submitting a support ticket, describe what you expected, what actually happened, when it occurred, how you connected, the client platform, entry-point name and tests you have already tried. Include only redacted error excerpts—never passwords, full subscription addresses or access tokens. If the issue affects only one service, give its public name and the type of error. Remove page content or request details that could reveal personal information.

Incident notes: Use case; access network; client platform; entry point and protocol; failure stage; the single variable changed; result; whether the original settings were restored. Follow this order to create a repeatable support report.

For account and service issues, contact support through the user panel. For common connection issues, start with the FAQ. If you have not imported a client yet, go back to the quick-start guide. This technical reference explains limitations; the setup guide walks you through the main steps. Together, they can help you avoid unnecessary changes.

Keep a clear recovery plan: know which tested entry point to use, which routing mode to select, which settings to leave at their defaults and where to find your current subscription. Do not store configurations containing credentials in public places, and do not leave necessary verification turned off for troubleshooting. Protocols and routes are tools. A sustainable setup is one you can explain, test with your apps and roll back when something goes wrong.