Clash Troubleshooting Guide for Apple Devices

No internet: isolate the direct and proxied connections first

Start with a baseline test outside the proxy chain instead of reinstalling right away. Turn off the system proxy and TUN in the client, then quit the app. On iPhone, disconnect the corresponding VPN. Visit a site that normally works without a proxy, then test another device on the same network. If both fail, check Wi-Fi, your router, or your ISP first. If only this device fails, look for leftover proxy settings, other VPNs, or local DNS issues. Until the baseline connection works, node test results aren't a reliable comparison.

Establish a repeatable local network baseline

On macOS, open “System Settings → Network” and check whether you're using Wi-Fi or Ethernet. Hotel, airport, and campus networks may require sign-in through a captive portal; connecting to Wi-Fi doesn't necessarily mean you have internet access. Disconnect the VPN temporarily to complete sign-in, then reconnect the proxy. Check that the system clock is correct, too. A clock that's out of sync can cause TLS certificate errors across multiple HTTPS sites, rather than a simple Wi-Fi disconnection.

Next, run just one proxy client and leave TUN off for now. Confirm that the right config is selected and the core is running, then enable the system proxy. If several apps manage the system proxy, one may leave its address configured after it exits. Running multiple tunnels at once also makes routing harder to diagnose. Keep any work VPN you need, but note its state during each test and don't change it between runs.

Use an explicit proxy test to separate the local entry point from the remote connection

The commands below test a direct connection and an explicitly specified local HTTP proxy; both request headers only. Port 7890 is an example—replace it with the mixed port shown in your client. You can use another known reachable site as the test target. A successful command confirms only that this route to this target works; it doesn't prove every app, UDP, or routing rule is working.

# macOS: bypass proxy environment variables and test a direct connection
curl -I --noproxy '*' --connect-timeout 10 --max-time 20 https://www.apple.com/

# Specify the mixed port the client is actually listening on
curl -I --proxy http://127.0.0.1:7890 --noproxy '' \
  --connect-timeout 10 --max-time 20 https://www.apple.com/

If the explicit proxy immediately returns a connection-refused error, the issue is usually at the local entry point: the core isn't running, the port is wrong, or the listener failed. If it times out, check the client connection log to see which policy and node the traffic used. If the proxy test works but your browser doesn't, focus on system proxy settings instead of repeatedly testing remote nodes. If direct access works but proxied access doesn't, the issue is now narrowed down to the config, rules, or remote connection.

Check routing rules, DNS, and TUN separately

Temporarily switch from Rule mode to Global mode, select a known working proxy node, and visit the same target. If Global mode works but Rule mode doesn't, check the target domain's matching rule, the selected policy group, and the direct connection route. Switch back to Rule mode when you're done. Global mode changes how traffic is routed; it doesn't force apps that ignore the system proxy through the client, and it doesn't prove that TUN is working.

If the browser says it can't find the server, start with the DNS section. If the failure happens only with TUN enabled, turn TUN off and test again. Then check whether the helper service, default route, or DNS interception conflicts with another tunnel. Don't change the gateway, remove every network service, or delete system files all at once. Restore the smallest working setup—the system proxy—then expand traffic capture one step at a time.

Node timeouts: distinguish failed probes from failed connections

A node showing a timeout doesn't necessarily mean it's offline. Latency checks usually connect through the node to a test endpoint, so results depend on the target, DNS, node egress, and timeout settings. Select the node and test two different targets in a browser and through an explicit proxy, then check the connection log. If only the probe fails but websites work, review the probe target and method. Check the server connection and protocol settings only if actual connections fail, too.

Pinpoint the stage where the connection fails

Connection refused, dial timeout, certificate error, and authentication failure mean different things in the log. Connection refused usually means the destination is reachable but isn't accepting connections on that port. A dial timeout can indicate packet loss, a firewall, or an unreachable address. Authentication failures point to credentials, a user ID, or server settings. For certificate errors, check the clock, server name, and certificate chain. Keep the full error and relevant surrounding log lines; a screenshot showing only “Failed” isn't enough.

First check whether you've selected an individual node or a policy group such as Auto Select, Failover, or Load Balance. The name displayed for a policy group may not identify the actual egress used for a connection. Open the connection details and check the target, matching rule, policy chain, and node in use. If a rule sends the request DIRECT, the node test and that request took different routes and can't be compared as if they were the same.

Check the server hostname and protocol fields

If the subscription downloads normally but every node times out, check whether the node server hostname resolves before replacing all your passwords. Server hostnames may use a separate proxy-server-nameserver, which doesn't necessarily follow the same path as DNS for regular websites. If the result includes IPv6 but your network has an unreliable IPv6 route, some networks may work while others hang. Check the address family and error before making changes.

If only one node fails, compare its address, port, transport, TLS, SNI, and core support with the original subscription fields. Don't use the node's IP as its SNI, and don't disable certificate verification to get rid of a certificate error. With protocols that validate a hostname, the connection address and certificate name may serve different purposes. Changing either field arbitrarily can turn a routing issue into a handshake failure.

# Look up the DNS records for a server hostname
# example.com is a sample domain; replace it with the node's actual server hostname
dscacheutil -q host -a name example.com

# Test TCP port reachability only; this does not check proxy authentication or UDP
nc -vz -G 5 example.com 443

A successful TCP test confirms only that a TCP connection was established. It doesn't verify proxy authentication, UDP forwarding, or access to the target website. For a UDP-based protocol, it doesn't even test the relevant transport. Don't treat this as proof that the server is fully operational. If the command fails, confirm that you used the actual port and account for whether the current network allows that transport.

Use network comparisons to identify external restrictions

Keep the node and config unchanged, then test on home Wi-Fi and a mobile hotspot. If the hotspot works but the original network doesn't, check that network's access policies, UDP restrictions, or routing quality. If both fail while other nodes work, the node or server settings are more likely at fault. Avoid rapidly probing a large number of nodes; this can trigger server-side limits and add connection load that makes results harder to interpret.

If the current core doesn't support the protocol, use the download page to choose a maintained client that does. For Apple devices, consider Clash Plus first, then compare other options for your needs. A core and a client app aren't the same thing; see Clash, Meta, and mihomo: Core Differences. Keep your original config before switching clients, and test the same node afterward so you can distinguish a client change from a network fix.

Subscription failures: check download, parsing, and activation separately

Subscription problems can occur at three stages: the remote content fails to download, the downloaded content isn't a valid config, or a valid config isn't activated. First identify which stage failed. HTTP errors, connection timeouts, and certificate failures usually happen during retrieval. YAML line numbers, incorrect field types, and unsupported protocols point to parsing. If the update succeeds but the node list doesn't change, check the selected config, overrides, and proxy provider cache. Repeatedly deleting the subscription can erase useful clues, so don't make it your first step.

Download stage: check the URL, access, and update route

Copy the full subscription URL again from your provider and check for leading or trailing spaces, line breaks, and characters changed by a chat app. URLs with query parameters may contain access credentials; don't post them in public discussions or send them to an unknown online converter. Opening your provider's homepage doesn't prove you have access to the subscription endpoint. The homepage, account sign-in, and subscription download may use separate authorization paths.

Status codes 401 and 403 usually point to authorization, expiration, or access policy issues. A 404 may mean the path changed or the URL is invalid. A 429 means too many requests; wait instead of repeatedly clicking Update. Even a successful status isn't enough if the response body is a sign-in page, verification page, or error message rather than YAML. Check the response summary in the client and don't keep full credentials in your logs.

Some clients let you choose whether subscription updates use a direct or proxied connection. During initial setup, the proxy may not be working yet, creating a loop: you need the subscription to connect, but need a connection to update the subscription. If your network allows it, update directly or use an independent working connection to retrieve the config. Don't route updates through a node that's already failing without checking first. Change the route, update once, and note whether the error changed.

Parsing stage: distinguish node links from full YAML configs

Generic Base64 node lists, individual protocol links, and Clash YAML are different input formats. A full config may contain fields such as proxies, proxy-groups, and rules; a node list may need to be added as a proxy provider. First confirm which format the import option accepts, then decide whether conversion is needed. See Subscription Formats and Conversion for examples. A file extension alone doesn't tell you what's inside.

When a parsing error gives a line number, check that line and the one before it. A missing colon, tab indentation, an unclosed string quote, or inconsistent indentation in a list can cause the next line to be flagged. The local example below is only meant to illustrate structure; it doesn't include working proxy nodes. Don't replace your full remote config with it and expect nodes to appear.

mixed-port: 7890
allow-lan: false
mode: rule
proxies: []
proxy-groups:
  - name: Manual Selection
    type: select
    proxies:
      - DIRECT
rules:
  - MATCH,Manual Selection

Activation stage: check the active config and its overrides

After an update, confirm that the client is actually using the newly updated config. Some clients handle downloading, saving, and activating as separate steps; proxy providers may also refresh on their own schedule. Check the current policy group members and load log, not just the subscription card's update time. If the node count changes but the rules don't, a template or override may be preserving local rules; that doesn't necessarily mean the remote update failed.

Remote configs are usually replaced by the next update, so put persistent changes in a client-supported override, merge, or extension config. For troubleshooting, disable nonessential overrides and keep a copy of the original file, then compare with the unmodified subscription. If the original works but the merged config fails, re-enable overrides one at a time to find the conflict. Don't edit the remote file and local template simultaneously, or it'll be hard to tell what actually took effect.

Slow speeds: measure latency, throughput, and app behavior separately

Low latency doesn't guarantee fast large downloads, and high latency doesn't always mean low throughput. Web performance also depends on DNS, handshake count, the number of resources, and limits imposed by the destination. Start by describing the symptom: slow initial page load, slow sustained downloads, video buffering, or lag in just one app? Compare the same device, network, target, and approximate time. Don't rank results from different speed test sites or content delivery routes as if they were directly comparable.

Build a minimal test matrix

With the proxy off, first visit a destination that should be directly reachable to check for obvious Wi-Fi or broadband bottlenecks. Then use a fixed node to compare explicit proxy access with normal browser access to the same target. Change only the node and repeat. If all nodes are slow but direct access is fine, check how the client captures traffic and whether the device is under load. If only one node is slow, look at the route between that node's egress and the destination instead of changing system-wide network settings.

Also check the CPU, memory, and network tabs in Activity Monitor. Background sync, OS updates, and cloud uploads can saturate the upstream connection and slow website acknowledgments—even when download bandwidth isn't maxed out. Pause tasks you've confirmed are using substantial bandwidth, then test again. Don't force quit unfamiliar system processes. Avoid leaving diagnostic logs at the most detailed level; frequent disk writes add load and accumulate sensitive connection data.

Identify DNS, handshake, and download stages

Use the command below to get DNS, TCP, TLS, and total timing as clues. With an HTTP proxy, some fields describe the connection to the local proxy; the proxy may resolve the destination hostname itself, so time_namelookup doesn't represent the full remote DNS lookup time. Use the client log to identify where a request stalls rather than drawing conclusions from a single value.

curl --proxy http://127.0.0.1:7890 --noproxy '' \
  --connect-timeout 10 --max-time 30 \
  -o /dev/null -sS \
  -w 'dns=%{time_namelookup}\ntcp=%{time_connect}\ntls=%{time_appconnect}\nfirst=%{time_starttransfer}\ntotal=%{time_total}\n' \
  https://www.apple.com/

If TLS completes quickly but the time to first byte is long, look further into the destination server's response and the egress route. If the connection phase keeps retrying, consider packet loss, address family, and node reachability. One small request doesn't indicate sustained throughput, and the server may throttle test files. Don't launch frequent concurrent downloads just to get a better number: they use subscription bandwidth and may trigger restrictions on the destination.

Check UDP, MTU, and architecture differences

Video, calls, and games may use UDP or QUIC, which a regular browser HTTPS test doesn't cover. Confirm whether the app's traffic enters TUN, whether the node supports the required forwarding, and whether the current network restricts UDP. If the app supports a transport fallback, try it temporarily for comparison. Disabling all UDP isn't a general-purpose optimization: it changes app behavior and may prevent calls from connecting.

An MTU mismatch can allow small requests while large transfers stall, but it doesn't explain every slow connection. Adjust MTU in small increments, only in a TUN config that supports it and when network comparisons, logs, and transfer behavior all point to an MTU issue. Record the original value and test each change. On Apple silicon Macs, prefer an arm64 build to reduce translation as a variable, but a different architecture won't increase remote network capacity. See client comparisons for differences between options.

Aim for a reproducible conclusion, such as “the same target works on a hotspot but stalls consistently on home Wi-Fi,” rather than “all nodes are slow.” The first points to the router, network policy, or route. The second still mixes variables such as nodes, destinations, and timing. After testing, restore your usual log level and verify with the apps you actually use; a single speed test isn't a sufficient endpoint.

DNS issues: check the resolution path, fake-ip, and leak boundaries

Start DNS troubleshooting with three questions: what initiated the query, which resolver received it, and what used the result to connect? System DNS, browser Secure DNS, the client's built-in DNS, and node server hostname resolution may all be involved. A website failing to load doesn't necessarily mean DNS failed, and a DNS test site showing a particular region doesn't prove the request took the expected route. First check whether the hostname resolves, then compare the client connection log with the actual egress.

Distinguish system DNS from client DNS

On macOS, run scutil --dns to see resolvers and their scopes. The output may include default, interface-specific, and VPN-provided resolvers; don't judge where all domains go from the first entry alone. Corporate intranet domains may rely on split DNS, so changing every resolver to a public DNS service can break internal access. Browsers using their own Secure DNS may also bypass the system resolver.

# Show current macOS resolvers and their scopes
scutil --dns

# Look up a sample hostname through the system resolver
dscacheutil -q host -a name www.apple.com

# Run only if you need to clear stale cache after changing the configuration
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Clearing the cache removes stale results; it can't fix an incorrect upstream resolver or route. Tools such as dig are useful for querying a specific resolver, but their default behavior may not match the full system resolution path used by macOS apps. If the command-line and browser results differ, first confirm the query path and cache rather than assuming one tool is broken. With encrypted DNS, also confirm that the resolver hostname has a working bootstrap resolution path.

Understand when fake-ip traffic is intercepted

In mihomo fake-ip mode, apps can receive mapped addresses that the core later associates with the original hostname. These aren't the destination server's real IP addresses; seeing them doesn't mean DNS is poisoned. The key is whether the same core still handles the subsequent connection. If an app has cached a mapped address after the client exits, or system DNS points to the client after its listener stops, access may still fail even after you disconnect the proxy.

# Example mihomo DNS snippet; this is not a full subscription config
dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query

This example listens only on the local loopback address, and its upstream resolver must be reachable on your current network. Standard system DNS settings generally can't use a custom port such as 1053 directly. Enabling this listener alone won't send every system query to it; you'll also need DNS interception, TUN capture, or another explicit client setting. A graphical client may override these fields, so check the loaded config and startup log.

Choose the right fix based on the symptom

If only local device names, printers, or corporate domains fail, check local discovery, split DNS, and fake-ip filtering rather than sending every domain DIRECT. Add only confirmed incompatible domains to a filter list supported by your client, and preserve the internal DNS route. If node hostnames also fail to resolve, fix the node's bootstrap DNS first; you can't rely on a node that isn't connected yet to resolve its own server address.

If the proxy works but an external test shows an unexpected resolver, temporarily disable the browser's independent DNS and compare again. Then check TUN DNS interception, IPv6, and bypass rules. DNS queries going DIRECT and application traffic going through the proxy are separate decisions; evaluate them against your actual privacy requirements. A test site checks only the query methods it was designed to test, so it can't guarantee that every app's DNS traffic is captured.

After a fix, test a regular hostname, the hostname that failed, and any required intranet domains. Then disconnect and reconnect the client to confirm that the system resolver recovers properly. For everyday use, choose a DNS setup you can explain; avoid interdependent forwarding chains across system, browser, router, and client settings. If you need to change TUN capture, see macOS TUN Authorization to check how it works.

System proxy not working: check settings, listeners, and app behavior

The macOS system proxy is a network setting that apps can choose to use; it doesn't force all device traffic through a proxy. Browsers may follow it, while command-line tools, games, and apps with their own network stack may not. First confirm the client entry point works with an explicit proxy, then check whether the system settings were applied to the network service currently in use. If the entry point works but one app still connects directly, check that app's proxy support and consider TUN only if needed. Repeatedly toggling the system proxy won't help.

Confirm the settings apply to the active network service

Open “System Settings → Network → Current Network Service → Details → Proxies” and check the web proxy and secure web proxy host and port. Labels may differ slightly between macOS versions, but always check the service currently online. Wi-Fi proxy settings don't automatically apply to Ethernet. After switching a dock, hotspot, or network location, the old service may keep its settings while traffic now uses a different service.

# Show a summary of the current proxy settings
scutil --proxy

# List network services to match their names with System Settings
networksetup -listallnetworkservices

# Check whether the sample port is listening for TCP connections
lsof -nP -iTCP:7890 -sTCP:LISTEN

HTTP, HTTPS, SOCKS, and automatic proxy configuration can each be enabled separately. If a manual proxy and PAC are both configured, check which one the app actually uses; don't assume manual settings always take precedence. Organization-managed devices may also have configuration profile restrictions. Follow your organization's network requirements instead of trying to remove managed settings. If the client can't update the proxy settings, its logs are often more helpful than the state of the toggle.

Check the listening address and mixed port

The listener host is usually 127.0.0.1; use the port configured in the client. Don't enter a remote node's server port as the system proxy port or confuse it with the controller port. If another process is using the port, the core may fail to start or the system proxy may point to the wrong app. Check the process name in the listener output, then quit the relevant app normally instead of terminating an unknown process.

This minimal snippet shows a local proxy entry point, not a remote node. mixed-port accepts both HTTP and SOCKS proxy connections. It's not a DNS port, and external websites shouldn't connect to it directly. If the graphical client has its own port setting, change it there first to avoid conflicts between generated config and manual edits.

mixed-port: 7890
allow-lan: false
mode: rule

Check app-specific proxies and terminal environment settings

Terminal programs may read environment variables such as HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, and NO_PROXY, or may accept only their own options. Never paste variable values containing passwords into public logs. Temporary command-line options are useful for diagnosis because their scope is clear; once confirmed, set a persistent proxy using the tool's documentation. Note that HTTPS_PROXY can still use an HTTP proxy endpoint such as http://127.0.0.1:7890.

Browser extensions, in-app proxies, and system proxy settings can override one another. Turn off proxy extensions and test in a new window. If needed, quit and reopen the app so it doesn't reuse an existing connection. Changing a node or rule after a connection is established won't necessarily change the route of that existing connection. Start a new request and confirm it in the connection log instead of just refreshing a page with a long-lived connection.

If an app doesn't support the system proxy, use the client's TUN capture if available. First confirm the helper service is installed and authorized, and that no other tunnel is conflicting. Clients may use a helper service or a network mechanism built into the system; you don't always need to install the same extension. After quitting the client, check that proxy settings have been restored. If the network goes offline, disable any leftover proxy settings and recheck the entry point as described in this section; don't leave security features disabled as a permanent workaround.

App crashes: distinguish a closed interface, stopped core, and system block

A disappearing window, a stopped core, and a system block on launch are three different problems. The core may keep running after the interface exits, or the interface may show stale status after the core crashes. Note when it happens: on launch, after importing a config, when enabling TUN, or after waking from sleep. Don't immediately delete the whole data directory. Configs, logs, and crash reports are key evidence for identifying the trigger, and reinstalling the app may not clear these states.

Check the architecture, source, and system alerts

On Apple silicon Macs, choose an arm64 or Apple silicon build; on Intel Macs, choose x86_64. Check your chip under “About This Mac.” A Universal build may include both architectures; follow the app's documentation. Use the macOS download page to choose an installer and avoid switching between multiple old copies. Clash Plus is a good first client to consider; compare other options based on system requirements and maintenance status.

If macOS warns that the app is damaged, the developer can't be verified, or permissions are restricted, first confirm the download source and the client's release notes. Don't immediately run commands to disable system security. Managed devices may also have app execution policies. An incompatible architecture, unsupported macOS version, or security block can all prevent launch, but each needs a different fix. Keep the exact alert text instead of describing every case as a “crash.”

Collect evidence before trying a minimal launch

Check crash reports in the macOS Console app, or export the relevant time range from the client's log viewer. Determine whether the report is for the graphical interface, the mihomo process, or a helper service. Note the steps that triggered the issue and the most recent changes, such as a new override, core switch, DNS change, or TUN activation. Logs may contain hostnames, server details, and subscription information; redact them before sharing. Don't send your entire user directory.

Keep a copy of your config, then disable auto-start, auto-connect, and TUN before launching with a minimal config. Restore subscriptions and overrides one at a time. If the minimal config works but the original causes an exit, narrow it down to a specific field or rule set. If the app exits before loading any config, focus on the app, runtime environment, and system report. If the client has a supported safe mode or recovery option, use it rather than guessing the data directory name.

Check helper services and resource usage

If the failure happens only when TUN is enabled, check that the helper service belongs to the installed client and whether an upgrade requires it to be repaired. Also check whether another VPN is taking over the route. Regular users shouldn't replace system extension files manually or lower the system startup security level. Use the client's built-in service install, repair, or uninstall option. If a permission request doesn't match the release notes, stop and verify the source instead of repeatedly granting access.

If the app exits after running for a while, monitor memory pressure, log size, and connection count over time. Frequent refreshes of large rule providers, repeated reconnects, or continuous verbose logging can increase system load. Reduce variables unrelated to the diagnosis: restore the normal log level, pause nonessential refreshes, and reproduce the same workload. Don't mask the issue by clearing every rule or disabling certificate verification; the interface might stay open, but you'd lose important security and routing protections.

Clash for Windows and ClashX Meta are archived options. For compatibility issues on newer systems, prioritize actively maintained alternatives instead of copying an old config wholesale into a new app. Clients may handle config merging, helper services, and storage differently. Start with a minimal working subscription, then migrate rules and preferences. This helps separate config issues from compatibility problems in the new client.

If the issue is still reproducible, report it through the project's or app's public support channel with your OS and architecture, client name, reproduction steps, minimal config, and redacted logs. Don't invent version details or write “latest” instead of the identifier shown in the app. Once things work again, turn auto-connect back on and test a normal quit and restart to make sure no stale system proxy or unusable background service remains.

Mobile troubleshooting: iPhone, iPad, and Android network changes

On mobile, first compare the VPN status in system settings with the connection status in the app, then check whether you're on Wi-Fi or cellular data. iOS proxy apps use network extension mechanisms approved by the system; macOS helper services and terminal commands don't apply. Clash Plus is a good first choice for iPhone and iPad; find App Store and website links on the iOS Clients page. Check each app's supported config formats, rules, and settings.

iOS says connected, but there's no internet

Disconnect in the app first, then check “Settings → General → VPN & Device Management” for another active VPN. Configs from multiple apps can coexist, but simultaneous tunnels and on-demand connection rules can interfere with each other. Temporarily turn off auto-connect for the other app and test again. Don't delete configurations installed by your organization. During first-time setup, the app's ready state doesn't mean the system tunnel is active until you've approved the VPN configuration.

If it fails only on cellular, check the app's data permission under “Settings → Cellular,” along with your plan and system data mode. If it fails only on one Wi-Fi network, disconnect the VPN and complete any captive portal sign-in. After a network change, an existing connection may still be bound to the previous interface. Reconnecting the client and making a new request is usually a better recovery test than repeatedly refreshing an old page. Note the results before and after the change; switching nodes at the same time invalidates the comparison.

iOS background behavior differs from desktop. An app being out of the foreground doesn't necessarily stop its network extension, and removing its card from the app switcher isn't a reliable way to restart the service. Use the in-app connection toggle and check the actual status in Settings. If the device gets hot or drains quickly, look for repeated reconnects, frequent config updates, or other high-bandwidth apps. Don't assume the proxy is responsible just because VPN appears in the status bar.

Local network access, privacy features, and routing rules

If you can't reach a printer, TV, or other local network service, check the app's Local Network permission and the client's LAN bypass rules. Connecting by IP and discovering a device by name may use different mechanisms; a successful IP connection doesn't prove multicast discovery works. Test them separately and preserve any required local DNS and routes. Don't force all private network traffic through a remote server to fix access to one device.

iCloud Private Relay and system privacy options such as “Limit IP Address Tracking” can change the route for some traffic, but they aren't general-purpose VPN tunnels. If you suspect a conflict, note the original setting, temporarily disable it for a comparison, then turn it back on. Don't blame these features for every connection problem. Focus on whether the app's request entered the current client, which rule it matched, and which egress it used.

Android and cross-device config differences

On Android, choose Clash Plus, Clash Meta for Android, FlClash, or Surfboard from the download page. If background connections drop, check system battery management, background data permissions, and the app's VPN settings; menu paths vary by manufacturer. Also note Private DNS, other VPNs, and always-on VPN settings. If failures happen only with the screen locked, reproduce the background restriction before changing every node's protocol.

Using the same subscription on a Mac, iPhone, and iPad doesn't mean you should use the same runtime settings everywhere. Don't copy desktop listener ports, controller settings, file paths, or helper service options onto a phone. Share nodes and necessary rules, but keep platform-specific runtime settings local to each app. See Config Sync for Mac, iPhone, and iPad for sync options. After importing, check what the client actually loaded; matching subscription names don't guarantee matching behavior.

If the problem persists, create a minimal reproduction report with the device OS, current network, client, selected policy, failed destination, approximate time, and a redacted error summary. Avoid resetting all network settings right away; that can remove other connection configs and make recovery harder. To repeat the installation and connection steps, return to the Getting Started guide. If only a specific hostname or node still fails, continue with the relevant section on this page instead of reinstalling everything.