Clash Troubleshooting Guide

No Internet: Separate Local Network Issues from Proxy Problems

Check whether your connection works with traffic routing disabled

If every website stops loading after you enable Clash, or the client says it is running while apps spin indefinitely, note the affected app, destination, and time. Then turn off System Proxy and TUN mode, leaving the client open. In your browser, try a site you can normally access directly. If it still fails, check Wi-Fi sign-in, your router, system network settings, and any other VPN first. The proxy client may not be the only source of the problem. Campus, hotel, and public Wi-Fi often require sign-in before traffic can be routed through a proxy.

If disabling traffic routing restores access, narrow the problem down to the local proxy entry point, rule selection, or proxy outbound. Open Subscriptions or your configuration list and confirm that a configuration is selected—not just downloaded. Then open Proxies and check that the active policy group points to a working outbound. Some groups retain an old selection after a subscription update changes the available entries, so the client may appear to run without having a usable route. Don’t delete all your subscriptions; compare with a configuration you know works first.

Test a request through the proxy directly

Next, enable only the client core and leave TUN off for now. Check the actual mixed port under Settings; the example below uses 7897, so substitute your port if it differs. An explicit proxy request does not depend on whether your browser follows the system proxy settings. This lets you test whether the client can forward traffic separately from whether an app is using the proxy. In Windows PowerShell, use curl.exe to avoid older environments interpreting curl as a different command. The example domain is simply an HTTPS request target; it is not necessarily accessible directly from your network.

curl --noproxy "" --proxy http://127.0.0.1:7897 --connect-timeout 10 --max-time 20 -I https://example.com

An HTTP status line means the server responded to this request, even if it rejected it; that is different from a connection that was never established. If you get a connection error for 127.0.0.1, check that the core is running and the port is correct. If the local connection succeeds but the request later times out, check the outbound logs. If the explicit request works but your browser does not, check the system proxy section for issues with the app’s entry point instead of repeatedly switching nodes.

Use logs to distinguish rule problems from outbound failures

Open Logs, keep the standard information level, clear the view, and reproduce the failed request once. Check its timestamp, destination domain, matched rule, and final policy group. If the request unexpectedly uses DIRECT when the destination requires a proxy, the issue is likely the rule order or mode. You can briefly switch to Global mode for comparison, then switch back to Rule mode. If Global works but Rule does not, check which rule matched rather than routing every connection through the same outbound indefinitely. Existing connections may keep their old route; reload the page or start a new connection after switching modes.

If an app has no corresponding log entries, it may not be using this proxy entry point, or it may use a separate network process. Test your browser first, then check the app’s own proxy settings. If the logs show REJECT, find out whether an ad-blocking, privacy, or custom rule matched. Adjust only the relevant rule—don’t clear the entire list. For more on rule priority, see Rule Syntax and Match Order.

If a change also breaks sites that normally work without a proxy, return to the last known-good state immediately: turn off TUN, restore the previous DNS settings, exit other traffic-routing tools, and test again. Don’t reset the entire network stack yet. A system-wide reset can remove adapter or network settings and disrupt remote desktop, virtual machines, and corporate access. Use it only after confirming that local fixes have not worked.

Connection Timeouts: Find the Failure Point from the Error Address

Distinguish connection failures, handshake failures, and destination errors

A timeout can have several causes. A client’s connection test may contact a specific test server, while your browser visits another site, so the results may differ. Open the destination directly, then check the logs for the same time. If only the test button times out but browsing works, check the test address and its rule path; one test result alone does not prove the outbound is down. Conversely, a successful test confirms only that test request—it does not guarantee that every site, UDP traffic, or large transfers will work.

Pay close attention to the address after dial tcp: it may be the proxy server or the direct destination. If the proxy server connection fails, check its domain resolution, port, and network reachability. If the address is the destination, first find out why the request is going direct. connection refused usually means the connection was explicitly rejected, perhaps because nothing is listening on that port or an intermediary refused it. i/o timeout means the read or write did not finish in time; it does not by itself prove that the provider’s service is down.

Narrow down the issue by comparing networks and outbounds

Keep the same outbound and destination, then switch your device from the current Wi-Fi to a mobile hotspot. If it works on the hotspot, the original network may restrict the relevant port or transport, or have a poor connection path. Then return to the original network and try a different outbound. If only one outbound fails, check whether its configuration has expired or the server has changed, and give the subscription provider the exact time and error. If every outbound fails on every network, check your device’s clock, subscription status, and core compatibility first.

For UDP-based transports, a basic TCP port check is not enough to prove that the protocol works. Some networks allow web browsing but restrict UDP; in that case, compare with an outbound that uses a different transport. Don’t arbitrarily change the protocol, port, or transport fields to another protocol—the client settings must match the server. A failed connection does not mean you should disable your firewall. Check its block log first and add a rule for the app or a specific port only if needed; remove temporary allow rules after testing.

Check TLS, authentication, and core compatibility

If the handshake fails, first enable automatic time synchronization, then verify the server name, SNI, authentication details, and transport path. Replacing the server domain with an IP address can change certificate name validation, so it is not a general-purpose fix. Keep the subscription’s supplied parameters intact; for a manual configuration, check each setting against the server’s documentation. If a protocol or configuration field is unrecognized, check which core the client uses. The original Clash core does not support every mihomo extension.

If you recently migrated a configuration, see mihomo vs. the original core and check the protocol, rule providers, and sniffing fields in particular. To update the client, choose a build for your device from the downloads page, and keep your current configuration before installing. Don’t replace the core with an executable from an unknown source or update the client, subscription, DNS, and every rule at once; if something breaks, you won’t know which change caused it.

If you need help, keep the log entries immediately before and after the failed request, not just a screenshot of the word “timeout.” Include the client name, operating system, network type, whether only one outbound is affected, and the results of testing on another network. Hide passwords, subscription parameters, and full server identifiers. For help reading log fields, see Understanding Clash Runtime Logs.

Subscription Update Failed: Check Download and Parsing Separately

Couldn’t retrieve the link, or couldn’t load its contents?

If a subscription update fails, keep your current working configuration and don’t delete and re-add it. Open the error details on the subscription card and identify whether the failure happened while fetching or parsing the content. Connection timeouts and name resolution errors usually occur during download. YAML format errors, unsupported proxy types, and invalid policy group references usually occur during parsing. Each requires a different fix. Repeatedly clicking Update won’t fix a format problem and may trigger server rate limits, making the error harder to diagnose.

Copy the complete subscription URL again from the provider’s account page. Make sure you haven’t included leading or trailing spaces, line breaks, chat app punctuation, or the text displayed on the web page. Query parameters in a subscription URL often grant access, so don’t remove or change them, and don’t post the URL in screenshots or forums. Import it in the client when possible; don’t submit it to an unfamiliar online converter. If you must check it in a browser, remember that browser history, download history, and sync may retain the full URL.

Use the HTTP response to choose your next step

A 401 or 403 usually points to authorization, account status, or server access policy—not your local mixed port. A 404 may mean the path is invalid, or the server may be deliberately hiding the resource; get the URL from the provider again. A 429 means too many requests. Stop retrying and wait as instructed by the server. A 5xx response is more likely to indicate a server-side or upstream issue. Note the time and try again later instead of immediately reinstalling every client.

Even a successful response may contain a login page, verification page, or error instead of the configuration. Check for <html>, a document type declaration, or web login content in the error details. A Clash configuration is generally a YAML mapping with related fields such as proxies, policy groups, or rules. A list of proxy nodes is not the same as a full configuration. If the provider offers multiple subscription formats, choose one compatible with your client. Changing the client name or request identifier only helps when the provider explicitly asks you to do so.

Check update-path dependencies and configuration conflicts

Some subscription URLs cannot be reached directly from your current network, while the client may default to direct access during updates. In other cases, the update request goes through a proxy that is already down. Check whether the subscription update settings support fetching through your current proxy, then test both the direct and working proxy paths. If all existing outbounds are unavailable, temporarily switch to a network that can reach the subscription service. This avoids the loop where you need an update to connect, but need a connection to update. The proxy server’s own domain must also resolve.

If a parsing error includes a line number, check that line and the indentation around it. YAML uses spaces to show nesting; don’t mix in tabs. Duplicate keys at the same level can also cause overrides or parsing errors. The example below is a standalone minimal direct-connection configuration for checking whether the core can load a configuration. It has no proxy outbound and is not a replacement for a subscription. Create a separate local test configuration; don’t overwrite the contents of a remote subscription.

mixed-port: 7897
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

If the minimal configuration loads but the subscription does not, check the subscription content, core support, and local overrides. Some clients apply Merge, Script, or Override settings to each update. An old override that references a policy group that no longer exists can make the final configuration invalid even when the remote content is correct. Disable these extra processing steps one at a time, update, and test. Once you find the cause, fix only the affected reference instead of permanently discarding all your custom settings.

After an update succeeds, confirm that the new configuration is selected and check its policy group members and working outbounds. Some clients download an update without switching to it. If you think your subscription URL has been exposed, reset it in the provider’s account page and update it on all your devices. Deleting the message from a chat does not revoke access details that have already been copied.

Slow Speeds and Intermittent Drops: Separate Bandwidth, Latency, and App Behavior

Describe what “slow” means in a repeatable way

Pinpoint where it’s slow: does the page take ages to appear, does video keep buffering after playback starts, is the download rate low, or does the connection drop after a while? A slow page load is more likely related to DNS, connection setup, or the TLS handshake. A slow sustained download points more to throughput, network congestion, or server limits. A drop after a consistent amount of time calls for checks of sleep, background restrictions, and keepalives. A client’s latency number alone cannot tell you your download bandwidth, and low round-trip latency does not mean the remote connection is uncongested.

Keep the device, destination, and app the same during testing. Pause cloud sync, system updates, and other high-bandwidth tasks. First check your local network without a proxy, then compare two outbounds to the same destination. Don’t change the Wi-Fi, browser, protocol, and destination all at once; the results would be based on different conditions. A speed test site may also be routed directly by your rules. If you mistake a direct result for proxy performance, you could draw the exact opposite conclusion. Check the connection list to verify which outbound the test actually uses.

Check each part of the connection and device load

A strong Wi-Fi signal does not rule out interference. Move closer to the router, switch to a stable band, or temporarily use a wired connection to test for local wireless issues. If the same outbound is stable on a mobile hotspot but drops on your home Wi-Fi, start by checking the local connection. Corporate networks, shared broadband, and evening peak hours can also affect throughput. Don’t overhaul every setting based on one poor test during peak hours just because a website recommends “high-speed settings.”

Check Task Manager or Activity Monitor for sustained CPU, memory, or disk pressure. With many proxy connections, the client interface, core, and security software may all use system resources. Temporarily lower log verbosity and close continuously scrolling debug windows, then check actual transfer speeds. Don’t disable essential security protections to improve a speed test score. If only the interface is sluggish but network requests work normally, troubleshoot the interface separately from core forwarding.

Check rules, protocols, and large transfers

If one site is slow but others are fine, check whether it uses different content delivery domains or sends some resources through a different outbound. A browser page may connect to several domains: if the main site uses the proxy but images or media go direct, text may load while video stalls. Review the relevant requests in the connection list and logs, then adjust the rule for the domain that actually matched. Put custom rules where they can take effect before broader matches, and keep a final fallback. Don’t append a rule after MATCH.

If System Proxy works but large transfers stall with TUN enabled, turn off TUN for comparison and check routing and MTU. An MTU mismatch can let small requests through while large transfers hang, but it is not the cause of every stall. Note the original value before making changes, and test gradually according to the client and network documentation. Don’t copy virtual adapter settings from someone else. If your transport relies on UDP, also consider the network’s UDP quality and throttling.

Browsers may use QUIC, and apps may open their own UDP sessions. If the problem occurs only with this traffic, temporarily disable the relevant feature in a test app that provides a specific setting, then restore it afterward. Don’t block all UDP globally just to make one test pass; that can disrupt voice calls, games, and other services. Reconnect after changing routes. Existing downloads or video sessions may not switch to a new outbound immediately.

If just one app is consistently slow, check whether similar requests in other apps work before clearing that app’s proxy settings or cache. Some platforms assign different routes based on exit IP, account, or content server, so a brief improvement after switching outbounds does not necessarily mean the client is faulty. Keep a stable setup where possible; frequent reconnects can trigger account checks or interrupt ongoing tasks.

DNS Issues: Separate System Resolution from Core DNS

A domain lookup failure does not mean every connection is down

Common symptoms include “server not found,” no such host in the logs, or a site that sometimes loads and sometimes resolves to an unreachable address. Check the domain spelling first, then determine whether the error occurred while resolving the proxy server or the destination site. If the proxy server’s domain cannot be resolved, all outbounds may be affected; a failed lookup for one site may affect only that destination. Visiting an IP address is not a complete substitute for testing a domain, since HTTPS certificates, virtual hosting, and content delivery may depend on the hostname.

System DNS, browser Secure DNS, and mihomo’s built-in DNS are separate parts of the path. A browser may use encrypted DNS on its own, and some apps bypass system settings entirely. So a successful system lookup does not mean the browser uses the same path, and a failed system lookup does not necessarily mean the proxy core cannot resolve names. On Windows, run nslookup example.com to check system resolution. On systems with the tool installed, you can also run dig example.com. Compare these results with the client logs; neither command alone gives you the full answer.

Rule out circular dependencies before clearing the cache

An encrypted DNS service needs a connection and may also need to resolve its own server name. If connecting to the proxy requires resolving the proxy server, but resolution must go through that proxy before it is connected, you have a circular dependency. Make sure bootstrap resolution, proxy server resolution, and ordinary destination lookups each have a clear path. Don’t force all DNS requests through the proxy and then route the proxy server’s own hostname through the same chain. If you use a subscription, restore its original DNS settings first and add local requirements one at a time.

After changing DNS, cached results may remain unchanged for a while. Reopen the test app and, if necessary, clear the core cache or restart the core as documented by the client. When needed, run ipconfig /flushdns on Windows to clear the system DNS cache; this will not clear every browser or app cache. Don’t keep resetting network adapters instead of identifying which cache is involved. After each step, test the same domain and note whether its request path in the logs has changed.

Understand fake-ip and local domain exceptions

In fake-ip mode, the core may return a mapped address from a reserved range, then use an internal mapping to recover the destination domain. This is how the feature works; seeing that address does not by itself mean DNS has been tampered with. If an app bypasses the core’s routing and tries to connect to the mapped address directly, the connection may fail. An app that retains an old mapping after traffic routing is disabled may also fail temporarily. Restore the correct routing or reconnect the app instead of adding the mapped address to your system hosts file.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  nameserver:
    - https://dns.alidns.com/dns-query

This example shows mihomo-related fields and assumes your network can reach the chosen DNS servers. It is not a complete DNS setup for every network. Merge the fields you need into the existing dns mapping; don’t add a second top-level key with the same name. LAN devices, corporate domains, and split DNS may need to use your router or corporate DNS. Excluding a domain from fake-ip does not automatically select the right internal resolver; configure the resolution policy for your environment.

If a LAN printer, NAS, or company domain stops working with TUN enabled, first turn off TUN to check, then inspect the DNS interception scope, internal name resolution, and private network routes. Don’t force all local traffic through a remote outbound. Corporate networks may rely on search suffixes, split DNS, or a dedicated VPN; switching to a public DNS server can make internal names even harder to resolve. On an organization-managed device, follow your network administrator’s instructions rather than overriding managed settings.

If a page shows a certificate error, don’t hide it by disabling certificate validation. Check the system clock, the domain you actually reached, and the certificate’s subject. A DNS response with the wrong address or leftover intermediary proxy settings can cause similar symptoms. See HTTPS Certificate Errors to narrow down the cause. Verify access to regular websites, sites that require a proxy, and LAN resources so that fixing one type of lookup does not break another.

System Proxy Not Working: Check the Entry Point, Port, and Routing Conflicts

The System Proxy toggle does not route all device traffic

The client’s System Proxy is on, but some programs still connect directly—or your browser works while terminals and games do not. System Proxy generally sets a local proxy address in the operating system; whether an app uses it depends on how that app handles networking. Browsers, system services, and command-line tools may use different proxy mechanisms. Establish a baseline with your browser and an explicit proxy request first. Don’t assume that no log entry for one program means core forwarding has failed.

On Windows, open Settings → Network & Internet → Proxy and check that the address and port match the current client. On macOS, open System Settings → Network, select the active network service, and check its proxy settings. The exact locations may vary between system versions. After switching Wi-Fi, Ethernet, or network location, check which service is active. Automatic proxy scripts and manual proxy settings may come from other software or organization policies. Note the original settings before changing them, and don’t override policies on a managed device.

Check which process is listening on the mixed port

A port shown in the client interface does not prove that the core successfully bound to it. Check the logs for an address-in-use error, insufficient permissions, or a core startup failure. The commands below use mixed port 7897 as an example and only show the listening process; they do not terminate it. Run the first command in Windows PowerShell. Run the second on macOS or Linux if lsof is installed. If your permissions limit the information shown, elevate access as required by your system.

Get-NetTCPConnection -LocalPort 7897 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

lsof -nP -iTCP:7897 -sTCP:LISTEN

If an old client is using the port, confirm the process name in Task Manager or Activity Monitor, then exit the old client normally. Don’t force-close a system service just because you see a process ID. If you switch to another available port, update the app’s own proxy settings and terminal commands too. Changing only the client port while the system proxy still points to the old one leaves the core running but the app unable to connect. Conversely, an old core holding the port may send requests to the wrong configuration.

Check environment variables and TUN mode step by step

Terminal apps may read HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, and NO_PROXY, or only some of them. Check for a stale address in the current session, especially in containers, remote development tools, and integrated terminals. Processes inherit environment variables when they start, so an already-open terminal may not pick up a system variable change. First specify the proxy explicitly for a single test command. If it works, decide whether to set a persistent variable.

Consider TUN only when you need to route apps that ignore system proxy settings. First close other VPNs, network acceleration tools, and duplicate TUN instances, then confirm the client’s required permissions or service mode are working. After enabling TUN, check that the virtual adapter and routes were created; don’t rely on the toggle alone. Some clients can use System Proxy and TUN together, but test each separately while troubleshooting to avoid multiple entry points, detours, or interference from another tool.

Linux desktop proxy settings are not necessarily used by every program. Command-line apps, sandboxed apps, and system services may each have their own configuration. Inside a container, 127.0.0.1 refers to the container itself, not the host running Clash. Letting other devices or containers access the proxy also involves the listening address, firewall, and access controls. Don’t expose the proxy entry point to the public internet for convenience; restrict LAN access to trusted sources too.

Test your browser, an explicit proxy command, and the app that originally failed separately. If the first two work but the app still produces no logs, focus on that app’s entry point. If only TUN causes the failure, check routing, permissions, and DNS instead of repeatedly changing the subscription. This layered approach also helps when proxying occasionally fails after startup: confirm the network is ready and the core is listening, then check that System Proxy is configured correctly.

Client Crashes and Startup Failures: Isolate the Issue Without Losing Your Configuration

Distinguish a closed window from a background process or stopped core

If double-clicking the app opens no window, check the system tray or menu bar and the process list. Some clients stay open after you close the window; starting them again may simply bring the existing instance forward. A hidden window is not necessarily a crash. If the window is open but the core is not running, check the core logs instead of reinstalling the interface. If the process starts and immediately exits, investigate a startup crash. Note what changed after the last time it worked, such as a system update, configuration migration, security software installation, or unexpected shutdown.

Use the client’s supported directory entry point to find its configuration and log locations. If you can’t open the directory, check that client’s documentation instead of deleting files from another app’s folder. Exit the client and its background processes normally, then copy the entire configuration directory to a local backup location. Store any subscription credentials it contains securely; the backup is for recovery, not for uploading to a public support ticket. If you can only retrieve the logs, keep the entries around the latest failed startup and relevant system events.

Check runtime requirements, architecture, and security blocks

On Windows, some clients rely on the WebView2 runtime. If an error mentions loading it, repair the runtime through an official channel listed in the system or client documentation. The fact that a different client opens does not prove this one has everything it needs. Check that the installer matches your operating system architecture and that the archive has been fully extracted to a writable folder. Running the app from an archive utility’s temporary preview directory can make its resource or data files unavailable.

On macOS, check that the app is in an accessible location and whether system security settings recorded a reason for blocking it. If you see a security warning, verify where the app came from instead of disabling system protections wholesale. On Linux, distinguish package dependencies, the graphical session, and file permissions. Starting the app from a terminal may reveal missing dependencies that are not shown in the interface. Distros and desktop environments differ; install dependencies named in the actual error rather than reinstalling the entire desktop environment.

If security software quarantines the core, the window may open normally while all connections fail. Check the quarantine log and confirm the file’s source before taking action; don’t exclude an entire drive. A port conflict can also prevent the core from starting. Use the port listener check to see whether an old instance is using it. In service mode, the interface and background service may run independently. If an upgrade leaves them with mismatched paths, use the client’s service management controls to repair them.

Compare with a fresh user configuration

If the runtime looks fine, leave your backup untouched and rename the original configuration directory, then create a fresh user configuration using the client’s supported method. Fully exit the client first; don’t move a database while it is being written. If the fresh configuration starts, the issue is more likely to be stale client state, an override script, a damaged configuration, or interface data. Then import one trusted subscription and verify it works before restoring custom rules and settings one at a time. Don’t copy the entire old directory back over the new one.

If the fresh configuration also fails to start, check the system app logs, available disk space, and directory permissions. A full system drive can prevent configuration writes, and protected folders may block required updates. Data file ownership or permissions may also be inconsistent if you previously ran the app as an administrator and later switched to a standard account. Limit repairs to the client’s data directory. Don’t grant broad write access to your entire user folder or recursively change permissions on system directories.

If you need to reinstall, exit or uninstall the old app normally, handle its service as documented, then choose a suitable build from the downloads page. Clash Plus is the recommended option for a new installation. If you already use Clash Verge Rev or FlClash, try repairing your current setup first. If an archived client has new compatibility issues, reinstalling the same app may not help; consider migrating your configuration instead of relying on disabled security protections to keep it running.

Mobile Troubleshooting: VPN Permissions, Background Limits, and Network Changes

Android says connected, but apps still can’t access the internet

A VPN icon on Android means the system has established a traffic-routing state; it does not prove that the subscription, outbound, or DNS is working. Keep the client open in the foreground, select an imported configuration, test in a browser, and check the logs. If the browser works but one app does not, check per-app proxy settings or the bypass list and make sure the app has not been excluded. Clients may offer opposite modes—proxy only selected apps, or bypass selected apps—so check which mode is active.

The first time you connect, Android asks you to authorize VPN routing. If you denied it, return to the client and start the connection again instead of enabling a system-proxy-style option. Android generally allows only one regular VPN app to route traffic at a time. Other proxies, VPN-based filtering tools, and corporate access may replace one another. Keep just one routing tool active while testing. Work profiles, managed configurations, and always-on VPN settings may have additional restrictions. Check your organization’s policy on managed devices instead of trying to remove management components.

Drops while the screen is locked and recovery after changing networks

If the connection works in the foreground but drops when the screen locks, check battery optimization, background activity permissions, and the manufacturer’s auto-start settings first. See whether the client still shows the foreground service notification required by the system, then allow necessary background activity as documented. Not every drop is caused by battery optimization: network sleep, Wi-Fi-to-cellular handoffs, and expired upstream sessions can look similar. Note when you lock the screen, the network type, and whether reopening the app restores the connection immediately.

After switching from Wi-Fi to cellular data, existing TCP or UDP sessions may no longer work because the network address, routes, and DNS have changed. Have the affected app reconnect, or disconnect and reconnect in the client if needed. Don’t keep switching nodes before the connection is re-established; that can hide the network handoff as the real cause. If only one Wi-Fi network fails, compare it with cellular data using the same outbound, and check whether that Wi-Fi requires a web sign-in or restricts certain transports.

Android’s Private DNS and the client’s built-in DNS may both affect name resolution. When a domain lookup fails, note the current settings, then test automatic mode and the client’s recommended configuration separately. Don’t keep every DNS setting pointed at a different service. Mobile networks may use IPv6. If only certain domains or protocols fail, check whether the selected outbound and routing mode support IPv6. Avoid disabling IPv6 in just one place while another component continues to prefer those addresses.

Check iOS routing status and configuration

On iOS, choose Clash Plus from the iOS installation page. Product details are available at clashplus.io. After installing, import a subscription and select a configuration, then allow the VPN configuration when prompted by iOS. If the system says connected but pages won’t load, follow the same sequence: destination request, logs, rules, and outbound. The system status alone does not prove that the remote service is working.

If the device has multiple VPN configurations, check which one is active and whether an on-demand connection rule starts another VPN automatically. Work devices may have a managed VPN; don’t remove it without authorization. Some privacy features, configuration profiles, and content filters can also change the request path. Adjust them temporarily only when they are clearly affecting the test, and restore them afterward. If iOS refuses to establish the connection, disconnect other VPNs normally before authorizing and connecting again.

On mobile, also check whether the client is allowed to use cellular data, subscription updates are restricted to Wi-Fi, or data saver is limiting background activity. If updates fail only on cellular, test whether the subscription server is reachable before deleting the app; uninstalling may remove local settings and rules. Before reinstalling, use the client’s supported export or backup feature to save needed settings and protect any credentials they contain.

If you still need help, include the device operating system, client name, other VPNs in use, affected app, network type, and redacted logs from the same time. If you missed a setup step, review the quick start guide. If you have confirmed a subscription or outbound issue, contact the relevant service provider with results from testing on another network. Keeping your last working configuration makes recovery easier than resetting several devices at once.