Protocol and Route Technical Guide

How Connections Work: Distinguishing Protocols from Routes

What happens when you connect

When you open a webpage, the client first decides whether the request should use the proxy. It then resolves the destination domain or forwards it for resolution, before connecting to an entry point through your local network. The entry point validates the request before establishing the onward connection to the destination. The page's load time reflects all of these steps. A protocol name describes only part of the communication; it cannot tell you how the full route performs. The same protocol can feel very different depending on the entry point, exit location, and local network.

To understand a connection, consider authentication, encryption, data transport, and the network path separately. Authentication determines whether the server accepts the client. Encryption protects data in transit. Transport handles delivery, retransmission, and congestion control. The path determines where the data travels. These elements can work together, but they are not interchangeable. Treating an encryption method as a route tier, or a dedicated-route label as a protocol name, makes comparisons unreliable and can lead you to misidentify where a problem occurs.

Connection setup and sustained transfer are different measures

Short requests are often more affected by DNS resolution, connection handshakes, and the destination server's response time. File transfers and long video sessions depend more on sustained throughput, packet-loss recovery, and exit capacity. A route that opens webpages quickly may be less suitable for long downloads; a connection that handles sustained downloads well may still take longer to load a page if its initial handshake follows a longer path. Before comparing routes, decide whether you want to reduce initial wait or interruptions during transfer. One word—“fast”—doesn't capture both.

Connection reuse can also affect test results. A client may send multiple requests over an existing connection, and a browser may reuse a session with a destination site. The first page load and a later refresh may not follow the same path. Comparing only the second load can hide an entry-point handshake issue because of caching and reuse. On the other hand, disconnecting everything repeatedly exaggerates the setup cost that may be uncommon in everyday use. Test notes should say whether the connection was new and whether the original page or background tasks remained open.

Map labels to things you can verify

Subscription names often combine a region, a route type, and a purpose label. The region indicates the exit location, the route type describes how the path is organized, and the purpose label offers a selection hint. A label alone cannot prove that a destination service will always be reachable or that a connection suits every task. To inspect the actual configuration, check the protocol, transport, server name, and current rules in the client details. Don't infer every technical detail from a long route name.

Your local connection belongs in the picture too. Wi-Fi signal, router queues, system proxy settings, network changes, and an app's own connection strategy can all affect the result. A client showing “connected” only means that a connection has been established; it doesn't prove every browser request uses the expected exit. In rule-based mode, different domains may take different paths. Global mode may not cover apps the client doesn't manage. When testing, check both whether the request reaches the client and how the target app handles its network traffic.

As you read on, keep asking three questions: Which layer changed? Which stage should it affect? How can you confirm the result came from that change? If you only switch regions, don't also change the protocol and DNS settings. If you're testing the first connection, don't mistake a cache hit for a better handshake. Thinking in layers is more useful than memorizing a protocol ranking, and it helps you explain problems clearly to support staff. For details on available entry points and regions, see the Network Routes. The dashboard shows the configurations currently available to your account.

Stream Protocols: Trade-offs in Authentication, Encryption, and Transport

How to think about Shadowsocks and VMess

Shadowsocks is a proxy protocol, not a complete network-routing solution. Modern implementations commonly use authenticated encryption to protect data, while the client still handles local rules, DNS resolution, and connection management. Its structure is relatively straightforward, but actual resource use depends on the encryption method, processor, and implementation quality. Fewer configuration fields don't necessarily mean lower battery use or greater stability. Use the complete parameters provided by your subscription; don't assemble a configuration based on the protocol name alone.

VMess incorporates authentication and data encapsulation into its protocol design, and compatibility can vary with the implementation and configuration. When troubleshooting a failed connection, check the credentials, client-core support, and system time—not just the route region. Separate the security goals handled by the protocol from the capabilities provided by the surrounding transport. Extra transport encapsulation may suit a particular deployment, but it can also add handshake, buffering, and maintenance costs. More layers don't automatically mean better protection or a better experience.

Where Trojan and VLESS differ

Trojan typically uses TLS to protect proxy traffic, with authentication and request forwarding handled inside the protected connection. Certificate validation and a matching server name are therefore essential to establishing the connection. If the client reports a certificate error, check the subscription, system time, and destination name rather than skipping validation. Disabling validation changes the security boundary. It might make an error disappear, but it doesn't fix the failure to verify the server's identity and shouldn't be a routine connection tip.

VLESS primarily handles authentication and proxy-request signaling; it does not encrypt payload data on its own. Its actual security depends on the surrounding security layer. When you see VLESS, check which transport and security settings are paired with it. The protocol name alone doesn't prove that a setup is unencrypted, nor does it guarantee that every combination offers the same protection. For everyday use, keep the subscription's original settings and let the client connect as required by the server. Don't copy parameters from an unrelated configuration found online.

Why protocols can't be assigned fixed speed rankings

These protocols can run with different transport combinations, so the actual connection process may vary. Reverse proxies, connection reuse, and the way entry and exit points are arranged can all change response times. For a fair comparison, keep the exit region, destination, and local connection consistent, then test the same kind of task. If two configurations follow different routes, the results only show how those configurations performed in your current environment—not a universal performance difference between the protocols themselves.

Processor load isn't determined by protocol headers alone. Hardware acceleration for encryption, frequent memory allocation, overly detailed logging, and a client handling many rules at once can all affect resource use. Differences in processing capacity are easier to notice at high throughput; during light browsing, wake-ups and background keep-alives may matter more. On mobile devices, track battery use, temperature, and task completion together. Don't apply desktop processing results directly to mobile devices.

Prioritize compatibility, successful authentication, and reliable completion of your tasks before considering small differences in overhead. If your client already handles tasks consistently, there's no need to keep changing its core just to try a protocol name. If there's a real problem, keep the original configuration for comparison and make sure any replacement comes from the same trusted subscription. This guide explains technical differences; it doesn't override server requirements. Don't try to create combinations the dashboard doesn't offer by editing protocol fields.

QUIC Protocols: Where Hysteria2 and TUIC Fit

UDP-based doesn't mean unreliable

Hysteria2 and TUIC both use QUIC for proxy transport, but they're distinct protocols, not different names for the same thing. QUIC runs over UDP and implements connection management, encryption, reliable data streams, and congestion control at a higher layer. UDP doesn't mean “lost data is ignored,” nor does it make a protocol automatically suitable for every real-time app. How an app's data maps to transport streams, how the proxy forwards datagrams, and how the receiver handles them all depend on the implementation.

QUIC's multiple streams can reduce the delay between streams caused by in-order delivery, but they can't eliminate competition for bandwidth on a shared link. Lost data in a reliable stream still has to be recovered, and congestion on the underlying network can constrain every stream. So claims like “packet loss doesn't affect speed” aren't accurate. A better way to put it is that transport mechanisms respond differently to packet loss and queuing; the real-world benefit depends on link conditions, congestion control, and the app's workload.

Hysteria2: Match bandwidth hints to route capacity

Hysteria2 deployments may use bandwidth hints to inform congestion control, or use other control methods allowed by the configuration. A bandwidth hint isn't a promise of purchased bandwidth, and a higher value isn't always better. If the sending strategy doesn't match the route's actual capacity, it can push data into upstream queues. Throughput may barely improve while interactive tasks take longer. Don't casually increase parameters for testing. Keep the subscription settings and check whether the network is experiencing queuing or packet loss.

On an unstable wireless connection, a more aggressive sending strategy may reduce idle time, but it can also increase retransmissions, wireless activity, and device heat. Don't judge the results by downloads alone: try an interactive app at the same time and check whether background transfers cause noticeable delays. If interactions improve as soon as a large transfer stops, suspect a queue on the shared link before blaming the destination app. Adjust parameters only on the basis of repeatable observations; don't copy settings from a different network.

TUIC: Check implementation and network support too

TUIC is also based on QUIC, with its own authentication, proxy requests, and data-forwarding behavior. Connection quality depends both on what UDP traffic the network permits and on how well the client and server support the protocol details. If the two ends aren't compatible, the client may show only a generic timeout or authentication error; the message alone doesn't prove a route-capacity problem. First confirm that the subscription was imported completely, then check client-core support. Don't keep switching destination sites to fix an error during the handshake.

Some networks handle UDP differently from TCP. A connection may fail to establish, become idle and drop, or transfer unreliably. Switching to another similar protocol may not help if both face the same underlying restriction. With the device and target app unchanged, compare an available TCP-based configuration with a QUIC-based one. If the difference appears only when you change networks, focus on the connection conditions rather than repeatedly changing authentication or encryption settings.

Connection migration and reconnection aren't the same

QUIC is designed to handle changes in network path, but whether a proxy client can keep a task going after a network switch also depends on the implementation, session management, and destination app. When switching between wireless networks, the exit may change and the app may close its old connection. A protocol's support for connection migration doesn't mean every proxy task will continue uninterrupted. Test whether the task resumes, whether it needs a retry, and whether the client establishes a new upstream session.

QUIC-based protocols are candidates for particular network conditions, not universal upgrade buttons. If UDP works well on your network, the client implementation is mature, and long-running tasks improve, keep the configuration. If you see intermittent failures or increased background battery use, compare it again with a known working setup. Note the device, connection type, and task when recording your results. If conditions change, you'll know which assumptions to retest instead of relying on an outdated ranking.

Network Topology: Direct, Relayed, and Dedicated Routes

Direct routes have fewer steps, not necessarily shorter paths

A direct route usually means the client connects to the named entry point or proxy service without an explicitly arranged intermediate relay. Its structure is straightforward, with fewer service nodes to investigate, but internet routing is still determined by multiple networks. A geographically nearby entry point doesn't guarantee a shorter network path or enough interconnection capacity. If your local provider takes a roundabout route to that entry point, a direct connection may still have a long delay. “Direct” doesn't mean no other equipment is involved in the physical network path.

Direct-route performance is often sensitive to your local connection and its interconnection with the entry point. The same entry point can perform differently across networks, and the same device may get different results on another Wi-Fi network. Judge whether a direct route suits you by whether it reliably handles your usual tasks at the times you need them. If the problem is on the local-to-entry segment, switching the destination region may not help: the network conditions may already be limiting the connection before it reaches the exit.

Relaying changes reachability and performance by organizing the path

A relay sends data to an intermediate entry point first, then onward to the exit. Adding a service hop can increase delay, but it may also avoid a poor interconnection on the original path. Node count alone doesn't tell you which route is better. A relay is useful when its path organization better suits your connection—not because “one more hop makes it faster.” If the entry point is stable but the later segment lacks capacity, a client-side check of the entry may look fine even while real-world access stalls. That's why an entry-point test isn't the same as completing the full task.

Relays add more possibilities to check: your connection to the entry point, the path from entry to exit, and the path from exit to the destination can each have problems. Everyday users usually can't inspect every internal segment, so there's no need to guess which device failed. A more useful approach is to compare another available route with the same exit region and see whether the problem changes, then test another destination app to find out whether it's service-specific. These results help narrow things down better than a connection-status light alone.

A dedicated route describes a transport segment, not the entire internet path

IEPL dedicated routes typically refer to a dedicated Ethernet transport segment within a path. This can distinguish part of the journey from ordinary internet interconnection, but you still need to consider the connection from your device to the entry point and from the exit to the destination website. A stable middle segment won't eliminate local wireless interference or a slow destination server. Think of a dedicated route as one part of the network path—not a guarantee of the same experience across all regions, apps, and times.

A dedicated route is not a substitute for a protocol. Different proxy protocols can use the same transport path, and the same protocol can use different paths. First define the task: do you need responsive interaction or sustained video streaming? Then compare suitable entry and exit points. A topology advantage is of no use if your client doesn't support the configuration. Conversely, if a standard relay works with your protocol and handles the task, there's no need to switch just because another route has a different label and interrupt your current session.

Choose a region by considering both entry and exit points

The region shown for a route usually helps identify its exit, but the entry point may be elsewhere and internal paths may change. The exit region affects the location seen by the destination service; your local path to the entry point affects connection setup. Don't confuse the two. For regional content, consider the exit and account requirements. For remote work, focus on the stability of the whole session. For general browsing, compare how your usual destinations respond. Don't pick one region for every app based only on map distance.

RFCVPN offers 100+ countries / 210+ routes. Choose based on the Network Routes and configurations available in your dashboard. Coverage describes the range of regions and routes you can choose from; it doesn't guarantee continuous access to any particular destination service. Record the route name, network conditions, and results before switching to build a useful guide for your own connection. That's more helpful than simply classifying every route as “premium” or “standard.”

Packet Loss and Peak-Hour Congestion: Capacity, Queues, and Response Times

Packet loss can come from congestion or poor wireless conditions

Packets may fail to arrive as expected because a congested link dropped them, or because of wireless interference, a faulty network device, or a change in path. Reliable transport attempts to recover missing data, but recovery takes time and affects the sending rate. That means lag isn't always caused by “not enough speed”; it can also come from repeated waits for recovery. If your wireless signal is unstable, first compare performance closer to the access point or on a more stable connection. That's often more useful than immediately changing proxy protocols.

Simple probes don't always confirm packet loss. Some devices limit probe responses, so a nonresponsive intermediate hop doesn't mean business traffic was dropped there too. Conversely, a response from the entry-point probe doesn't show that the path from the exit to the destination is working. Relate test results to real tasks: does the page load, does a long-running connection drop, or does a download keep stalling? If the results differ, describe what happened in the task rather than treating one probe as the final answer.

Queues can affect transfers and interactive tasks in opposite ways

When data is sent faster than a bottleneck link can handle it, it waits in a queue. If the queue gets too long, downloads may continue while webpage clicks, voice calls, and remote control feel sluggish. Looking only at throughput can make the route seem fine. A useful check is to pause large transfers on your device and see whether interactions improve. If they do, investigate shared connections, router queues, and competition for bandwidth in the client rather than increasing the sending rate and pushing even more data into the same congested path.

Transport congestion control adjusts the sending rate in response to feedback, but feedback takes time, and different algorithms interpret loss and delay differently. More aggressive isn't necessarily better: if higher throughput also increases interactive delays, that may be a poor trade-off for remote work. Resilience to packet loss doesn't mean there are no extra resource costs. Recovering missing data and maintaining a connection both require processing and communication. Judge a configuration by how well it completes your tasks, not by how aggressively it sends.

Peak-hour slowdowns often involve competition for shared resources

Slowdowns during busy hours can occur on your local broadband connection, at the interconnection to the entry point, on a relay segment, in the exit network, or at the destination service. First check how widespread the issue is. If all apps are slow, including tasks that don't use the proxy, inspect the local connection. If only one exit region is affected, compare another region. If only one destination service is slow, consider its load and your account status. A slowdown at a particular time is a clue, not proof of where the problem is.

To avoid mistaking random variation for a pattern, repeat the same task at the times you normally use it, keeping the device, connection, and destination as consistent as possible. Record whether the task completed, which stage was slow, and whether switching helped—not permanent performance labels for each route. If every route change also clears the cache, restarts the device, and changes DNS, there's no consistent basis for comparison. It may look more “thorough,” but it's hard to tell what actually made the difference.

Separate a slow destination response from slow network transfer

Some requests reach the destination service, but the service still needs time to process, queue, or generate a response. That's an application-side delay, and changing protocols may not help. Check whether lightweight pages in the same app work, whether other destinations respond normally, and whether the service displays a status message. This matters especially for generative tools: streaming output after generation starts and waiting before it starts are different stages. Don't assume the connection has dropped just because content doesn't appear right away.

During peak-hour slowdowns, keep a regular configuration and an alternative on a different path for comparison when a problem actually occurs. There's no need to keep automatically switching a working long-running connection; switching adds its own reconnection cost. If the alternative completes the same task reliably, use it for now and note the time, route, and symptoms. Adjust protocols only after identifying a specific issue, not as your first response to every slowdown. This avoids unnecessary changes and makes it easier to keep a working setup.

Mobile Resource Use: Battery, Background Activity, and Network Changes

Battery use isn't just about encryption

On mobile devices, maintaining a proxy connection uses battery for processor work, wireless communication, background wake-ups, and the app's own activity. Encryption is only one part of the picture. Frequent small requests can repeatedly wake the wireless radio, while long downloads keep the radio and processor active for extended periods; the two use power differently. Comparing protocol names without controlling foreground activity, screen brightness, and network conditions makes results hard to interpret. A better comparison uses similar habits and tracks both task completion and the system's battery records.

With a weak wireless signal, a device may use more communication resources, and retransmissions can keep it active longer. The same protocol can use less power on a stable Wi-Fi connection but generate noticeable heat on an unstable one; there's no contradiction. Frequent client probes, detailed logs, and background refreshes can also cause repeated wake-ups. First check for large background apps and overly frequent checks before deciding whether to change transport. Don't attribute all battery use to proxy encryption.

Background policies affect how long connections stay alive

Mobile operating systems manage background activity according to power-saving policies, permissions, and network-extension capabilities. If a connection drops after you switch away from the client, the cause may be a system restriction or a network device reclaiming an idle connection. First check whether it works normally in the foreground, then compare what happens after locking the screen and returning. If the problem only occurs when resuming in the background, check whether the system allows the required background activity and whether the client handles reconnection appropriately. Don't start by changing the exit region or authentication settings.

Keep-alives maintain idle connections, but more frequent keep-alives mean more wake-ups and network activity. Keeping a connection active at all times isn't always the goal. For occasional browsing, reconnecting when needed may be more efficient than continuous keep-alives. For tasks that rely on long sessions, check how well the app resumes. The server and client may both need to cooperate. Use the subscription and client defaults first, and adjust them only when there's a specific reason.

After switching networks, recheck the exit and app connection status

When switching from Wi-Fi to another connection, your IP address, route, and the session state maintained by network devices may all change. Automatic client recovery doesn't guarantee that the destination app's previous request will continue. Distinguish between the proxy reconnecting, the app retrying, and the destination service requiring you to confirm your session again. If only the current page fails after the switch, retry that task first. Don't repeatedly rebuild every connection based on one failed old request.

The proxy entry point and the app's own connection cache can also delay the visible effect of a network switch. After the client shows the new route, existing app connections may still use the old path until they're closed or restarted. To verify an exit change, make a new request in the app and note whether you needed to reopen it. Before switching during document editing, a meeting, or an upload, save your work. Even if the underlying connection can recover, app-level continuity isn't guaranteed.

Evaluate resource use by task, not protocol name

For browsing and messaging, check how smoothly apps resume in the background and whether they cause frequent wake-ups. For video, track temperature and battery over a continuous playback session. For remote access, focus on recovery after a network change. If your current configuration completes the task and resource use is acceptable, there's no need to switch frequently. A protocol that uses less power on someone else's device may depend on different hardware, implementation, and network conditions; it doesn't establish how it will perform on your device.

RFCVPN supports Windows / macOS / iOS / Android / Linux, with no limit on the number of devices online at the same time. Each platform still has its own system restrictions. Get the client and subscription from the User Dashboard. Sign in to view your subscription; don't submit its contents to public comparison tools. For Windows installation and verification, see How to Set Up a VPN on Windows from Scratch. This section focuses on how to assess differences between platforms.

Choosing for Your Use Case: Set Route Priorities by Task

Browsing and remote work depend on responsiveness and recovery

Everyday browsing involves many short requests, so DNS resolution, the initial connection, and destination response time often matter more than peak throughput for a single file. When choosing a route, start with the sites you use most and check the first page load, in-site navigation, and form submissions. If only one type of resource fails to load, check your rules and DNS instead of switching to global mode as a permanent fix. A page may rely on several domains to provide its content; seeing the main page doesn't mean every related request succeeded. That's another reason an entry-point test can't measure the whole browsing experience.

Remote work depends on sustained interaction, session recovery, and a consistent path. Meetings, remote desktops, and shared documents use different transport methods, so a route that works well for documents may not suit voice calls. Test the apps you use regularly without disrupting active work, and keep an alternative route available. Switching exits frequently during a task may force an app to reconnect or request extra account verification. If the current route handles the task reliably, keeping it unchanged is usually more useful than chasing short-lived differences in test results.

AI Tools: Keep the Exit Consistent and Identify the App Response Stage

Using AI tools involves the network connection, account permissions, service-region policies, and load on the app itself. A route only addresses the network-path portion. First confirm that the sign-in page and basic features work, then note what happens after you submit a request: an immediate error, a long wait, or interrupted output. Interrupted streaming output points toward a long connection or network change; a wait before generation begins may be due to a queue on the service side. Don't assume every app error is caused by the exit, and don't treat a protocol name as a guarantee that an account will work.

For long sessions, keep the exit consistent where possible, and finish or save the current task before changing regions. If browser extensions, system proxy settings, and client rules are all active, identify which one controls routing so some requests don't take a different exit. If a configuration reliably handles the same type of task, keep it as your regular choice. If it only opens the home page but can't perform the actual task, note the stage where it fails instead of just saying “it works.” These notes are more useful for reproducing the issue and getting support.

Streaming depends on the catalog, account, and network

Watching video depends on an exit region that fits the destination service's rules, as well as account status, content licensing, device capabilities, and sustained data transfer. Opening a platform's home page doesn't mean all its titles will play, and switching regions doesn't guarantee the catalog will refresh immediately. Test the specific content you plan to watch. Check playback startup, seeking, and uninterrupted viewing. If only a particular title is restricted, consider content licensing first. If playback keeps stalling, check the full route and shared local bandwidth.

For a Japanese streaming catalog or content from another region, choose an exit based on the title you want to watch, then compare stable routes in that same region. Don't pick an exit in the wrong region just because a test shows lower latency. For more on these use cases, see Japanese Routes and Anime Streaming or Disney+ Regional Catalogs and Route Selection. These articles explain the platform use cases; actual playback still depends on your account, content, and network at the time.

Choose a subscription plan separately from a technical setup

Monthly plans: ¥9.9/month for 60GB, ¥18/month for 250GB, and ¥28/month for 500GB. Data resets monthly on the activation date. Mid-cycle upgrades are prorated for the remaining days. Data add-ons: ¥158/300GB, ¥358/1000GB, and ¥658/3000GB. Add-on data stays available until used and never expires. Compare plans on the Plans & Pricing page based on your usage and routine. Don't infer that a protocol is faster from its price, or assume a higher data allowance guarantees access to a destination service.

RFCVPN's service terms include a no-logs policy, no limit on the number of devices online at once, and a 60-day no-questions-asked refund. Payments are supported via Alipay / WeChat Pay / USDT. No email address is required; create an account with a username and password. These are account, billing, and service details, not a replacement for understanding a protocol's technical limits. Read the Privacy Policy for information about data handling, and the Terms of Service for refund and usage terms. A successful proxy connection doesn't prevent destination websites from processing account and browsing data.

Testing and Troubleshooting: Compare Results and Narrow It Down by Layer

Save a working setup before making changes

Before troubleshooting, note your current client, route name, connection type, target app, and symptoms. Keep the original working configuration. Describe what happened specifically—for example, the subscription won't update, the entry-point handshake fails, webpage resources are missing, or video keeps stalling—instead of writing “it doesn't work.” These symptoms occur at different stages and require different next steps. You don't need to post screenshots of every setting publicly. Always hide subscription links, authentication details, and information that could identify your account.

Change one condition at a time and record the result before and after. First, keep the route fixed and change the network. Then keep the network fixed and change the route. Finally, check protocol compatibility or DNS. If you reinstall the client, switch regions, and change rules all at once, you won't know which change fixed the issue. The point of keeping a comparison isn't to run a complex experiment; it's to avoid mistaking a temporary recovery for a lasting fix and making the whole setup hard to restore next time.

Check the account, configuration, connection, and app in order

First check the account and plan status in the dashboard, then confirm that the subscription updated successfully and that the client recognizes all required fields. If the client doesn't support a protocol, check compatibility through the official client source. Don't force an import by deleting configuration fields you don't recognize. If a subscription update fails, distinguish between a sign-in or request failure and a parsing failure: the former concerns fetching the subscription, the latter concerns reading its contents. Only investigate the handshake and service access after the configuration has imported correctly; otherwise, later tests don't have a valid starting point.

For an authentication failure during connection setup, check that the subscription contains a valid configuration for your account. For a certificate error, check the system time and server name. For a timeout, compare the network, entry point, and transport conditions. Don't assume every error means the password is wrong, and don't disable certificate validation to bypass an error. Client logs can help identify the stage, but keep only the excerpts relevant to this task. Excessive logging adds noise and may expose browsing details you don't need to share.

Use the actual request path to diagnose DNS issues

DNS resolution may be handled by the operating system, browser, client, or a remote service, depending on the current mode. Successfully resolving a domain only means an address was returned; it doesn't prove that address is suitable for the current exit. A DNS failure doesn't necessarily mean there's a problem with the remote route either. First identify which component handles resolution, then check for caching, mismatched rules, or conflicting routing. Changing every DNS address at random can turn a local issue into a new inconsistency, especially when the app and client follow different policies.

If the home page loads but sign-in, images, or video endpoints fail, check whether only the related domains aren't being handled as expected, then test a new request. After changing rules, existing connections and cached data may continue using the old behavior. Distinguish between saving a setting and starting the task again. Clearing all app data shouldn't be your default first step; it can discard sessions and add more variables. Save your work, close the affected task, and retry to keep any changes limited and easier to explain.

Draw conclusions that others can verify

Useful feedback includes when the issue occurred, the network conditions, route name, specific task, stage of failure, and any one-at-a-time comparisons you've already tried. If a route behaves differently on different networks, say so. If only one destination fails through the same exit, include that detail too. Don't describe one successful retry as a permanent fix, or one failed attempt as proof that a whole protocol doesn't work. State the conditions your conclusion applies to so support staff can continue the investigation without repeating the same steps.

If you need more help, visit the Help Center or, after signing in, submit the necessary details through a support ticket in the dashboard. If you're new and haven't yet retrieved or imported your subscription, return to the Quick Start Guide and follow the steps in order. The key ideas here are to think in layers, keep the task consistent, and compare one change at a time: restore a working setup first, identify what caused the difference, and keep notes on the configuration that suits your device and network. Avoid relying on protocol rankings detached from real use.