Clash Troubleshooting
Connections, Subscriptions, and System Proxy

No internet: identify the failing layer

“Websites stop loading when I turn on Clash” doesn’t necessarily mean the node is down. Incomplete network sign-in, a system proxy pointing to an old port, a rule that rejects the connection, or a DNS request that never returns can all produce the same browser error. First determine whether the problem starts before or after the client launches, then check whether it affects every app or just a particular site or program.

Turn off traffic routing and check the underlying connection

Turn off the system proxy and TUN mode in the client, leave the client open, and try a site you can normally access directly. If it still fails, check your Wi-Fi connection, gateway access, and whether the hotel or campus network requires web sign-in. Don’t keep switching nodes before the underlying connection works; that makes it hard to tell a network problem from a proxy exit problem.

If your connection keeps failing after you quit the client, check your system network settings for a leftover manual proxy. Note the address and port, then disable the stale setting. On a managed device, the proxy may be part of your organization’s network policy—don’t remove it without checking. Once the underlying connection is back, restart the client and test with only the system proxy enabled. Leave virtual adapters and custom DNS out of the first test.

Check connection records to see whether traffic reaches the core

Open the connections list or logs, clear the old entries, then visit a specific destination. If a connection appears, the request reached the core; check the matched rule, outbound policy, and error details. If nothing appears, first check whether the app follows the system proxy, whether the browser has its own proxy settings, and whether the core actually started. A “running” status in the UI doesn’t guarantee that the listening port is available.

A rejected connection, DNS resolution failure, and connection timeout point to different layers. For a rejection, check the rule or outbound policy; for a resolution failure, check DNS; for a timeout, check the node address and network route. Note the destination, matched policy group, and final node instead of looking only at the last error in the log. Background update failures may appear on the same log page without affecting current web requests.

Rule-based routing: check the match order and final outbound

Rules are evaluated in order, and the first match usually determines where traffic goes. Check which rule matched the failing connection, then confirm that its policy group exists and has a valid selection. If Global mode works but Rule mode doesn’t, focus on the routing configuration rather than reinstalling the client. Global mode is useful for comparison, but it doesn’t prove that every site should use the same outbound.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

This example assumes a policy group named Proxy already exists; it won’t run on its own without the rest of the configuration. The final MATCH rule handles connections that didn’t match earlier rules. Group names must match their definitions exactly, including capitalization. Domain rules depend on the domain being available to the connection; IP rules may trigger DNS lookups. Different connections to the same site may not match the same rule.

Make the smallest change needed to verify recovery

Choose a node you’ve already confirmed works, keep the default traffic-routing mode, and retry the site that failed, followed by another site. If only one service fails, check its status, account limits, and exit-region requirements; don’t assume the whole client is broken. If every request fails, check the nodes in the next section. If only some apps have no connection records, see System proxy failures.

Node timeouts: test each connection stage

A node test timeout means the client didn’t receive the expected response in time under the test conditions. It doesn’t prove that the node is unusable for every purpose. An unreachable test URL, a DNS error for the node hostname, invalid credentials, or a failed transport handshake can all produce similar results. Check the path from your device to the server, the protocol handshake, and the server’s connection to the destination separately. Don’t judge by the test button’s color alone.

Confirm what you tested and which node you’re using

Check whether the current connection uses an individual node, an automatic selection group, or a fallback group. Some groups contain another group, so the outermost name in the UI may not be the actual outbound. Expand the connection details and confirm the final route uses the same node you tested. If automatic selection is still changing, temporarily pin one candidate to reduce variables.

Compare two results: whether the client’s built-in test fails, and whether a browser can reach a regular website through the node. The built-in test uses a specific test URL; access restrictions or changes to the remote site’s response can cause it to fail even when browsing works. Don’t enter an unfamiliar URL just to make the test pass. Use the client’s default test target and check that it’s reachable on your current network.

Use the error to distinguish DNS, connection, and authentication issues

If the log says the host doesn’t exist or the server address can’t be resolved, check the node’s hostname and your local DNS first. A connection refusal usually means the destination explicitly rejected the request, possibly because the port is wrong or no service is listening. A timeout may indicate packet loss, access restrictions, or an unresponsive server. These clues narrow down the issue but don’t prove that the server is permanently offline.

For authentication failures, handshake failures, or certificate errors, check that the subscription is still valid, the device clock is correct, and the client core supports the node configuration. Don’t hide the problem by disabling certificate verification. The configuration provider should confirm the certificate name, server name, and transport parameters. Share the error type and timestamp with the provider; don’t post node passwords or full connection strings in public forums.

Compare results on a different network

Test on both your home network and a mobile hotspot using the same device and configuration. If it fails on only one network, focus on that network’s sign-in requirements, access policies, and DNS. If it fails on multiple networks while other nodes on the same subscription work, the issue is more likely with that node or its protocol settings. A hotspot uses mobile data, so start with a quick web test rather than a large download.

You can also test the same valid subscription on another device, subject to the service’s device and concurrent-connection limits. If it works there, the configuration is valid in that environment; compare core support, system time, and traffic-routing settings. Avoid testing the same account on several clients at once, since concurrency limits can introduce new timeouts or disconnects.

Distinguish an unavailable node from a protocol-specific issue

If websites load but voice calls, games, or real-time communications fail, check whether the app relies on UDP and whether the node, policy group, and traffic-routing mode support that traffic. The behavior of an app using an HTTP proxy isn’t identical to traffic routed through a virtual adapter. Don’t assume the whole node is unavailable because one real-time feature fails—or that all traffic types work just because web browsing does.

Once you’ve confirmed a node is unavailable, update the subscription manually and select another working node. Increasing the timeout only makes you wait longer; it won’t fix a wrong address, failed authentication, or unreachable route. If all nodes still fail after an update, check the subscription configuration in the next section. For client and platform compatibility, see the download center. Clash Plus is a good first choice.

Subscription failures: check the response content

Importing a subscription involves fetching its content, parsing the format, and loading the configuration. A failed link request and a YAML syntax error are different problems and need different fixes. Copy the full error message first and identify whether it occurred during download or configuration loading. Your existing working configuration may be the best way to recover, so don’t delete all old configurations and nodes before confirming the new subscription works.

Check the link and account status

Copy the subscription URL again from your provider’s account page. Chat apps may insert line breaks, browsers may truncate what they display, and manual selection may miss part of the link. Check for spaces or quotes at either end, and make sure query parameters haven’t been cut off. Subscription URLs often contain credentials: don’t post them publicly or paste them into online formatters or unfamiliar conversion services. Hide the address bar and QR code in screenshots.

If your account has expired, you’ve run out of data, or the subscription URL has been reset, retrying in the client won’t restore access. Check your status on the provider’s site and use the new link. If opening the URL in a browser shows a sign-in page, CAPTCHA, access-denied message, or ordinary web page, the client may not be receiving configuration content. Saving that page as YAML won’t make it parse as a configuration.

Distinguish network errors, status codes, and format errors

For a timeout or failed connection, first check that the device’s network works and its clock is correct. If the configuration page offers a direct or proxied download option, record the current setting and compare them. A subscription that requires a proxy needs a working outbound connection first; it can’t rely on nodes that haven’t been imported yet. If no configuration is available, ask the provider for an official import method that works on your network.

Permission-related status codes usually require checking the account or URL. For rate limits, stop retrying and wait as the provider advises. For parse errors, check the response format: a node list for another client, a single share link, and a Clash configuration file are not interchangeable. Make sure the subscription page is set to produce an output for Clash or mihomo before importing. Don’t try to fix it by changing the file extension.

config.yaml: start with the first reported error

YAML is sensitive to nesting and indentation. Check the lines around the reported location and the line before it. Indent with spaces, not tabs, and check that colons, list dashes, and quotes are correctly paired. The reported location may be where the parser noticed the problem, not where it began; an unclosed string may be the real cause. Copy the original file before editing, fix one issue, then reload. Don’t reformat the entire configuration at once.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
dns:
  enable: true
  listen: 127.0.0.1:1053

This snippet illustrates nesting only; it contains no nodes or policy groups and isn’t a complete subscription. Top-level fields sit at the same level as dns; enable and listen are DNS subkeys. Also check for policy groups that reference nonexistent nodes, rules that use undefined group names, and protocol fields unsupported by the current core. Use the load logs to diagnose these issues.

Check whether overrides or auto-updates changed the result

If the subscription source is valid but the active configuration fails, check the client’s configuration merge, scripts, and override features. Back up custom content, temporarily disable it, and reload to tell a source issue from local processing. Don’t edit cached files as a permanent fix; the next update may overwrite them. Put settings you need to keep in the client’s supported persistent override location.

An automatic update failure doesn’t necessarily mean the current connection is broken. Check the last successful update and the failure reason. Try a manual update, confirm the new configuration loads, then set a reasonable interval. Device sleep, background restrictions, and network changes can all delay scheduled tasks. For more detailed checks, see the subscription link parsing troubleshooting checklist. For import instructions, see the subscription import guide.

Slow speeds: separate latency from throughput

Slow page starts, low download rates, and frequent video buffering can point to DNS delays, high latency, and limited sustained throughput, respectively. A client test mainly measures the response time of a particular request; it isn’t the same as download bandwidth. Start with a repeatable task, such as loading the same page or downloading the same file. Note the network, node, and time, then change one variable at a time.

Establish direct-connection and proxy speed baselines

Pause other downloads, cloud sync, and system updates. Check whether other devices on the same network are using all the bandwidth. Test a resource that’s available directly, then access the same or a similar resource through the proxy. If the direct connection is already slow, check Wi-Fi signal, router load, or your broadband connection first. The client can’t increase your available bandwidth or prevent packet loss caused by network congestion.

Wi-Fi tests can be affected by distance, band, and interference. Temporarily use Ethernet on a computer or retest a phone near the router, keeping other conditions the same. Don’t compare peak speeds from different sites to rank nodes: the site’s server, content delivery route, and account limits can all differ. A stable transfer rate over time is usually more useful than a peak in the first few seconds.

Find the bottleneck by when the slowdown occurs

If a link takes a long time to start loading but images appear quickly afterward, check DNS, connection setup, and the handshake. If the page appears immediately but large files stay slow, check outbound bandwidth and remote-side limits. If the first visit is slow and later visits improve, DNS, connection, or resource caching may be involved. Note whether each test is a first visit so caching differences aren’t mistaken for configuration improvements.

Check the client’s connection list to confirm the slow request uses the expected node. A page usually connects to multiple domains, and the main site, images, and video may match different rules. Changing the rule for the page’s main domain may not change the route used for media. Identify the slow resource’s actual domain and final policy before changing a rule. Don’t leave all traffic in Global mode to fix one video.

Compare network routes, not just geographic distance

A nearby server doesn’t necessarily mean a shorter route, and a fast response test doesn’t guarantee fast downloads. Choose two or three nodes you’ve confirmed work, run the same test around the same time, and compare stability, packet loss, and sustained throughput. If congestion happens only in the evening, note the time and share it with your provider. If only one site is consistently slow, the cause is more likely the service, exit region, or content delivery route.

Device performance can affect speed too. Check CPU use and memory pressure in your system’s task manager, and close idle connections and duplicate proxy tools. Detailed logs can help during a brief investigation, but leaving high-frequency debug logging on can increase disk writes and processing overhead. Return to the normal log level when you’re done. Turning off all logs isn’t a universal speed fix.

Use care when changing MTU, IPv6, or real-time traffic settings

If large files stall or some pages hang only when TUN is enabled, while the system proxy works, check the virtual adapter, routes, and path MTU. Restore the client’s defaults first, then make one change at a time following its documentation, and record the original value. An MTU that’s too large can disrupt some paths; one that’s too small adds overhead. There’s no single best value for every broadband connection, hotspot, and tunnel.

Incomplete IPv6 support, unavailable UDP, or a different route for real-time apps can make speed tests differ from everyday use. Test each app according to its needs; don’t disable IPv6 system-wide based on one test. If the issue occurs only with a particular traffic-routing mode, see TUN mode vs. system proxy and confirm what traffic is routed before changing settings.

DNS issues: find out which resolver is involved

DNS problems often show up as inaccessible domains, apps reporting they’re offline, or repeated resolution failures in connection logs. The system resolver, browser secure DNS, the client’s built-in DNS, and DNS lookups for the node server may all be involved in one request. Identify which layer returned the error before changing settings. Changing system DNS to a public resolver may not affect the path the client actually uses.

Compare system and client DNS results separately

First, use a system tool in the terminal to look up a public domain and check whether the system gets a response. Then check how the client logs a lookup for the same domain. The command below checks the system’s current resolution path; it doesn’t prove that the proxy route works. If the system lookup succeeds but the client’s fails, check the core’s DNS settings. If both fail, check network sign-in, resolver reachability, and local network policies.

nslookup example.com

A lookup timeout and a nonexistent domain are different errors. A timeout may mean the resolver didn’t respond; a nonexistent domain may actually be invalid or return an unexpected result. Check whether only the node server’s hostname fails: the core must resolve the server address before it can connect, and relying on a proxy that isn’t connected yet can create a loop. Follow the client’s documentation to set up DNS resolution for node hostnames instead of copying an entire DNS template at random.

Understand fake-IP, caching, and browser secure DNS

With fake-IP enabled, the client may return a mapped address from a reserved range to the app, then associate it with the real domain in the core. This is part of the traffic-routing mechanism; a lookup result that isn’t a public IP doesn’t by itself indicate a DNS problem. What matters is whether the connection returns to the same core and whether the mapping exists. If traffic bypasses the client and connects directly to the mapped address, the app may fail to connect.

A browser’s own secure DNS may bypass the system resolver, making the browser behave differently from other apps. Note the current setting, then temporarily compare it with system DNS. Don’t change the browser resolver, client upstream, and system DNS all at once, or you won’t know which change helped. Keep the network’s required resolution path for local devices and internal domains.

After changing configuration, existing connections and cached results may still be in use. Close the failing page and establish a new connection before clearing the relevant cache. On Windows, the command below clears the system DNS cache; it doesn’t clear the client’s or browser’s internal cache, and it can’t fix an unreachable upstream server. Follow your platform’s documentation on other systems. Avoid one-click network reset scripts from unknown sources.

ipconfig /flushdns

GeoIP updates: check these separately from DNS data

GeoIP data is used to match IP addresses to geographic locations in rules; it doesn’t translate domain names into IP addresses. If a download fails, check whether the log mentions a resource file, download URL, or read error. Then check the client’s data update controls, storage permissions, and network access. Don’t rebuild the geographic database because a domain won’t load, and don’t confuse domain-rule data, IP geolocation data, and the DNS cache.

If the log reports a missing database, use the client’s supported update feature first. After the update, reload the configuration and check that the error is gone. Data sources and formats must match the current core and configuration; renaming an incompatible file won’t make it work. If an update requires a proxy but no outbound connection works, restore a working connection or follow the client’s documentation for a reachable download method instead of repeatedly retrying the same failed task.

Check IPv6 and local network DNS boundaries

A domain may return both IPv4 and IPv6 addresses, but your network may not have a working IPv6 route to the internet. If the log shows that only IPv6 connections fail, compare support in the system, core, and node, then run a temporary test. Don’t permanently block all IPv6 instead of diagnosing the issue. If printers, network storage, or internal work domains stop working, check whether they’re being sent through proxy DNS or the proxy outbound by mistake.

A successful recovery means the target app can connect, traffic follows the expected policy, and internal resources still work—not just that one lookup returned a result. For configuration field nesting, see config.yaml structure explained. For common concepts, visit the Help Center.

System proxy failures: check the listener and traffic routing

The system proxy is an operating-system setting for apps; it isn’t a switch that forces all network traffic through a proxy. Browsers may follow it, while command-line tools, games, and some store apps may use their own network stacks. So “the browser works but the terminal doesn’t” doesn’t necessarily mean the setting is broken. Check which proxy method the target app supports, then compare the client’s listening address with the system setting.

Make sure the listening port matches the system proxy

Check the mixed port in the client settings or active configuration; don’t assume every device uses 7890. The system proxy should point to the device’s loopback address and the actual listening port. Another client may have left an old port configured or may still be changing the system settings in the background. Quit other proxy apps, then toggle the current client’s system proxy off and on and check whether the system setting updates.

A command-line tool that supports proxy parameters can test the local port directly, bypassing the system proxy switch. The command below assumes the client listens on 7890 on the same device; replace it with the port you confirmed in the settings. If the explicit proxy works but the browser doesn’t, check the browser’s own settings, extensions, and system proxy. If it also fails, check the listener, node, and rules.

curl --proxy http://127.0.0.1:7890 --head https://example.com

Distinguish graphical apps, terminals, and system services

Some terminal tools read environment variables; others use their own configuration files. On Windows, different proxy interfaces may serve different types of apps. Changing one setting doesn’t change every system service. Check the target tool’s proxy documentation and test with a one-time command-line option first. Persist the setting only if it works, so you don’t forget to remove a proxy variable from the global environment later.

If an explicit proxy option works but the usual command doesn’t, check for a separate proxy setting, a direct-connection exception, or an old environment variable in the tool. The variable’s address should match the current client, and an exception list may bypass the proxy for the target domain. Change only the target tool’s settings; don’t reset the entire system network. After closing the client, check for persistent settings pointing to a stopped port.

If you need TUN, check permissions and routes first

TUN uses a virtual network interface to route traffic, including traffic from some apps that don’t follow the system proxy. It may require specific system permissions, a service component, and route support. If it won’t start, check the client logs for permission, device creation, or route errors instead of repeatedly toggling it. Install a service or authorize a network extension through the client’s normal process, then confirm that the core actually created the interface.

Other VPNs, virtual machines, container networks, and security software may conflict with routing rules. Note which network tools are running, then pause them one at a time to compare, if it’s safe to do so. Don’t disable the system firewall or remove unknown adapters. Be especially careful on a remotely accessed device: changing the default route may immediately disconnect your session. Make sure you have local access or another recovery method first.

LAN sharing and restoring settings after exit

When connecting another device to your computer’s proxy, don’t enter 127.0.0.1—that address always refers to the device itself. Enter the computer’s address on the current local network, and confirm that the client allows LAN connections, listens on the right interface, and the firewall allows only the necessary network access. Never expose the proxy port to the public internet. Turn off sharing when you no longer need it, and update the other device if the computer’s address changes.

Before exiting normally, turn off the system proxy and TUN, then confirm that a direct connection works again. If the network fails after you force-quit the process, manually disable any leftover system proxy and restart the client to let it clean up. For full sharing instructions, see mixed port and LAN connections. For the basic setting, see the system proxy setup guide.

Client crashes: keep your configuration and recover safely

A window that closes unexpectedly, a blank interface, a core that keeps restarting, and settings that won’t save are separate problems. The graphical interface manages the client; the core handles proxy traffic. Either can fail independently. First check whether the process is still running, whether the tray icon opens, and whether the proxy port is still listening. If the window closes but the network still works, it may just be hidden. If the core exits while the UI stays open, you might mistake it for a node failure.

Check the installation, permissions, and runtime environment first

Make sure the installer matches your platform and processor architecture, and that your OS meets the client’s requirements. On macOS, distinguish Apple Silicon from Intel; on Linux, check the distribution and package type; on Windows, review security prompts and installation-directory permissions. Don’t download purported repair tools from unfamiliar pop-ups or permanently disable system security to launch the app. Use the installation and authorization steps in the client’s documentation.

A protected install directory, a read-only portable folder, or insufficient disk space can prevent settings from saving or the app from starting. Check the data directory the client actually uses, not just its installation folder. Organization-managed devices may restrict background services and network extensions; follow your device management policy. Running as administrator can be a useful test when appropriate, but it doesn’t fix incorrect directory permissions.

Distinguish a UI problem from a core startup failure

If the UI opens but the core won’t start, read the startup log first. A port conflict, invalid configuration field, missing policy group, or missing data file usually produces a clear error. Don’t immediately delete all user data. Use the client’s built-in validation or load feature to check the configuration, then disable recently added overrides, scripts, and rule resources. Restore a previously working configuration, then reapply changes one at a time.

For a port conflict, identify whether an old client or leftover core is using the port, then quit that program normally. If you need to change the port, update the system proxy, terminal configuration, and shared devices too. Changing only the listening port while leaving the system pointed at the old address can turn a startup issue into a lost connection. For a blank or corrupted interface, check the graphics runtime as described in the client documentation; don’t reuse startup flags from unrelated apps.

Back up first, then rebuild a minimal working setup

Before resetting or reinstalling, export the subscription configuration, note your policy group selections, and back up overrides and essential settings. Store the backup somewhere you control; it may contain subscription credentials and node authentication details. Uninstalling the app may not remove user data, so a crash that persists after reinstalling doesn’t prove the installer is at fault. Old configuration or cached data may load again on startup.

If the client has a reset option, read what it removes first. If its effects aren’t clear, fully exit the related processes, back up the data directory, and temporarily move it aside rather than deleting it permanently. Restart with default settings and confirm that a clean setup opens reliably. Then import one known-good configuration. If the crash returns immediately, check that configuration and its resources. If a clean setup also crashes, investigate OS compatibility and the installation environment.

Choose a maintained client and prepare a useful bug report

For a new installation, consider Clash Plus, or choose a client for your platform from options such as Clash Verge Rev and FlClash. Clash for Windows and ClashX Meta are no longer maintained, so reinstalling may not fix issues in an old setup. Before switching clients, confirm that the subscription format is compatible. Don’t copy the entire user directory: configuration files, app settings, and cached data are different kinds of data.

Include your OS and processor architecture, client name, installation details, steps to reproduce, and the relevant final lines of the log. Avoid conclusions that can’t be reproduced, such as assuming the OS is unsupported based on a single crash. Remove account, subscription, and node details from logs before sharing them. If you enabled verbose logging while troubleshooting, return to the normal level when fixed and remove local diagnostic files if needed.

Mobile troubleshooting: check VPN and background access

On phones, proxy connections rely on the system VPN interface or a network extension, which works differently from a desktop system proxy. A VPN icon in the status bar only indicates that the system interface is active; it doesn’t confirm that the subscription, nodes, or routing rules are correct. Test a connection with the client in the foreground, then check what happens when you lock the screen, switch apps, or change networks. Record initial connection failures separately from background disconnects.

Android: check permissions and VPN conflicts

Grant the system VPN permission when you connect for the first time, and confirm that the intended client is active. Filtering tools, work profiles, and other VPN apps may compete for the same routing slot, causing the connection to drop as soon as it starts. Check the current VPN in system settings and avoid starting several apps repeatedly. On managed devices, network policies may differ between work and personal profiles; check each one separately.

If traffic drops only after the screen locks, check whether the system restricts background activity, battery use, or mobile data for the client. Allow it to run in the background, then retest with the screen locked. Setting names vary by manufacturer; check the actual system menus. Don’t remove restrictions from every app, and don’t assume the proxy stopped just because its notification disappeared. Check the client status and test an actual connection.

Android’s per-app proxy settings may include only selected apps or exclude certain ones. If one browser works and another doesn’t, check whether both are covered before looking at the rules. Recheck the selection after an app update or work profile change. For initial import and VPN authorization, see the Android setup guide. Don’t assume that the system proxy switch names used in desktop guides apply to a phone.

iOS: make sure the network extension and configuration are active

On iOS, Clash Plus is a good option. See the iOS download page for the App Store link; the client’s official site is clashplus.io. After authorizing it in iOS, confirm that the subscription has loaded and a policy group has a valid selection. Creating a VPN configuration without importing working nodes won’t establish a proxy connection.

When switching from another network tool, check which VPN configuration iOS is using and disable auto-reconnect in the old tool if needed. After the client reports a connection, test the same webpage. If only one app fails, check its network behavior and routing result. Don’t keep deleting every system configuration; first see whether the old tool is taking over again.

Switch between Wi-Fi, cellular, and hotspot connections

After switching from Wi-Fi to cellular, existing connections may still depend on the old address and route. Wait for the network to settle, then disconnect and reconnect in the client to establish a fresh session. If only cellular fails, check whether mobile data is allowed for the client and target app, and compare node hostname resolution and protocol support. Don’t assume the subscription is invalid because of a brief failure during a network switch.

If a public Wi-Fi network requires web sign-in, pause the proxy and complete the sign-in first, then reconnect. Sharing a phone’s hotspot doesn’t automatically route connected devices through the phone’s proxy; the system may handle shared traffic differently from traffic on the phone itself. Use a sharing method explicitly supported by the client and OS. See LAN proxy sharing for address and security checks.

Keep a rollback option and verify the final setup

Android’s Always-on VPN, “Block connections without VPN,” and a client’s auto-connect option can make the device appear completely offline if the service stops. Note their current settings, then temporarily turn them off as a comparison, following the system’s instructions. Restore them after troubleshooting if needed. If the app was removed or its configuration became invalid, check whether the system still requires traffic to use a connection that no longer exists.

For a final mobile check, test access in the foreground, reconnect after locking the screen, and switch between Wi-Fi and cellular. Use the same destination each time and confirm the actual route instead of relying on the status bar icon. If the issue persists, note the OS, network type, client, error time, and a sanitized log, then check the Help Center. To set things up again, follow the Getting Started guide one step at a time.