Protocol and route reference

A framework for choosing protocols and routes

Assess the app, transport and network path separately

A slow webpage doesn’t automatically mean a particular protocol is unsuitable. A request passes through several stages: the app sends it, the domain is resolved, the client applies its rules, a connection reaches an entry point, and that point forwards traffic to the destination. Each stage adds its own delay. A page may also rely on resources from multiple domains; if one fails, the page may appear blank or its buttons may not work. Before choosing a route or protocol, narrow down the issue: is everything slow, or just one site? Is the first load slow, or does the transfer remain slow? The clearer the symptoms, the more useful the comparison.

The protocol determines how data is encapsulated, authenticated and transmitted. The route determines which networks it travels through. The same protocol can perform very differently over different paths, while different protocols can both slow down when they share a congested exit. Treat “switching protocols” and “switching routes” as separate variables. Keep the same device, network and task, and change only what you’re testing. If you change the region, protocol and client mode at once, even an improvement won’t tell you which change helped.

Fast setup, sustained speed and stability are different measures

Connection setup time mainly affects the first request and short-lived tasks. It depends on round-trip routing, DNS resolution, transport and encryption handshakes, and connection reuse. Sustained downloads depend more on available bandwidth, packet recovery and congestion control. Stability is about consistency: whether long-lived connections drop, video keeps buffering or a network change forces a reconnect. A small file downloading quickly doesn’t prove a long transfer will be stable. Nor does a low latency reading from a client prove that the route to a particular service is just as short.

Resource use also has several causes. Encryption uses processing power, maintaining connections uses memory, and frequent data exchange wakes the network hardware. Actual overhead also depends on the client, rule set, logging level, number of connections and app workload. Desktop and mobile devices have different constraints, as do foreground downloads and background keep-alive activity. A protocol name can suggest how it works, but it can’t provide a universal battery-life ranking. Choose based on device temperature, background behavior and connection recovery—not the name alone.

A technical overview isn’t a list of service capabilities

This page explains the general design of Shadowsocks, VMess, Trojan, VLESS, Hysteria2 and TUIC. It doesn’t mean every VPNKC route supports all of them. Check the user panel and the subscription available in your client to see which protocols can be selected, whether datagrams are supported and whether connections can be reused. A client’s ability to parse a format doesn’t mean the server provides a matching endpoint. Don’t treat a protocol support list as permission to replace server settings, and never modify subscription authentication details just to try a protocol.

VPNKC covers 120+ countries and 170+ routes. This describes the range of options, not a performance guarantee for every destination. When browsing the route directory, first check the region and available entry points, then test a route against your current task. Account and data allowances are separate considerations: monthly plan data resets each month on the activation date, while data add-ons remain valid indefinitely until used. Neither changes how a protocol works. See the plans page for details.

A good order of operations: check the app and its rules, then the access network and route, and finally the protocol. Evidence gathered under the same conditions is more reliable than a one-off speed impression.

Trade-offs in stream-based protocols

Shadowsocks and VMess: different ways to encapsulate traffic

Shadowsocks is an encrypted proxy protocol commonly used to forward client traffic to a server, which then connects to the destination. Its security and efficiency depend on the encryption method, client implementation and server configuration. Modern authenticated encryption combines confidentiality with integrity checks, allowing the receiver to detect modified data. The protocol’s structure is generally straightforward, but that doesn’t mean every implementation is faster. Additional transport layers, plugins and datagram support can all change how a connection works, so compare the actual configurations.

VMess provides authentication and request-encapsulation mechanisms and can be paired with different transports. A native stream transport and a connection carried over an additional application layer can differ in startup overhead, network compatibility and resource use. Some authentication flows also depend on accurate system time; a significantly incorrect device clock can cause connection failures that aren’t obvious. If importing succeeds but the connection won’t establish, check that the system clock is synchronized, then check subscription and client compatibility. Don’t keep changing regions and conclude that every route is at fault.

Trojan and VLESS: encryption can’t be judged by name alone

Trojan typically uses TLS for encrypted transport, then handles proxy authentication and request forwarding within the connection. TLS certificates, service names and verification settings are therefore important to a valid connection. Certificate verification confirms the identity of the other party. If verification fails, check the system clock, server name and subscription integrity. Disabling verification may hide the error temporarily, but it changes the security boundary and can mask incorrect settings. Keep the parameters provided in the user panel. If you can’t confirm what’s wrong, ask support to check them.

VLESS focuses on lightweight authentication and forwarding. It should not be assumed to provide a complete transport encryption scheme on its own. Protection comes from the secure transport used with it, and different combinations have different handshakes and network requirements. “Lightweight” describes a design trade-off; it doesn’t guarantee low latency on every route. If the destination path is congested, trimming a small amount of encapsulation overhead is unlikely to fix the bottleneck. When comparing VLESS, record the full transport combination, not just the protocol label.

Where reliable byte streams help—and where they can stall

When these protocols use TCP byte streams, the transport layer delivers data reliably and in order. Apps don’t have to handle every lost packet themselves, but if a segment goes missing, later data may have to wait until it’s retransmitted. This head-of-line blocking can affect real-time use, especially when multiple requests share a connection. It’s not a flaw unique to any proxy protocol; it follows from reliable, ordered delivery. The more often packets are lost along a route, the more likely apps are to experience occasional pauses—not just lower average speeds.

Connection reuse can reduce the overhead of repeatedly opening connections, but it also puts more tasks on the same underlying connection. That may help with many short requests. With a mix of downloads, interactive tasks and long-lived connections, shared congestion or waiting can cause interference. The result also depends on the client’s reuse implementation, server limits and the app’s own connection pool. Don’t treat “enable connection reuse” as a guaranteed speed boost. If short requests improve but interactive tasks get worse, compare the default and alternative settings on the same route and watch for pauses caused by shared connections.

Start with the client’s default combination, provided it’s maintained and compatible, to establish a baseline. If connections often fail during the handshake, check DNS, system time and authentication. If they connect but transfers stall, investigate the route and congestion instead. Switching protocols won’t fix incorrect rules or make a slow destination respond faster. For Windows system proxy and split-tunneling issues, see Windows system proxy and rule-based routing explained to check whether the app is actually using the route you’re comparing.

QUIC protocols and recovery on unstable networks

What Hysteria2 and TUIC have in common

Hysteria2 and TUIC are both associated with QUIC transport. QUIC runs over UDP and provides secure connections, congestion control and multiple streams; it’s much more than a simple way to send datagrams. The client and server must complete the relevant authentication and negotiation, and the local network must allow the required UDP traffic. If the access network handles UDP poorly, the connection may fail to start, drop intermittently or behave unexpectedly. Trying a different transport can help isolate the issue, but it doesn’t prove QUIC is inherently unstable.

QUIC’s multiple streams can make progress independently, rather than forcing all traffic to wait in one ordered byte stream. If data is lost on one stream, others don’t necessarily have to stop due to the same ordered-delivery constraint. However, all streams still share the network’s capacity, and congestion control and receiver resources can affect them together. Multiple streams can’t eliminate congestion or guarantee an app will never wait. An app may still pause if it needs a result first, or if the client groups tasks onto the same stream.

Congestion control determines how available capacity is used

Hysteria2 configurations commonly include parameters related to bandwidth estimation or congestion control. TUIC is also affected by its congestion-control implementation and how it forwards datagrams. Algorithms differ in how they interpret latency, packet loss and available capacity, and they have different design goals. In some networks, packet loss comes from wireless interference; in others, it comes from router queue overflow. If an algorithm treats every lost packet as the same signal, results may not match expectations. Understanding what a setting does matters more than simply increasing its value.

Bandwidth settings should match the actual environment and server requirements; they aren’t a way to buy more speed. Overestimating capacity can increase queuing, packet loss or resource use and make interactive tasks slower. Underestimating it may prevent sustained transfers from using the available path fully. If your subscription provides a value, start with that. If the client allows custom settings, read the implementation’s documentation and keep a copy of the original configuration. There’s no universal value: the access network, server settings and implementation all vary.

Test connection recovery and datagram support separately

QUIC includes mechanisms related to address changes and connection IDs, but whether a specific proxy handles network switching smoothly also depends on the client, server and operating system working together. When a device switches from Wi-Fi to mobile data, its exit path, address mapping and routing all change. The protocol may be able to handle some changes, but that doesn’t mean the operating system will promptly resume a background process. Check whether new requests work after the switch, whether existing connections recover and whether failures happen only when the screen is locked. This helps distinguish transport issues from background restrictions.

Voice calls and games may use datagrams, but “uses UDP underneath” doesn’t mean application datagrams are forwarded correctly. The proxy needs to support the relevant transport, the client must capture the traffic and the server must allow access to the destination. Some apps also probe routes themselves or use separate stream-based control and datagram-based media connections. So a working webpage doesn’t verify the route for a game or call. Test the connection in the actual app; don’t use a browser download as a substitute for a datagram test.

“Quantum encryption” is a VPNKC security message, not the name of a transport protocol. A protocol’s name alone also doesn’t prove that it uses a particular post-quantum algorithm; algorithm and implementation details need to be documented separately.

Before choosing Hysteria2 or TUIC, confirm that your client provides the relevant option and that your current network can carry it reliably. If a stream-based protocol already handles your tasks well, there’s no need to switch just for the name. If you see pauses on an unstable network, compare recovery under the same conditions. State conclusions with their limits—for example, “long transfers recovered more smoothly on this Wi-Fi network”—rather than turning a local result into a universal ranking for every region, device and network.

Network routing and exit locations

Direct, relayed and dedicated routes describe different network paths

Direct routing usually means there’s no additional service relay between the client’s entry point and the destination, though traffic still passes through carrier routers and network interconnections. It doesn’t mean a physical direct connection or the shortest possible path. Routing depends on peering, capacity and commercial arrangements, so nearby locations on a map may connect through a more distant exchange. To assess a direct route, focus on real-world performance toward your destination—not geographic distance or assumptions about stability based on a label.

A relayed route separates the entry point from the exit: the client connects to an entry point, which forwards traffic to an exit. This can use a better-connected path and improve performance on some access networks, but it also adds components to maintain. Congestion can occur at the entry point, between entry and exit, or between the exit and destination. A relay isn’t automatically slower, just as a direct route isn’t automatically faster. An extra leg may improve peering and the overall experience. Compare the full path, not the number of nodes.

Terms such as dedicated route and IEPL describe how particular links are organized. Even if part of a route is more controlled, the user’s local connection and the final leg to the destination may still use public networks. A label doesn’t describe the entire end-to-end path or guarantee the same capacity at all times. When viewing the route directory, rely on the details actually listed; don’t infer an unlisted route type. This page explains the terminology, not a claim that every VPNKC route uses a particular topology.

Don’t confuse the entry region with the exit region

The entry point accepts the client connection; the exit connects to the destination on the user’s behalf. The region shown for a route often relates to its exit, but check the service’s documentation for its naming conventions. A client’s latency test to an entry point covers only part of the path and can’t directly show how the exit performs toward a destination. For region-sensitive apps, also check how the service identifies the exit and whether the account region matches the network region. Route names, map locations and the region shown by a destination site may come from different sources.

Residential IPs, shared exits and geolocation

“Residential IP” is a common search term, but it’s not a standard capability defined by any proxy protocol. To assess one, distinguish the address’s allocation background, its listing in geolocation databases, how destination sites identify it and its usage history. Different sites may use different databases and may also consider account records, payment region and risk signals. An address that appears to match your expected region won’t necessarily be classified the same way by every service. This page doesn’t claim that any particular route has a specific IP address type.

With a shared exit, multiple connections may access destinations from the same IP address. This can work for everyday browsing, but a destination service may assess activity from that address collectively. An IP change may also trigger account re-verification; that’s separate from the reliability of the transport protocol. If you see a region warning or access restriction, note the exact message and check the exit and account requirements. Changing encryption alone usually won’t change how a website classifies an address. Verify relevant capabilities with your client and the destination service’s rules.

Keep the destination in mind when choosing a route

For interactive tasks, start with a route suited to the destination and one that establishes connections reliably. For sustained transfers, check whether throughput remains steady from the exit to the destination. Searches for an accelerator for access to mainland China are different from searches for international exits; an overseas route directory shouldn’t be mistaken for a specific return route. See the VPNKC routes page for region options. Route types, entry points and directions depend on the directory and your client. If you want to share a route across devices at home, read router setups and whole-home networking: the trade-offs to understand the limits of a shared entry point.

Packet loss, queuing and peak-hour congestion

The same slowdown can have different causes

Network congestion occurs when demand exceeds the capacity to process or transmit traffic on a particular segment. Data enters a queue, and growing queues increase wait times; if a queue fills up, packets may be dropped. You may notice slower webpage responses, choppy calls or fluctuating download speeds. Peak hours are simply periods when demand tends to rise; they’re not a separate type of fault. Your Wi-Fi, access provider, network interconnection, relay entry point or destination server may all be handling more traffic at the same time. Narrow down the problem one segment at a time.

Packet loss doesn’t always mean the route lacks capacity. Wireless interference, changes in signal, an overloaded device or expired address mappings can all cause similar symptoms. Loss during a sustained transfer triggers recovery mechanisms; an occasional lost packet during a short interaction may make one action noticeably slow. Averages can hide these pauses, so track continuity too: does the connection stop completely for a moment? Does it happen only while moving? Does it coincide with downloads on other devices? The conditions that trigger a problem often help locate it better than a single speed reading.

Queue buildup can make downloads interfere with interactive tasks

When a large transfer fills queues along a route, even lightweight interactive requests may end up waiting behind it. This can make webpages or calls feel much worse during a download. Heavy packet loss isn’t required; long queues alone can add significant response time. Pause background downloads and cloud sync, then repeat the interactive task. If it quickly improves, shared capacity and queueing are likely factors. Repeatedly switching regions may not help: the congestion could be on your local access segment, which every international route shares.

Uploads can affect performance too. Video calls, backups and file sync may fill the upload path, forcing acknowledgments and new requests to wait. It’s easy to focus on download speed and miss the overall delay caused by an upload queue. Check sync apps, remote transfers and activity on other devices. If your client or local router offers suitable traffic management, follow its instructions. Don’t try to counteract queueing by arbitrarily increasing a protocol’s bandwidth estimate; that can add even more pressure.

A test only tells you about the part it measures

Client latency tests may use a connection test, request test or another method, and each covers different parts of the path. Intermediate hops in routing tools may also deprioritize replies, so a missing test response from an intermediate device doesn’t mean it drops forwarded traffic. Consider test results alongside access to the final destination, and don’t label an intermediate hop as the fault based on that result alone. If the end-to-end connection is stable, anomalies in intermediate tests are clues, not proof of a fault.

When comparing peak-hour performance, keep the task and general conditions as similar as possible. A video that has already buffered isn’t comparable to one just starting to load. A cached result and a fresh download can also behave differently. Repeat the same action on the same service and note whether pauses happen before connection or during transfer. For sustained tasks, check steady progress rather than a brief speed peak. Results collected without controlled conditions aren’t a sound basis for long-term protocol or region rankings.

When to change protocols—and when to change routes

Comparing protocols makes sense if one transport fails to establish a connection on your current access network while another works. If all connections establish but one route keeps stalling, try a different entry or exit first. If every route slows during local downloads, investigate the shared access bottleneck. For games, also consider server distance, datagram forwarding and app-specific routing; webpage performance through a proxy doesn’t predict in-game performance. See game accelerators vs. VPN proxies to check that the options address the same kind of problem.

Pause shared transfers before comparing routes, and confirm the destination before interpreting test results. Changing fewer variables makes it less likely that you’ll mistake a local queueing issue for a protocol defect.

Platform traffic handling and mobile battery use

System proxies and virtual network interfaces capture different traffic

A system proxy provides an entry point for apps that follow the system’s proxy settings. A virtual network interface captures traffic closer to the routing layer. They solve different problems. Some apps use their own network settings and may ignore the system proxy; some datagram-based tasks can’t be handled by a browser proxy alone. A virtual interface usually covers more traffic, but requires coordination with permissions, routing, DNS and other network software. A connected status only confirms the tunnel state. Verify in the destination app that its traffic is actually using the expected route.

Running multiple tools that capture network traffic can cause route overrides, DNS conflicts or forwarding loops. First determine which tool controls the default route, then disable any network capture you don’t need. Corporate networking software, virtual machines, remote-work tools and local development environments may all add interfaces. Don’t delete all your network settings just to troubleshoot. Record the current state first, then temporarily quit or disable tools as their documentation recommends. This gives you a simpler baseline while preserving the option to restore your normal setup.

Battery use reflects processing, data transfer and wake-ups

Mobile battery drain can’t be blamed on encryption alone. Continuous transfers, weak signal, frequent background wake-ups, detailed logging and rule processing all use resources. Video decoding and image processing in the app itself may consume more power. To compare protocols, keep the app task, screen state and access network as consistent as possible. Check whether the client stays active, whether the device gets unusually warm and whether network activity drops after the task ends. A brief temperature change doesn’t prove a protocol is inefficient, let alone establish a general battery-life ranking.

Keep-alive traffic can maintain connections or network mappings, but sending it too frequently increases background activity. Longer intervals can reduce wake-ups, but may allow connections to expire sooner on some networks. The right setting depends on the client, network mapping behavior and server policy; there’s no universal value. If your subscription and client already provide defaults, observe those first. Only consider changing settings after confirming that connections fail to recover from sleep and understanding what the parameters do. Don’t change every background option at once.

How macOS clients differ from terminal apps

On macOS, browsers, terminals and development tools may use different network paths. A browser opening a site successfully doesn’t mean terminal downloads or editor extensions use the same settings. Check whether the tool reads the system proxy, has its own proxy options and is covered by the client’s traffic capture. If only terminal tasks fail after waking from sleep, try reconnecting that app before reimporting the entire subscription. Download the client and subscription through the user panel download page; sign in to access the subscription.

Troubleshooting background restrictions and network changes

Android devices may restrict apps running in the background; on iOS, the system manages network extensions and scheduling. First test in the foreground, then lock the screen, then switch access networks. This helps separate transport issues from background restrictions. If the connection works in the foreground but fails in the background, check the relevant background activity settings. If it fails only after a network switch, check whether it reconnects and whether new requests can be established. For the full Android setup, see the Android client installation and verification guide. Setting names vary by device.

VPNKC supports Windows, macOS, iOS, Android and Linux, with no device limit for simultaneous connections. That doesn’t mean data allowances increase with more devices or that devices on a shared network won’t affect one another. Downloads, backups and calls compete for capacity when household devices share an access path, and account data allowances still follow the plan rules. If performance differs across devices, compare their modes, background permissions and access networks while keeping the route the same. Don’t assume the account itself is the cause.

Choose a route for your use case

Websites and AI tools: prioritize connection continuity

Web interactions rely on DNS, short requests and connection reuse. AI tools may also return long, streaming responses. Searches such as “ChatGPT accelerator” and “Cursor accelerator” can refer to very different issues: page loading, interrupted responses, editor extension connections or remote development tasks. Describe the symptom first: does the page load, does sign-in work, is the request sent, does the response start, and does it later stop? Each stage points to different checks. Don’t reduce every failure to “not enough speed.”

If a streaming response starts but stops partway through, check for a network switch, sleep, client reconnection or an error from the destination service. Keeping the same exit can reduce address changes as a variable, but it can’t guarantee that the destination will always accept the connection. Editor extensions may use their own network stack, so accessing the same service in a browser doesn’t confirm that the extension’s route is working. Check the extension’s proxy settings and client rules before comparing protocol recovery. If the server explicitly rejects a request, follow that service’s account and usage rules.

Streaming: sustained throughput and region both matter

Streaming depends on sustained data transfer as well as the platform’s region checks, account permissions and content licensing. A smooth connection doesn’t necessarily mean the content will play. A player may buffer first and then adjust video quality, so a smooth start doesn’t rule out later pauses. A playback failure may also relate to account or content requirements rather than a broken route. Note the title, error message and buffering stage, then see the streaming guide for testing methods. This page doesn’t promise that any protocol will work with a particular platform or title.

For video, watch buffering over a continuous playback session instead of judging only the initial load. If the quality keeps changing, pause other downloads, check local capacity, then compare the same content over other available routes. Switching regions may also change the content catalog and cache hits, making the results hard to compare. Record region and transport conditions separately: the first indicates whether the platform’s requirements are met; the second, whether playback is continuous. Only consistent conditions can show whether a route change improved the task.

Trade-offs between calls, games and file transfers

Calls and games are more sensitive to timing variation, so consistent delivery often matters more than peak download speed. Check that the client captures the app’s datagrams correctly, that the route is suitable for the destination and that local wireless conditions are stable. Some games also use their own server matching and network policies; a proxy connection doesn’t replace app-specific route configuration. Test the protocol with the actual task. “Uses UDP” isn’t a guarantee of game compatibility, and a webpage route in the same region isn’t necessarily the route to the game server.

File downloads and code sync depend more on completing the task successfully. Resume support, app-level verification and server capabilities also affect recovery. If a task fails at the same point repeatedly, check app logs and the destination’s response, and rule out file permissions, expired authentication or insufficient storage. If different tasks fail during network switches, check the client’s recovery behavior. Sustained high-volume transfers also use shared capacity, so avoid running them alongside important calls. Scheduling tasks sensibly is more effective than chasing a protocol’s momentary speed.

Technical choices and billing choices solve different problems

Protocols don’t determine how plan data resets. VPNKC monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Data resets monthly on the activation date; mid-cycle upgrades are prorated for the remaining days. Data add-ons cost ¥158/300GB, ¥358/1000GB and ¥658/3000GB, and remain valid indefinitely until used. Choose a billing option based on how often you use the service, then choose a route based on network conditions. See the plans page for full pricing.

Get started with VPNKC without an email address—just a username and password. Payment methods include Alipay, WeChat Pay and USDT, and there’s a 14-day no-questions-asked refund policy. For comparisons, use the apps and network you actually rely on as your baseline; experience from another device may not apply. To import a subscription for the first time, follow the getting started guide, from retrieving your subscription to verifying the connection. This page explains observed differences; use the user panel for settings and account tasks.

Build a troubleshooting process you can repeat

Record what happened before making a small, deliberate change

Start troubleshooting with symptoms you can describe. Record the affected app, task stage, current access network, selected route and client mode. Keep the exact error message. Don’t repeatedly refresh the subscription, switch regions and change settings without taking notes, or it’ll be hard to reproduce the issue. First confirm that the account and subscription are in good standing, then check that the imported configuration works, and finally test the destination app. If you can’t establish a basic connection, discussions of throughput or protocol rankings can wait. Restore a working baseline first.

Pick a representative task as your baseline—for example, open a frequently used service and repeat the same interaction, or start a transfer you can monitor. Keep the device and network unchanged, test the current default settings, then change one clearly defined variable. If another route helps, switch back and recheck the original route so you don’t mistake a destination service recovering on its own for the effect of the route change. If the problem can’t be reproduced, record “working again this time” rather than claiming to know the root cause. A cautious conclusion is more useful for support and future configuration choices.

Choose checks based on where the failure occurs

If a domain won’t resolve, check the system resolver, the client’s DNS settings and the current network. Remember that an app may use its own DNS method. If authentication or the handshake fails, check the subscription, device clock, service name and client compatibility. If a connection is established but no traffic gets a response, check rule matching and the route to the destination. If transfers start but keep stalling, investigate shared capacity, wireless conditions, congestion and recovery behavior. Each branch should be guided by supporting symptoms—not answered with the same reinstall steps for every issue.

Tell rule issues apart from transport issues

Split-tunneling rules decide which route a destination uses; the protocol determines how traffic travels once it enters the tunnel. If a rule doesn’t match, changing the protocol usually won’t affect access to that destination. Check the client’s connection log to see whether the app’s request appears, which rule it matches and which outbound route it uses. If the app’s traffic doesn’t appear at all, check the coverage of the system proxy or virtual interface. If it appears but takes the wrong route, fix the rule or app settings first. Keep only the diagnostic logs you need; detailed logging over time uses extra resources.

Temporarily capturing more traffic can help with diagnosis, but don’t leave it enabled without understanding the impact. Broader traffic capture may change routes for local devices, work networks or development environments. After testing, restore rules suited to your usual tasks and recheck access to local resources. For common first-time issues with accounts, imports and permissions, see the complete VPN beginner’s guide. That article covers setup steps; this page explains failure mechanisms. Together, they’re more useful than repeatedly importing the subscription.

Protect your configuration when contacting support

In a support ticket, describe the expected and actual results, how to reproduce the issue and what you’ve already changed. Include your platform, access network, route name and the stage where the failure occurs, along with a checked screenshot of the error. Redact subscription URLs, authentication fields and session details. Logs may include destination addresses or browsing records, so make sure you’re sharing only what’s needed to troubleshoot. Contact VPNKC through user panel tickets; see the contact page for more information.

After recovery, repeat the original task and check conditions that often trigger problems, such as sleep, network switching and concurrent transfers. If reconnecting only restores service temporarily, record that without claiming the root cause is fixed. For long-term use, choose a combination that’s maintainable, compatible with your platform and reliable for real tasks. Protocol names, exit regions and topology labels are clues; the final evidence is app behavior that can be reproduced under the same conditions. Troubleshooting is complete when you can explain the difference and restore the original settings.

For setup steps, see the guide; for regions and entry points, see routes; for data and pricing, see plans. For technical issues, keep the reproduction details and contact support through a ticket.