Cross-Border NetworkingTroubleshooting Guide

Establish a troubleshooting baseline: Define the problem boundary first

The same phrase, “I can’t connect,” can describe very different problems: the client will not start, the connection button does nothing, the connection process stalls, the system says it is connected but websites do not load, or only one app is inaccessible. Before taking action, rewrite the symptom as a testable statement, such as “No route connects on my home network” or “The browser works after connecting, but the desktop app has no traffic.” The more specific the description, the easier it is to eliminate unrelated causes.

Record the environment before changing settings

Keep the current client screen, route name, network type, and exact error text. Each word in an error can point to a different layer: authentication messages often relate to the account or subscription, timeouts are more likely to involve the network path or route setup, and resolution messages call for a DNS check. Do not capture only a dialog title or describe everything as simply “stuck.” Full context is more useful than an isolated error code.

Next, confirm that ordinary networking works. Disconnect, then try a website that normally opens without the service. If regular websites also fail, restore the local network first instead of continuing to switch routes. On the same device, compare the current network with another trusted network. If the issue disappears after changing the access method, the scope is narrowed to the original network. If it remains, continue checking the client and subscription.

Change one variable per test round

A useful test keeps all other conditions unchanged. When testing routes, do not also change networks, switch protocols, and clear the subscription; even if service returns, you will not know which change helped. A safer sequence is to keep the client and subscription unchanged while switching only the route; then keep the route unchanged while changing only the network; only afterward check the system proxy, DNS, or re-import the subscription. After each change, disconnect and establish a fresh connection so the old session does not preserve the previous state.

Also distinguish an intermittent issue from one that reproduces consistently. For intermittent problems, record the context: waking from sleep, switching between access points, or bringing an app back from the background. Consistent problems are suited to a fixed sequence of steps, with the first abnormal step noted. Do not rapidly press the connection button repeatedly to reproduce an issue; overlapping requests can desynchronize the client interface from the actual connection state.

Confirm account details and traffic status

CavaVPN supports Windows, macOS, iOS, Android, and Linux, and has no device limit, so the number of devices should not be mistaken for an overage. If a third-party client shows a device-related message, first confirm where it comes from and what it actually means. It may refer to the client’s local configuration, duplicate sessions, or leftover settings, rather than a CavaVPN plan limit. Check the user panel to confirm that the plan is active and traffic remains available before investigating the connection layer.

Monthly subscription traffic resets each month on the activation date; traffic packages remain valid until used and never expire. During troubleshooting, rely on the actual status shown in the panel rather than guessing from calendar dates. If the plan status, remaining traffic, or subscription content differs from what you expect, save a screenshot of the panel before updating the subscription. Only after these baseline checks should you move to the relevant symptom section, keeping account, route, and client issues separate.

Cannot connect at all: Troubleshooting a connection that will not establish

“Cannot connect at all” means the client is open, but after selecting a route it never reaches a stable connected state. Do not focus on the target website yet; the data channel has not been established. Check whether the client has a valid configuration, whether the system allows network connections, whether the local network is interrupting setup, and whether the selected route suits the access path.

Start with the client state, not a reinstall

Fully quit the client, then open it again. Quitting does not mean merely closing the window; confirm that no old instance remains in the notification area, menu bar, or background processes. If an abnormal session is still running, a new window may continue using the old process. It can appear disconnected while the underlying state remains uncleared. After reopening, select one known-good route and wait for a clear status change. Do not rapidly switch between regions during connection.

If the connection button does nothing, check whether a system permission prompt is hidden behind another window. The first network connection may require approval for a network extension, virtual network interface, or administrator access. After permission is denied, the client may still show the route list but cannot take control of networking. Open the system network and privacy settings and confirm that the relevant component is allowed. Then quit and restart the client so it rereads the permission state.

Use route comparisons to separate one-route issues from global issues

In the Route List, choose another route in the same region for comparison. If only the original route fails while others connect, the client, account, and basic network path are probably working; avoid the affected route for now and record its name. If every region fails, prioritize the network environment, system permissions, subscription contents, and local security policies. Do not keep switching routes without a hypothesis.

Repeat the same steps on another trusted network. If the original network fails but the other network works, the difference lies on the access side. Enterprise, hotel, and public networks may apply stricter policies to certain connection methods, long-lived connections, or unfamiliar traffic. Use compatibility options provided by the client or choose another route type. Do not modify unknown system settings or disable system protection wholesale; instead, check each explicit network authorization prompt.

Check that the subscription has fully loaded

A client showing a group name does not guarantee that the subscription is complete. Check whether route names are blank, only old routes remain, the last update time looks abnormal, or an authentication or resolution message appeared during the update. If the subscription did not load, follow this page’s “Subscription update failed” section. Do not add multiple copies of the same subscription; duplicate groups make it impossible to tell which configuration the current connection uses.

If you recently changed your password, retrieved a new subscription, or adjusted the plan in the panel, the client may still have the old configuration cached. Delete the invalid local subscription entry, then copy and import it again from the user panel. Never share the subscription URL in public chats, screenshots, or forums. After importing, refresh the route list before connecting. Refreshing without reconnecting may leave the current session using old parameters.

When to stop local troubleshooting

When routes in different regions and on different networks all fail, while the subscription updates normally and the account is in good standing, further reinstalls are unlikely to help. Keep the client logs, full error text, route name, device platform, network type, and time, then submit a support ticket. Cover subscription URLs, usernames, and access credentials in logs first. Support needs a reproducible path and the original error, not a summary rewritten several times.

Before submitting, perform one clean verification: quit all similar clients, restart the current client, keep only one subscription, select one route, and wait for a definite result. If it still fails, include this exact sequence in the ticket. Such a record helps distinguish a route-side rejection, client initialization failure, and local network timeout better than simply writing “all routes are unusable.”

Connected but websites will not open: Check the proxy and DNS layers separately

A client showing “Connected” only confirms that the connection process completed; it does not prove that the browser, system proxy, and name resolution are configured correctly. Common symptoms include every domain failing, some sites working while new domains fail, the browser working while other apps have no traffic, or regular networking remaining broken after disconnecting. Check the connection layer and application access layer separately.

First determine whether DNS resolution failed or there is no traffic overall

Open a command-line tool and test domain resolution and an ordinary network request separately. The commands below use public example domains, contain no real subscription URL, and do not change system settings. Command names vary by system, but the goal is the same: confirm that the system can resolve a domain to an address and send a request after establishing a connection.

nslookup example.com
curl -I https://example.com

If the domain lookup fails and the network request reports that the host cannot be resolved, check DNS first. If the domain resolves but the request still times out, continue with the system proxy, route, and local network. Command-line results do not fully represent browser behavior because browsers may use their own cache or resolution method; compare the command line, browser, and another app together.

Clear stale state after switching connections

Web tabs, downloads, or apps with long-lived connections that were open before connecting may keep their original network sessions. Close the target page or quit the app process, then reopen it for testing. Refreshing alone may let the browser reuse the old connection. When switching routes, disconnect first, select the new route, establish the session, and then restart the target app. This prevents old and new exits from being active at the same time.

If ordinary networking still does not recover after disconnecting, the system proxy may not have been cleared. Quit the client normally and check whether the proxy settings still point to a local process that has ended. Do not enter arbitrary proxy addresses or copy unknown parameters from online articles. Confirm that no other network tool is managing the system proxy, test an ordinary website in a freshly opened browser, and then start CavaVPN again.

Typical boundaries of a DNS issue

DNS issues usually have a clear boundary: domain lookups fail while already connected apps continue transferring data; sites visited recently work while new sites do not; or switching routes restores access briefly before resolution errors return. When this happens, disconnect, quit the client and browser, and establish a fresh connection. This lets the system, client, and browser obtain a consistent resolution path.

If the client offers connection-managed DNS or system resolution options, keep a single source of configuration. Multiple tools rewriting resolution settings can send requests along competing paths. Managed devices may enforce fixed resolution policies; do not override them, and ask the administrator which network methods are allowed. On a personal device, temporarily quit other network filters, parental controls, or local proxy tools for comparison testing.

Browser cache and target service status

When only one website fails, do not assume the entire route is broken. Test other sites in the same region, then use a private browser window to rule out cache, extensions, and stale login state. The target service may respond differently based on account region, content licensing, or its own risk controls; that is separate from whether the network path is connected. If several unrelated sites work normally, the basic connection is available, so check the target service and account settings.

If every device shows the same resolution error on one route but recovers immediately on another, record the affected route and switch away from it temporarily. If only one device is affected, check that device’s system proxy, DNS, and local software conflicts first. In a ticket, specify whether the issue affects all domains, some domains, or one website, and include the privacy-safe portion of the command output rather than only the browser’s generic error page.

Slow speeds and peak-hour congestion: Separate route, access, and app bottlenecks

Speed is easily affected by several layers at once. Local Wi-Fi, the access provider, the cross-border path, route type, target service, and device performance can all change the result. One speed test does not represent long-term performance, and page load time alone cannot judge a route. A more reliable method is to use the same device, network, and task while changing only the route, then observe whether the issue consistently follows it.

Establish a local network baseline first

Disconnect and test ordinary websites, file transfers, or everyday apps to confirm that the local network is not already fluctuating. If it is slow while disconnected, address the Wi-Fi signal, router load, or access network first. Move closer to the access point, pause bandwidth-heavy syncing, backups, and downloads, and avoid testing while the device switches access points. Without a stable baseline, route comparisons are meaningless.

When testing speed after connecting, choose a task that matches your actual use. Web browsing depends on initial response and consistent page loads; video depends on sustained buffering; work apps depend on long-lived connections and uploads. Do not treat a peak reading from one speed-test site as the only standard; the test service’s region and load also affect results. What matters more is whether the same task remains steady across routes, whether pauses recur, and whether the result is reproducible after switching.

Choose routes by region and purpose

In general, prioritize a route near the target service’s region with a clearer path rather than automatically choosing the geographically closest node. The best exit can change with the target website’s region. Use the region and route type shown in the Route List: compare routes within one region first, then try nearby regions. After each switch, reopen the target app so it does not continue using the previous route.

If everyday browsing is normal but video or large-file transfers frequently stall, the basic connection is established and the issue is more likely sustained throughput, the target service path, or congestion on the current route. If every website and app slows down, also check the local network, device resources, and client status. Do not run multiple similar network tools or point the system proxy and browser proxy at different exits; inconsistent paths can result.

Use comparisons to diagnose peak-hour issues

Peak-hour congestion may appear as higher perceived latency, video buffering, or unstable long-lived connections at certain times, but the time alone is not proof. Record the same network, device, and app at different times, and switch to another route in the same region when the issue occurs. If several routes are slow and ordinary networking also fluctuates, consider access-side congestion first. If only one route is affected, switch away from it temporarily and record the details.

Do not switch repeatedly at speed during testing. Each route change requires a new session, and the target app may retain its old connection. Disconnect, select the new route, wait for the connection to complete, quit and reopen the target app, then perform the same task. If the app caches content, test uncached content for comparison. This produces a conclusion that is less dependent on exaggerated speed figures and closer to everyday use.

Device performance and background tasks can mimic slow speeds

An encrypted connection requires the client to continuously process network data. If the device is under heavy load, low on storage, or subject to power-saving restrictions, network performance may drop. Close unnecessary background sync and download tasks, and confirm that the system is not limiting the client. Browser extensions, network filters, and security software may also inspect requests at multiple layers and slow page responses. Compare with a clean browser window and an environment with extensions disabled.

On mobile devices, switching from Wi-Fi to a mobile connection may rebuild the existing session. A brief pause during the transition does not necessarily mean the route is persistently unstable. Wait until the network state settles, then reconnect. On desktop devices using a dock or multiple network interfaces, the system may select a different exit between interfaces; keep only the active network path during testing if possible.

When to report a route issue

If ordinary networking is stable, other routes in the same region work, and one route repeatedly stalls on the same task, submit a ticket with its full name, target app type, time period, access network, and reproduction steps. Do not send only a speed-test screenshot; it lacks comparison conditions. If the issue centers on long sessions in an AI coding tool, also see VPNs for Programmers: Stable Connection Testing to check whether the command line and development tool use the same proxy path.

CavaVPN covers 90+ countries / 200+ routes. When one route behaves abnormally, switch to another route in the same region instead of repeatedly retrying the affected one. If multiple regions, networks, and devices show the same behavior, provide the complete comparison results to support. The goal is not a single peak reading, but a stable, repeatable route combination for the current network and purpose.

Frequent disconnects and mobile background dropouts: Check the session lifecycle

For frequent disconnects, first distinguish an intentional disconnect, reconnection caused by a network change, system termination of a background process, and an interrupted route session. The client returning to a disconnected state is not necessarily the same as an app temporarily having no data. Note whether the device was locked, asleep, switching networks, entering power-saving mode, or whether the target app had been in the background for a long time.

On desktop, rule out sleep and network switching first

When a desktop device wakes from sleep, its network interface reinitializes and the existing connection may not continue. If the issue occurs only after waking, focus on the recovery sequence: wait for ordinary networking to return, open the client to check its status, and disconnect and reconnect if needed. Do not repeatedly click Connect before the network is ready; the client may be cleaning up the old session while creating a new one.

On Wi-Fi, the device may move between access points. In environments where wired and wireless connections coexist, the system may also change the default interface. These changes can invalidate the existing path. Temporarily fix one access method during testing. If the connection becomes stable, the disconnects are related to interface switching rather than the account or subscription. Enterprise network login pages can also interrupt an existing connection, so complete local network authentication first.

Mobile background dropouts are often related to system scheduling

Mobile operating systems manage apps based on battery level, background activity, and memory pressure. If the client stops soon after going into the background, check whether continuous operation is allowed, strict power-saving limits are enabled, or the system automatically clears background processes. Allow the CavaVPN client to run in the background and avoid cleanup tools that force-close background apps. Restart the client after changing these permissions so the system applies them again.

Disconnects after locking the screen may also be caused by Wi-Fi sleep policies. Check whether ordinary networking remains available before and after locking. If the entire network is suspended, the connection cannot be maintained. Compare with another trusted network to determine whether the issue comes from device power management or the current access environment. If it happens only on Wi-Fi while another network is stable, continue checking the router and Wi-Fi sleep behavior.

Distinguish an app disconnect from a full connection drop

If a chat app, development tool, or remote-work app asks you to reconnect while the browser still works normally, do not immediately assume CavaVPN has disconnected. The target app may have its own heartbeat, timeout, and background policies. Fully quit and reopen the app to see whether it recovers immediately, then check whether other apps are affected too. A full connection interruption is more likely only when several unrelated apps lose access at once and the client status also changes.

Conversely, if the client still shows Connected but every app has no traffic, follow the “Connected but websites will not open” section and check the system proxy and DNS. The status icon may lag behind the underlying state, so verify with actual requests rather than one toggle. Before switching routes, keep the current route name and circumstances so useful clues are not lost.

Reduce conflicts between network tools

Multiple similar clients running at once may compete for the system proxy, network extension, or virtual interface. Even if only one window is visible, another tool may retain a background service. Quit unused network clients and check startup items for older programs that launch automatically. Then restart the device and run only the current client for comparison. If the issue disappears, restore other software one item at a time to identify the conflict.

Local security, traffic filtering, and parental-control tools may also rebuild the network stack. Do not permanently disable protection to resolve a conflict. Check the software’s network permissions or compatibility settings and allow only the clearly identified client process. On managed enterprise devices, follow administrator policies rather than attempting to bypass device-management requirements.

Decide whether route-side assistance is needed

If disconnects continue consistently on one route after fixing the network, removing power-saving restrictions, and ruling out other clients, but stop after switching routes, the issue can be narrowed to that route or path. Include the full route name, access network, device platform, circumstances, and log excerpt in the ticket. If every route disconnects only after the screen locks, keep investigating system background management instead of reporting each route separately.

Stability troubleshooting depends on continuous context. Do not clear logs or reinstall immediately after every disconnect; doing so removes the state changes before and after the fault. Export the logs first and cover sensitive content, then continue. Support can use the connection events around the disconnect to distinguish system scheduling, network switching, and route-session issues more easily than from a single “Not connected” screenshot.

Subscription update failed: From account status to local cache

A failed subscription update and a failed route connection occur at different stages. Updating retrieves route configuration from the user panel; connecting uses the configuration already stored in the client. If the subscription cannot update, old routes may still appear or even connect, while newly added or changed content does not reach the client. Confirm the account status and subscription URL first, then check the network request, client cache, and duplicate configurations.

Confirm the source in the user panel first

Open the subscription or download area in the site’s user panel, confirm that the plan is active, and retrieve the subscription again from the panel. CavaVPN requires no email address for registration; use the actual username and password when recovering or verifying the account. Do not copy the subscription from chat history, old notes, or screenshots on another device. An old URL may have expired or been truncated during copying.

Monthly subscriptions include the traffic assigned to the plan and reset each month on the activation date; traffic packages remain valid until used and never expire. When an update fails, check the plan and traffic status in the panel rather than relying on cached text in the client. If the panel itself does not match the purchase record, save screenshots of the order and plan pages before submitting a ticket. Do not mask an account-side issue by importing repeatedly.

Identify incomplete copies and formatting noise

Copy the subscription URL as one complete link without leading or trailing spaces, line breaks, quotation marks, or explanatory text. Some chat tools and documents insert line breaks automatically, making a link look complete when the copied value is truncated. Paste it into a plain-text editor to inspect it, but do not save it in a publicly synced document. The example below shows the structure only; its domain and token are not a real subscription.

https://example.com/sub?token=YOUR_TOKEN

If the client says the format is unsupported, confirm that you selected “Import from link” or “Add subscription” rather than the local configuration-file entry. Names vary between clients, but the goal is for the client to request the link and parse the response. Do not enter the subscription URL as an ordinary route address or alter any characters in the link.

Verify the update request on an ordinary network

A subscription update must first reach the subscription URL. If the current connection is already abnormal and the client tries to update through that route, the two problems can become dependent on each other. Disconnect, confirm that ordinary networking can reach the site’s user panel, and then update. If it still times out, compare with another trusted network. If the other network works, the original access environment is affecting the request.

After updating, check whether the route list changed as expected rather than relying only on a brief “Update complete” message. Some clients retain old cache and continue showing historical routes even after a failed request. Compare route names and groups to confirm that the active configuration is the new subscription. If duplicate groups exist, back up necessary settings, remove the duplicates, and keep only the copy re-imported from the panel.

Clear the cache in the right order

Do not delete all client data at the first sign of an update failure. Refresh manually and record the error; quit and reopen the client; then delete only the invalid subscription and import it again. Consider resetting the client only after confirming that the local configuration is seriously disorganized. Save logs and necessary non-sensitive settings first, because a reset can remove clues that explain the failure.

After a successful update, disconnect the old session, select a route from the new list, and connect again. Without reconnecting, the client may continue using the pre-update session. If the update completes but every new route fails, follow the “Cannot connect at all” section and check system permissions and the network path. Do not keep re-importing the subscription; configuration retrieval has already succeeded.

Distinguish authentication, resolution, and format errors

An authentication message usually means the client reached the service but the subscription credentials or account status need checking. An unresolvable host points more toward DNS; a timeout requires comparison across networks; a format error means the client received content but could not read it as expected. Clearly naming the error category prevents repeated questions from support. If the original error can be copied, include it exactly instead of rewriting it as “the link is broken.”

If only one client cannot import while another platform updates normally, the account and subscription source are probably available. Check the affected client’s import method, network permissions, and local cache. CavaVPN supports Windows, macOS, iOS, Android, and Linux, but system networking differs by platform. State the platform and client entry point in the ticket instead of writing only “desktop” or “mobile.”

When to ask support to verify it

After copying again from the panel, trying different networks, removing duplicate subscriptions, and re-importing, stop repeating the same steps if the authentication or format error persists. Provide the username, a screenshot of the plan status, full error text, device platform, client name, time, and steps already taken. Do not send the password or complete subscription URL. Support can continue checking with the account and request details without exposing credentials.

If the issue began after a purchase or upgrade, include the plan status before and after the change. When a CavaVPN monthly subscription is upgraded mid-cycle, the difference is converted into remaining days; focus on whether the panel and subscription contents match rather than calculating it yourself. Keep the original order and plan pages to help distinguish payment status, plan activation, and client cache.

App routing, device messages, and support tickets: Complete the diagnosis

When the browser works normally but one app consistently does not use the proxy, the issue is usually narrowed to the app layer. The app may ignore the system proxy, use its own network settings, cache proxy state at launch, or be sent direct by a routing rule. Switching many routes is unlikely to help; check the target app’s process, proxy support, routing mode, and domain requests.

Establish a working comparison with the browser first

Keep the current route unchanged and first open a webpage related to the target app in the browser. If the page works but the app does not, the route and basic access are probably available. Fully quit the target app, including its notification-area, menu-bar, or background process, then start it again. Many desktop apps read the system proxy only at launch, so starting the app after the connection is established produces a more consistent test than switching routes while it is running.

If the app has its own proxy settings, avoid enabling the system proxy alongside an incorrect manual proxy. Prefer the system or client-recommended mode; enter local proxy parameters only when the app clearly requires them. Do not copy ports, addresses, or certificates from unknown guides. If manual parameters do not match the client’s current listener, the app may lose access while the browser continues to work.

Check routing rules and target domains

Rule-based mode determines where requests go based on domains, addresses, or app types. A target service may use separate login, API, static-asset, and content-delivery domains. Proxying only some of them can produce a successful login with failed content loading, or an interface that opens while messages cannot be sent. Temporarily use a more unified proxy mode for comparison. If that works, return to rule mode and inspect the matches.

Restart the target app and establish a fresh connection after changing rules. An old process may retain resolved addresses and network sessions, making the new rules appear ineffective. Command-line tools, development environments, and editor extensions often read environment variables, system proxies, and internal settings separately. For AI coding tools, see Stable Connection Testing for Cursor and Copilot and verify that the terminal, editor process, and extension service use the same path.

Differences between mobile and desktop apps

Mobile apps generally use system-managed networking, but background activity, private resolution, in-app web pages, and the system browser may behave differently. If an in-app page fails while the system browser works, clear the app’s own cache or sign in again, then check whether it has an independent network-protection feature enabled. Do not delete all app data before identifying the cause, as local content may be lost.

Desktop apps more often have independent proxy and background-process issues. Closing the window does not always end the process; confirm this in the system task manager or activity monitor. For command-line programs, check whether a new terminal inherited the current proxy environment; an old terminal may retain the environment from before the connection was established. Test in a new session and never put a real subscription URL in command history or configuration examples.

How to assess a “device limit reached” message

CavaVPN plans have no device limit, so first confirm whether a device-related message comes from the CavaVPN user panel. A third-party client may use similar wording for local configuration conflicts, duplicate logins, concurrent tasks, or an app-specific restriction. Record where the message appeared, its full text, and the client name, then check the account status in the user panel. Do not delete other device configurations simply because the message mentions a device.

If the message genuinely appears in the site panel or during a subscription request, capture it and submit a ticket for verification because it conflicts with the no-device-limit service fact. The screenshot should include the page location and context, while covering sensitive information other than the username. Support does not need the password or the complete subscription URL. If the message comes from another app, check that app’s own account and network rules.

Prepare the minimum complete information before submitting a ticket

A workable ticket should include the symptoms, device platform, client name, access network type, full route name, time, whether the issue reproduces consistently, original error text, steps already taken, and comparison results. Comparison results mean whether the symptom changed after switching routes, networks, or apps. The report does not need to be long, but support should be able to understand the issue in the same order.

Logs should cover the period before and after the failure. After exporting them, check for and cover subscription URLs, passwords, access tokens, and other account credentials. Screenshots should retain the full window context rather than one generic error line. For speed issues, describe the actual use case and same-region comparison; for disconnects, state whether the device was in the foreground, background, locked, or switching networks; for subscription issues, report the result after copying again from the panel.

When to stop making changes yourself

If the issue reproduces consistently across multiple networks, regional routes, and supported platforms, or the panel clearly does not match the purchased plan, stop reinstalling, resetting, and changing rules in bulk. Further changes can destroy the reproduction environment and delete logs. Preserve the current state and submit a ticket; it is more effective than undocumented experiments. If only one app, device, or route is affected, continue with limited comparisons around that boundary.

For payment and plan choices, refer to the official details on the Plans page. CavaVPN monthly subscriptions are ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB; traffic packages are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB, and traffic packages never expire. Alipay, WeChat Pay, and USDT are supported payment methods. If the panel differs from these facts, preserve the original page and ask support to verify it.

Wrap up after troubleshooting

Once the issue is resolved, undo temporary test changes and keep only settings confirmed to work and from a clear source. Remove duplicate subscriptions, close unused similar clients, restore the normal routing mode, and retest ordinary websites, the target app, and local networking after disconnecting. Record the route that worked and the steps taken so similar symptoms can be diagnosed quickly later.

If switching routes fixed the issue, keep the affected route name instead of recording only “reconnected.” If changing background permissions helped, record the relevant system setting. If re-importing fixed it, confirm that the old subscription was removed. For intermittent issues, continue observing the trigger; there is no need to keep changing settings to force a one-time conclusion. The goal of systematic troubleshooting is a diagnosis chain that can be reproduced, explained, and handed to support.