Clash FAQ

The client handles subscription management, system proxy controls, and the connection interface. The core handles protocol connections, DNS, and rule matching. Clash Meta was a core fork derived from the original Clash and was later renamed mihomo. A client with “Clash” in its name does not necessarily use the same core. To check whether a configuration will work, first confirm the active core in the About or core settings, then check which fields and protocols it supports. Back up your existing configuration before migrating, and don’t assume compatibility based on a similar interface.

Installing a client only installs the software on your device. You’ll usually also need to import a valid subscription or maintain your own configuration. A subscription provides node addresses, authentication details, and policy groups; the client does not create these connection resources automatically. After importing, make sure the configuration is enabled and the policy groups have options, then select a node and test access. If the list is empty, check the subscription response and its format first. Toggling the system proxy repeatedly won’t fix the underlying issue. The provider determines the subscription’s expiration and data limits.

An old configuration may still work, but the client is no longer maintained, so don’t assume it supports newer protocols or fields. Before migrating to a client such as Clash Verge Rev, note your subscription URL, policy group selections, ports, and custom rules, then import and verify them one at a time. A new client being able to parse the file does not mean it will behave exactly like the old setup. Pay particular attention to DNS, TUN, and override settings. Once the new setup is working, close the old client to prevent two proxy processes from changing system settings at the same time.

Rule mode routes connections according to the order of rules in the configuration. Global mode typically sends connections that reach the core to the global policy group. Direct mode connects those same incoming connections straight to their destinations. These modes change how the core handles connections; they don’t automatically route every app’s traffic through the core. If you’re new to Clash, start with Rule mode and check the matched rule on the Connections page. You can briefly switch to Global mode for comparison while troubleshooting, but switch back afterward to avoid changing how other apps connect.

On iOS, visit the Clash Plus App Store page from the downloads page, or check clashplus.io for product information. Whether a subscription is compatible depends on the protocols and configuration formats the client supports; the subscription’s name alone isn’t enough to tell. Check the link type provided by your subscription provider before importing, then make sure all nodes and policy groups appear afterward. Desktop scripts, file paths, and some TUN fields may not work on a phone. If the client reports unsupported fields, adjust the configuration using the mobile documentation instead of repeatedly importing it.

First, check that your device’s date and time are correct, the subscription URL is complete, and your account hasn’t expired or run out of data. Check the client’s update error: authentication failures usually point to incorrect link credentials, timeouts to connectivity with the subscription server, and format errors to a response that may be a login page rather than a configuration. If updates rely on a proxy that no longer works, use a direct connection if the client allows it. Subscription URLs may contain access credentials, so don’t submit them to public converters or include them in screenshots. If the problem persists, ask your provider about service status.

Check your processor architecture in your operating system’s device information, then choose the matching installer. Most Intel and AMD desktop processors use x64; ARM devices should generally use ARM64. Choose the appropriate build for Apple Silicon or Intel Macs as well. On Linux, you also need to match the package format to your distribution—processor architecture alone isn’t enough. If the installer says your system isn’t supported, check the client’s release notes for minimum system requirements. Don’t rename file extensions or force-extract an archive as a substitute for the proper installation process.

TUN creates a virtual network adapter and configures routes. Desktop clients typically do this through a service or an elevated operation. Turn TUN off first, then check the client settings to see whether the service is installed and running. Grant permission as instructed by the client; on Linux, follow the setup for your distribution. Managed devices may restrict drivers or route changes, so check with your administrator. Don’t leave the firewall disabled to work around an error or run multiple tools that take over routing at once. Note the exact error before deciding whether to reinstall the service.

The system proxy provides an address to apps that honor that setting. Some apps use their own proxy configuration, and existing connections may continue using their current route. First, make sure the address and port in system settings match the client’s mixed port. Restart the app, then check the client’s Connections page for new requests. Browser extensions, command-line environment variables, or other proxy tools may override the system setting. If an app doesn’t honor the system proxy, consider TUN. Don’t change nodes or routing rules before confirming where the app’s traffic enters the client.

Some Windows apps isolated with AppContainer can’t access local loopback addresses by default, so they may not connect to a proxy listening on the same device. First confirm the affected app uses this isolation model, then check whether the client can manage loopback exemptions. Enable an exemption for the specific app if needed rather than granting access to every app. Not every app installed from the Store uses the same isolation model, and this doesn’t apply to ordinary desktop programs. If you use TUN instead, check the connection records again to make sure requests are reaching the core.

Open the client’s Connections page, then make a new request from the app you’re testing. Find the connection by domain or process and check its rule, policy group, and actual exit route. Existing long-lived connections may keep their original route, so establish a new connection after changing a rule. Rules are usually matched in order; a broad rule near the top can override a more specific one below it. Also confirm that Rule mode is active. A domain lookup in the log alone doesn’t mean the web traffic went through the proxy—check the connection details and whether the app can access the site.

Subscription updates usually download and replace the configuration, so edits made directly to the downloaded file may not persist. Put rules, DNS settings, and policy group changes you want to keep in the client’s supported override or configuration merge feature, and check the merge order. Clients can handle array additions, field overrides, and scripts differently, so don’t assume instructions for another app will work. Test with a small number of rules, then inspect the merged configuration. When migrating clients, back up your overrides as well as the subscription URL.

Fake-IP returns a virtual address to an app, then the core uses its mapping to recover the domain and establish a connection. This can preserve domain information for routing decisions. Some local network services and apps that rely on real IP addresses may not work well with these responses. If you encounter a specific issue, add the relevant domains to the appropriate filter configuration rather than excluding every domain. After changing the filter, have the app resolve the domain again and establish a new connection. Filtering behavior depends on the core version and filter mode. Read the documentation for your version before copying a configuration so you interpret matches correctly.

A latency test usually measures the time for one request to a specific test address. It doesn’t measure large-file throughput or represent every website. Compare nodes on the same device, against the same destination, and at roughly the same time. Then check whether the slowdown affects only one route or one app. Look at packet loss, server load, the policy group’s exit route, and local network usage. Pause other bandwidth-heavy tasks while testing to avoid interference. If a direct connection is just as slow, check your Wi-Fi or internet connection before adjusting the client.

First, note whether disconnects consistently happen after locking the screen or switching networks. On Android, check the client’s background permissions, battery optimization, and system VPN settings. Some manufacturers impose additional background restrictions. On iOS, check the client’s VPN status and logs rather than assuming every disconnect is caused by background activity. If connections also fail while the screen is on, check the subscription’s validity and node connectivity. Keepalives, reconnection frequency, and network quality all affect battery use, so a protocol name alone can’t tell you whether a configuration will save power.

Not necessarily. An unreachable test address, DNS issue, incorrect device time, or a core that isn’t running properly can cause every node to time out. First make sure your regular internet connection works, then check the error type in the logs and test access with one node. If only the latency test fails but websites load, check the test address and method. If connections also fail, check authentication, account status, and server addresses. Don’t change DNS, TUN, and routing rules all at once, or it’ll be hard to identify the cause. Change one setting at a time and keep its original value.

First, make sure an old client or duplicate instance isn’t still running in the background. Then check the app and service logs or your system event log. If a port is in use, identify the process listening on it, close the duplicate proxy, or choose an available port. Update the system proxy and related app settings to match. If you suspect a corrupted configuration, back up its directory and test with a temporary new configuration as described by the client; don’t delete all your data. Follow the release notes for runtime or system compatibility issues. Before sharing an error screenshot, hide your subscription URL and authentication details.

Turn TUN off temporarily to confirm whether the issue is related to route takeover. Check for conflicts between your local subnet, corporate VPN routes, and virtual adapter addresses. Then configure route exclusions using a method supported by your core and client; adding a Direct rule alone may not prevent traffic from entering the wrong adapter. Corporate networks may also require internal DNS, so check the name resolution path too. Don’t blindly copy someone else’s subnet exclusion list or run multiple automatic routing tools at once. After making changes, test public internet, local network, and corporate resources separately.

Start by defining what you expect: which resolver should handle each domain, and whether requests should go direct or through the proxy. Then compare the core logs with the test results to confirm the actual path. A test site’s reported resolver name or location is a clue, not proof of a leak. Browser Secure DNS, encrypted DNS in the operating system, or another VPN may bypass the client’s DNS settings. TUN’s DNS handling also doesn’t automatically capture all encrypted DNS traffic. Check app settings, DNS routing, and the proxy exit separately; reconnect before testing again after a change.

Check whether your system still points to a local proxy address. If the proxy process has exited, that address is now an unusable endpoint, so turn off any lingering system proxy setting. Then check whether TUN or a VPN is still connected and whether other apps have manual proxy settings or environment variables. If possible, reopen the original client, turn off the system proxy and TUN, then exit normally rather than force-quitting it. If the problem continues, check your routes and DNS settings. Don’t reset all network settings as a first step—you could lose corporate network settings or static addresses.