VPN Protocols and Network Routes: Technical Guide

How Protocols, Transports and Traffic Routing Differ

Break the connection into observable stages

When you open a web page, the browser first resolves the destination address, establishes a connection, then sends a request and receives the response. Using a proxy adds several steps: the client checks its rules, connects to an entry point, encapsulates the request, and reaches the destination through an exit point. A page that takes too long to load could be delayed at any of these stages. A protocol name describes an encapsulation method; it does not tell you about entry-point quality, exit location, DNS resolution or the destination server’s response time. Separate these layers to narrow down the cause.

You can follow the request through the chain: “app request → rule match → entry connection → transport path → exit to destination.” Rules determine which requests use the proxy. The entry point is where your device connects; the exit point is the apparent source of traffic seen by the destination service. They may be in different regions. A region label in the client usually describes the exit point’s purpose. It does not tell you the physical distance from your device to the entry point, nor does it predict response times for every website.

Protocol support and service support are not the same

Shadowsocks, VMess, Trojan, VLESS, Hysteria2 and TUIC each have their own client implementations and deployment requirements. This page covers general design principles; it does not mean every F4VPN route supports every protocol. Check the subscription provided in your dashboard and confirm compatibility with your client to see what is actually available. If a protocol is not included, do not try to connect by editing protocol fields manually: authentication, transport and server listeners must all match.

The same protocol can use different transports, and the same transport can run across different routes. When you see a protocol name, check whether it relies on a reliable byte stream or datagrams, which layer handles encryption, and whether traffic passes through additional relays. Comparing protocol abbreviations alone can make a route’s capacity look like a protocol advantage. For a reproducible comparison, keep the exit point, app and network conditions as similar as possible, and change only the factor you want to test.

Routing modes change the path, not your account permissions

Rule-based mode routes traffic by domain, app category or address range. Global mode attempts to send a broader range of requests through the selected exit. Neither mode is a speed setting. If an app works in global mode, check its routing rules, DNS resolution or traffic capture; that does not mean global mode is always better. Sending local traffic to a remote server can add detours, use plan data and make nearby services select more distant content servers.

DNS resolution also affects routing. An app may resolve addresses itself, the client may use a separate resolver, and the system may still have an old cache. If routing rules rely on domains but the client only sees an address, check whether it can identify the destination correctly. Clearing your browser cache alone does not refresh every DNS cache. App connection reuse, the system cache and the client cache are separate; check each according to the client’s documentation.

Security also needs to be understood layer by layer. Proxy encryption protects traffic between your device and the relevant server; the encrypted connection to the destination website still matters. F4VPN uses the term “quantum encryption” as a trust claim, but the label is no substitute for checking the specific protocol, certificate and implementation. It also does not mean every protocol uses post-quantum algorithms. The sections below focus on the responsibilities of each layer, rather than ranking protocols outside their operating conditions.

Shadowsocks, VMess and Trojan

Shadowsocks: Check that the encryption method matches the implementation

Shadowsocks passes app traffic to a proxy server using agreed encryption and authentication methods. Its configuration is often straightforward, but fewer settings do not mean every implementation works the same way. Encryption methods, datagram handling, address resolution and plugin requirements can all affect compatibility. If an imported profile reports an unsupported method, check what your client supports instead of substituting a similarly named method. Similar names do not guarantee compatible key or data formats.

Shadowsocks resource use depends on the device’s processor, encryption implementation and traffic pattern. Devices with suitable hardware acceleration may handle some encryption tasks more easily; others may hit processing limits during sustained transfers. A short web request also puts a different load on the device than a long file transfer. Good performance on a desktop does not guarantee the same results on a mobile device in the background, at low battery or under thermal constraints.

How it carries app data also depends on the underlying transport. Reliable byte-stream connections handle ordered delivery and retransmission; datagrams work differently. Being able to open a web page only shows that the relevant request path works. It does not prove that voice calls or other datagram-dependent services will work too. If some app features work and others do not, check whether the client captures the relevant traffic and whether the exit supports that kind of forwarding.

VMess: Authentication, clock settings and additional encapsulation

VMess combines user authentication with proxy request encapsulation, and deployments may layer on different transports. It is not a fixed network route, and its name alone cannot tell you whether it suits a particular region. If authentication fails, check client and server compatibility, subscription integrity and the system clock. A device clock that is significantly out of sync can affect relevant authentication mechanisms and cause certificate validation failures in other encrypted connections.

Adding another transport layer to VMess means the connection must complete the corresponding negotiation, creating more potential failure points. A basic connection that succeeds but fails during later authentication is different from a failure to reach the entry point at all. Check logs for DNS errors, connection timeouts, handshake failures and authentication rejections. Calling all of these “a slow node” hides the cause. Switching exits repeatedly may not fix a local clock or client compatibility issue.

Trojan: A connection protocol built around TLS

Trojan typically uses TLS to establish encrypted transport, then authenticates and forwards traffic according to its protocol. Certificate validation, server names and server configuration are therefore important troubleshooting points. Reaching an address does not guarantee that TLS negotiation will succeed. An expired certificate, a name mismatch or an issue with the local trust store can end the connection before the app request is sent. Check the subscription and system environment; disabling certificate validation is not a routine fix.

TLS secures the connection layer; it does not automatically increase route capacity. A correctly configured Trojan connection can still be limited by congestion at the entry point, the return path from the exit or the destination’s response time. Connection reuse and session resumption may reduce the setup cost for later requests, depending on support from the client, server and intermediate devices. Do not compare a fast response on a warm connection directly with the wait for a first connection using another protocol.

Choosing between the core protocols

For everyday browsing and common apps, choose an option your client supports natively, with a complete subscription profile and stable performance on your network. That matters more than chasing a protocol name. If protocols use different entry or exit points, the results compare entire connection setups, not protocols in isolation. Record the route label, transport, use case and type of error for meaningful comparisons. For a quick introduction to subscriptions, nodes and protocols, see the VPN terminology glossary, then compare the relevant fields in this chapter.

Trade-offs when pairing VLESS with a transport

A lightweight protocol is not a complete security solution

VLESS keeps the representation of proxy requests and authentication information relatively simple, but it does not provide complete transport encryption by itself. Security depends on the transport protection and correct deployment. So “using VLESS” is an incomplete technical description: you also need to know which transport carries it, how the connection is validated and whether the client supports that combination. Claims of stronger encryption or lower resource use based on the protocol name alone lack essential context.

This separation allows different combinations, but makes compatibility checks more important. Read the transport type, service name, path, server name and related settings in a subscription as a whole. You do not need to enter each field manually, but deleting fields at random can change how the connection works. If a client reports that it supports VLESS but cannot connect, it may support only some VLESS combinations; the account, password or plan may not be the problem.

Reliable byte streams and application-layer transports

TCP-based transports provide a reliable, ordered byte stream for common uses such as browsing and file transfers. When packets are lost, missing data must be retransmitted, and later bytes may have to wait for the gap to be filled. For interactive apps, that wait can be more noticeable than average throughput. If a proxy carries many requests over one connection, fluctuations in the underlying link may affect them all. Consider how multiplexing works to understand the scope of a brief slowdown.

Once established, WebSocket provides a two-way messaging channel for forwarding data in compatible application-layer environments. But the extra encapsulation and forwarding steps have a cost. The experience depends on whether a reverse proxy is involved, whether idle connections time out and whether the upstream can keep forwarding. WebSocket can help with deployment compatibility, but it cannot create more available bandwidth. Compare the entire transport path, not just the name of the encapsulation.

Application-layer transports such as gRPC also depend on how streams, sessions and intermediate relays behave. Some environments reuse connections effectively; others may be affected by proxy timeouts or implementation differences. A client recognizing a node does not mean every type of traffic suits that transport. If long-lived connections drop while new short requests work, check idle connection handling, network changes and intermediate devices instead of simply increasing app concurrency.

Connection reuse is a situational choice, not a universal speed switch

Connection reuse lets multiple requests share an existing connection, reducing repeated handshakes and connection-management overhead. This can help when frequently loading small resources. But sharing also means requests can affect one another: a blocked or restarted underlying connection may disrupt more than one request. Start with the server configuration and the client’s default policy. Do not change reuse, DNS, exit and transport settings at the same time, then guess which one helped.

When assessing connection setup time, distinguish a cold start from ongoing use. A cold start may involve DNS resolution, connection setup, encryption negotiation and authentication; later requests may reuse an existing connection. Browser caching and connection pools can also affect page reloads. A useful test records the first visit, normal browsing and recovery after an idle period separately, along with the conditions. These answer different questions and should not be reduced to one “connection speed” figure.

If a combination works on desktop but fails on mobile, first check whether both clients support the same core protocol and transport rather than copying every advanced setting. Identically named switches can mean different things in different clients. Reimport the profile provided in the dashboard and keep its defaults. If the issue continues, note whether it occurs before connection, during the handshake or while carrying app traffic. That is more useful than sending many configuration screenshots and helps avoid exposing subscription credentials.

Hysteria2, TUIC and QUIC transports

Datagrams and reliable transport are not mutually exclusive

Hysteria2 and TUIC both use QUIC-related mechanisms to build proxy transports, but they are different protocols and their configurations are not interchangeable. QUIC typically provides encrypted connections, stream management and congestion control over UDP datagrams. Using datagrams underneath does not make application data inherently unreliable; reliable streams and datagram forwarding can have different semantics. Understanding this helps avoid equating “uses UDP” with low latency or assuming packet-loss recovery means retransmissions are unnecessary.

QUIC’s stream model can reduce direct head-of-line waiting between streams when data is missing, but congestion still shares network capacity. Poor wireless signal, queued traffic or a busy exit can affect every service. QUIC addresses specific transport issues; it does not remove bandwidth limits. If an app itself sends requests sequentially over a single chain, separate streams underneath may not deliver any noticeable benefit from concurrency.

Hysteria2: Congestion control needs realistic inputs

Hysteria2 performance depends on congestion control, bandwidth settings and network conditions. If the configuration requires a manual bandwidth value, use a realistic estimate of sustainable capacity, not the theoretical peak advertised for your connection. Setting it too high can cause queueing and extra packet loss; setting it too low can limit transfers. If the dashboard provides the setting, leave it as supplied. Without reliable evidence, do not copy aggressive values from someone else’s setup.

In networks with variable conditions but some available capacity, an appropriate strategy may improve sustained transfers. That does not mean it always uses less data or battery. Retransmissions, keepalives, encryption and user-space processing all consume resources. If downloads improve but other devices become noticeably less responsive, check local queueing and shared network load too. One task saturating the link is not proof that the overall network experience has improved.

TUIC: Sessions, forwarding and client implementations

TUIC requires compatible client and server behavior for authentication, sessions and forwarding. Performance depends on implementation quality, datagram forwarding and congestion control settings. The fact that it uses QUIC does not mean it performs like Hysteria2. Import the complete configuration provided by the subscription. If the client does not recognize a field, check its support rather than replacing the protocol name with a similar option.

Connection reuse and session persistence can reduce some setup costs, but network changes can still disrupt them. When a device switches between Wi-Fi and a mobile network, its source address, port mapping and routing may change. QUIC can handle connection migration at the protocol level, but whether a proxy recovers smoothly depends on the client, server and network devices. Underlying support for migration is no guarantee that an app’s long-lived session will stay connected.

Start with compatibility, then compare efficiency

Some access networks handle datagrams differently, with distinct forwarding, rate limits or idle timeouts. As a result, QUIC-based protocols may fail to connect, work briefly and then stop responding, or recover only after a network switch. First compare with another access network to see whether the issue follows the network. If it occurs only in a particular environment, keep a compatible backup route rather than forcing every app to use the same transport.

Packet size can also be a limiting factor. Encapsulation adds overhead, and poor handling of larger datagrams along the path can cause small requests to work while larger transfers fail. This is a troubleshooting lead, not a definitive diagnosis. Cross-check logs, different apps and different access networks before making adjustments as described by the client. Changing low-level size settings at random can extend a local issue to every connection and make later comparisons less useful.

Choose based on a combination of success rate, stability, responsiveness and device load. Sustained downloads help assess throughput and congestion recovery; chat, browsing and remote work depend more on consistent response times. A protocol that stands out in a speed test but frequently reconnects in your everyday apps may not be the right default. For a repeatable test method, see How to Test VPN Speed and record the conditions rather than relying on impressions.

How direct, relayed and private routes differ

First identify the relationship between the entry and exit points

A direct route usually means your device connects straight to the remote service’s entry point, without an additional relay arranged by the provider. The internet still consists of many networks, so “direct” does not mean a dedicated physical cable. The route and return path can change with carrier routing. Direct routes have a simpler structure and fewer troubleshooting steps, but rely more on the public path between your access network and the remote entry point. Performance may differ at peak times.

A relayed route adds an entry or forwarding node between your device and the final exit. Requests first reach a more suitable point of entry, then continue to the remote destination. The extra steps can add processing and transmission time, but may improve the overall experience if the route is better. Counting nodes alone cannot tell you latency. A short geographic distance may involve a detour, while a longer logical route may use better peering. The actual path matters more than its label.

A private line describes how a link is arranged, not unlimited capacity

An IEPL private line generally describes a network arrangement using a dedicated Ethernet link between locations. It can help control delivery and routing across that link, but end-to-end access still includes the connection from your device to the entry point and from the exit to the destination. A private segment does not eliminate congestion on local Wi-Fi or slow responses from the destination. Treat the route label as a clue to topology, not a guarantee for every app at every time.

Private lines still have capacity-planning, shared-use and equipment constraints. A route name alone usually does not tell you how bandwidth is allocated, so do not assume “private line” means exclusive use. Long-term fluctuations, the scope of failures and recovery behavior are more useful when evaluating a route. If only one destination is affected while other services work normally, check the path from the exit to that service or the platform’s policies before concluding that the entire private line has failed.

Geographic proximity is not the same as a good route to a service

Choosing an exit also means considering where the destination service is hosted. A fast connection from your device to the exit does not help if the connection from the exit to the destination is slow. Global content services may assign different content servers to different exits; account region and platform policies can also affect the result. Choose a region based on the app you use rather than simply picking the nearest-looking option in a list. For services with regional requirements, meet those requirements first, then compare suitable routes.

The forward and return paths may differ. Data going to a destination may take one route, while the response takes another, so observing only one direction cannot explain every issue. Intermediate devices on a route trace may also give diagnostic requests a lower priority. A delay at one hop does not by itself prove that app traffic is being delayed or dropped there to the same degree. Compare the destination’s response, app logs and other targets before drawing a strong conclusion from a partial trace.

If local access is fine but every remote route fluctuates, check the access network and client first. If only routes sharing an entry point are affected, investigate that entry point or the shared path. If a target app fails only through a particular exit, check the exit-to-service path. Narrowing down the issue by its scope is more efficient than repeatedly switching countries. When you switch routes, note the label and time so you can reconstruct the conditions later.

F4VPN covers 90+ countries and 220+ routes, giving you a choice of regions; this does not mean every region has the same protocols, topology or app compatibility. Check the route list for specific options rather than inferring the capacity of an individual region from the total. Keeping a trusted default route and a clearly chosen backup is usually easier to manage than saving many untested exits, and saves time when troubleshooting.

Troubleshooting Connection Setup, Packet Loss and Peak-Time Congestion

Turn “slow” into a symptom you can diagnose

“Slow” might mean a long wait before a page starts loading, a fast start followed by repeated pauses, or slow browsing even though large file transfers work well. For the first, check DNS resolution, connection setup and server response time. For ongoing pauses, look at packet loss, queueing and app buffering. Describe where the problem occurs before choosing a tool. Otherwise, a speed test may show good throughput without measuring the wait that is actually disrupting your workflow.

Connection setup involves DNS resolution, a transport handshake, encryption negotiation and authentication; the time to the first byte also includes processing by the destination service. A first visit is often more involved than a request on an existing connection. When comparing, distinguish a fresh start, continuous use and recovery after idle time rather than averaging them together. If the first request often fails after idle time but works after reconnecting, the cause may be idle connection cleanup, address mapping or client recovery, not sustained congestion at the exit.

Packet loss triggers recovery and can change the sending rate

Packet loss means some data did not arrive, and may trigger retransmissions and congestion control that reduce the sender’s rate. Reliable transport can eventually recover the data, but you may still notice pauses. Wireless interference, queue overflow, device load and route problems can produce similar symptoms. One test alone cannot prove a route is poor. Check whether the issue persists, affects the destination service and remains after switching access networks.

At peak times, several parts of the path may approach capacity at once: home internet, Wi-Fi, shared entry points, peering links or exits. Queues can grow and delay interactive traffic even before throughput drops. Sustained high-volume tasks can also crowd out other apps. Pause tasks that are using a lot of local bandwidth, then check whether browsing and real-time apps recover. This helps avoid blaming the remote service for competition within your own network.

Use a repeatable comparison sequence

First check ordinary local websites and your system’s network connection. Then confirm the client’s connection status and compare routes using the same app. If every route has the same issue, test with another device or access network. Change one major condition at a time and record the app, exit label, connection mode and error. This gives you useful evidence for the next step. Changing the client, DNS and protocol all at once only creates differences that are hard to explain.

Choose tools to answer a specific question. DNS lookups check whether a domain resolves. Connection logs show setup and handshakes. Browser developer tools help distinguish waiting from downloading. Route traces can help explain routing, but intermediate nodes may not respond to diagnostic requests. Speed tests mainly measure the selected test server, not every app. Test traffic counts toward actual usage, so avoid repeatedly running data-heavy tests to confirm an issue you have already identified.

Narrow down the cause by where the failure occurs

If the entry point cannot be reached, check DNS, the access network and service availability. If the handshake fails, check the system clock, certificates and transport compatibility. If authentication is rejected, confirm that the subscription is up to date and check your account status. If the connection succeeds but a particular app fails, check the rules, exit and destination service. Error messages are not a final diagnosis, but they help guide the next step. Reinstalling the client for failures at every stage is often costly and loses useful information.

If latency is stable but content loads slowly, check the destination’s response and throughput instead of searching for a lower-latency route. If throughput is fine but interactions lag, look at concurrent tasks, queueing and the app’s sequential requests. If only one region is affected, try a backup exit the service allows. If every region is affected, start with the local steps they share. This approach cuts down on unnecessary switching and makes support reports easier to verify.

To report an issue, use a dashboard support ticket and include reproducible steps and comparisons you have already tried. There is no need to upload a full page containing private information. Explain what you did, what happened and whether anything changed after switching conditions—not just that a route is “unstable.” For common connection issues, see the Help Center. To track performance over time, compare different usage periods using the speed-testing guide instead of treating one result as a long-term conclusion.

Mobile battery use and client resource consumption

Power use comes from the entire processing chain

When a mobile device runs a proxy, power use comes not only from encryption but also from wireless transmission, data copying, user-space network processing, keepalives and reconnects. Background apps may also generate proxy traffic as they sync. So power use for the same protocol cannot be compared directly across different devices. Even on one device, signal strength, screen state and app load can make a noticeable difference. Check for continuous data transfer before focusing on protocol overhead.

Weak signal makes the wireless link work harder, while frequent network changes trigger recovery and new connections. The access environment may be the main cause of what looks like high client power use. Compare behavior under a stable signal and similar app load with the original conditions. Do not run a continuous download while judging battery life based on an idle-use experience; the amount of network and processing work is different.

Platform behavior determines what happens in the background

iOS manages network extensions through its system lifecycle, so the app interface and background connection are not always in the same state. A network switch, low system resources or an extension issue may require a new connection. Check system connection status alongside client logs instead of relying only on the icon on the app’s home screen. Profiles, client imports and system permissions are separate steps. For initial setup, follow the Quick Start Guide so you do not mistake a missing permission for a protocol compatibility issue.

Android background limits, battery optimization and differences in process management can affect persistent connections. If a connection drops when the screen turns off, first check whether the client has the system permissions it needs to run normally, then check for restrictions on background network access. Relaxing restrictions may help maintain a connection but can also keep the app running longer in the background. Choose settings based on your needs. Disabling every battery-saving option is not a universal fix, and similarly named settings may behave differently across systems.

Use keepalives and automatic checks sparingly

Keepalives can help maintain connection state, but frequent ones may wake the wireless radio and add background traffic. Automatic speed tests and health checks also send requests, and checking too often can keep the device working continuously. Start with the client defaults for everyday use and adjust only after reproducing a problem. Do not enable every advanced switch labeled “stable.” Multiple checks running at once can cause more route changes and make issues harder to trace.

Traffic rules can send local requests directly, avoiding unnecessary detours and proxy processing. But fewer rules do not always use less battery, and more rules are not necessarily more accurate. Rule updates, matching behavior and app request patterns all affect resource use. Use rule sets with clear sources and purposes, and avoid piling on duplicates. If a local app has an issue, check the matched rule and DNS result before routing all traffic through the proxy globally.

A virtual network interface can capture traffic from a wider range of apps, but adds interactions with system routing, DNS and other network tools. Running several traffic-capture tools at once on a desktop can cause request loops, inconsistent exits or DNS confusion. If an issue appears, keep one clear traffic-capture entry point and restore other tools one at a time. Global capture and system proxy settings cover different traffic, so a switch label alone cannot tell you whether an app actually goes through the client.

F4VPN supports Windows / macOS / iOS / Android / Linux and allows unlimited devices, but device performance and network conditions still vary. Unlimited devices does not mean unlimited shared network capacity, nor does it mean every platform uses the same core. Download clients from the client downloads page in the dashboard. When comparing resource use, note the platform, access method, app load and background state; these details are more useful than the protocol name alone. For account and subscription security, see the VPN Safety Guide.

Choosing Protocols and Routes by Use Case

Web browsing and AI tools: Check for consistent responses

Everyday websites load many small resources, so request setup, DNS and connection reuse can matter more than sustained throughput. AI tools may also use connections that stream responses, where a brief interruption can stop output or force a retry. Prioritize routes that respond consistently during your usual hours and recover properly in your client, then consider the protocol combination. The exit region must also comply with the service’s terms. Network access does not replace account eligibility, service permissions or regional policies.

For these apps, start in rule-based mode and confirm that the target domain is routed through the proxy. Then compare sign-in, page loads and persistent sessions. If a page loads but a request fails, check the app’s response, related domains and long-lived connections rather than assuming there is not enough bandwidth. Switching protocols can address transport differences, but it cannot fix the destination service’s account status. A stable backup exit that the service allows is easier to troubleshoot than frequent region changes.

Streaming and large files: More than sustained throughput matters

Streaming needs continuous data transfer and is also affected by how the platform checks your exit, account and content region. A route that connects does not guarantee that the content will be available, and smooth playback does not mean every resolution will remain stable over time. Check the platform and exit in practice, then observe playback over an extended session. For content regions, platform messages and exit selection, see the Streaming guide. General protocol information is not a promise that specific content will be available.

Large file transfers can expose limits in sustained throughput, device processing and competition for shared links. Check whether other apps slow down during the transfer and recover when it stops. If a download saturates your local connection, changing protocols may affect congestion behavior but not resolve the underlying queue. Scheduling transfers and managing concurrency is often more useful than simply looking for a route with higher peak throughput. Protocols cannot replace capacity planning; assess test results alongside the apps you actually use.

Real-time apps and network changes: Prioritize stability

Remote access, voice and real-time collaboration are sensitive to jitter and interruptions, so higher throughput may not help. First check whether the app relies on datagrams and whether the client captures its traffic correctly, then compare continuity under the same conditions. For mobile work, also test recovery after leaving Wi-Fi. Underlying connection-migration mechanisms can help, but cannot guarantee that every app session will survive. For important work, follow the app’s own save and reconnect procedures.

You can organize your everyday setup into a default route, a backup for a specific purpose and a compatible option for networks that restrict datagrams. These are maintenance categories; your subscription does not need to include any particular protocol. For each option, note the apps it suits, exit requirements, client support and known limitations. Avoid keeping lots of untested advanced configurations, or adding options that are not in your subscription just to make it look complete. Real-world compatibility matters more than the name.

Keep network choices separate from plan choices

Protocols determine connection behavior; plans determine data allowances and billing. They are not speed tiers. F4VPN 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 by the remaining days. Data packs: ¥158 for 300GB, ¥358 for 1000GB and ¥658 for 3000GB. They last until used and never expire. See the plans page for full details. Do not use a single speed test to estimate data needs for every future use case.

F4VPN offers a 60-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 service facts, not protocol performance metrics. Before comparing options, check your platforms, commonly used apps and main access networks, then choose a data plan that suits your needs. For a checklist of what to verify before paying—including refunds, route details and support channels—see the VPN Subscription Buyer’s Checklist. Read verifiable terms separately from general claims.

Keep a short record of the platform, protocol combination offered by the client, route label, main app, failure stage and comparisons already tried. After a subscription update, check whether the previous setup still works and revisit the relevant section if anything changes. This gives you a connection setup you can explain, not a growing pile of switches. To import a profile again, return to the Quick Start Guide. To check available exits, see the route list. This page explains the technical limitations behind those choices.