Clash FAQ

The client handles configuration imports, mode switching, and connection details. The core parses configuration, matches rules, and establishes proxy connections. Clash Meta was the former name for the extended core; the project later adopted the name mihomo. The original Clash and mihomo do not support exactly the same protocols or configuration fields. Before troubleshooting, note the client and core names in the About or core information screen. The window title alone does not establish compatibility. Menu names and locations may also vary between clients.

A client routes connections; installing it does not provide proxy service. Import a server configuration you manage or a valid subscription from your service provider, then activate that configuration. If the list is still empty, check whether the configuration contains only rules, references proxy providers that have not loaded, or is not currently active. Don’t set an untrusted public configuration as the default.

For everyday use, start with Rule mode, which routes connections to direct or proxy policies according to your rules. Global mode sends connections entering the core through the global policy and is useful for brief comparison tests. Direct mode attempts to connect those connections straight to their destinations. These modes change how the core handles traffic; they do not capture app traffic that never reaches the client. Global mode also does not mean every system app is proxied—you still need to check the system proxy or TUN traffic entry point.

A latency test usually makes a single request to a specific test address. It doesn’t cover the target site’s DNS resolution, rule matching, login endpoints, or sustained transfers. Open the Connections panel, visit the site, and check whether a connection appears, which rule matched, and which route it took. If the test succeeds but the site still fails, try different destinations with the same proxy and compare the results with a direct connection. Don’t judge a proxy by one latency figure or assume lower latency means faster downloads.

Some basic configurations may work with newer clients, but compatibility depends on the target core, not the file extension. Back up your configuration and custom rules before migrating. Test in a separate configuration and check protocol types, proxy group references, rule-set paths, and DNS fields. Clash for Windows is no longer maintained, so it’s not a good long-term choice for ongoing updates. When choosing a replacement, check its maintenance status and compatibility with your subscription format.

First determine whether the request failed or the configuration could not be parsed. Timeouts often point to the network path; a 401 or 403 may indicate an authorization issue, request limit, or expired link. For parse errors, check whether the response is a web page or an unsupported configuration. Confirm the subscription hasn’t expired, the URL is complete, and it contains no accidental spaces. Change request settings only if your provider says they’re supported. A link opening in a browser doesn’t guarantee the client can fetch it. Hide the full subscription URL and any access credentials when reporting the issue.

Note the error line, protocol, and core name, then check the format required by your subscription provider. A configuration intended for mihomo may not work directly with the original Clash or another client, and extended options for a protocol may require a particular version. Request a subscription compatible with your client rather than deleting fields one by one. If you use a subscription converter, make sure it’s trustworthy: the converter may be able to access your subscription data and credentials.

TUN creates a virtual network interface and sets routes, usually requiring the client’s service mode, system authorization, or administrator privileges. Check that the core is running, then install or repair the service as instructed by the client. Make sure the system isn’t blocking its components. If the issue persists, note any adapter or route errors in the logs and check for conflicts with other VPNs or virtual network tools. Avoid changing several network settings at once. Change one thing at a time and compare results with TUN disabled.

On Windows, check the processor and system type in System Information. Most Intel- or AMD-based desktops use x64; for ARM devices, check whether the client offers a native build or supports compatibility mode. On macOS, use About This Mac to identify Apple silicon or Intel. On Android, choose an ABI supported by your device rather than guessing from the OS bitness. Check the available builds on the download page and review the project’s system requirements. Renaming a package won’t make it work on another platform.

Check the logs to identify whether the port conflict involves a proxy port, mixed port, or controller port, then find the process listening on it. If another proxy client is running, exit it normally rather than force-quitting an unknown process. If you need to change the port, update the active configuration or client override and then update the corresponding address in your browser, terminal, and system proxy settings. Restart the affected connections and confirm the old port is no longer in use. Changing the value in the UI alone may not help if the core still reads the old configuration.

Open the Connections panel and make a new network request in the app. Check for a matching domain, destination address, or process entry, then verify the rule and route. Existing long-lived connections may not reconnect when you switch proxies, so refresh the page or restart the app’s connection. Seeing the system proxy enabled doesn’t prove every app uses it. If an app has no connection entry, check how it routes traffic before changing proxies or rules.

Rules are usually matched from top to bottom, and the first match determines the policy. A broad rule higher up can override a more specific rule below it. Check that Rule mode is active, your custom rules are included in the effective configuration, and the policy name exactly matches the proxy group. Then check the matched rule in the Connections panel. If the client supports overrides, verify their merge order. Editing a file generated from a remote subscription may be undone on the next update; keep lasting changes in a persistent override.

On the other device, set the proxy server address to the LAN IP of the device running the client and enter the active proxy port—not 127.0.0.1. Make sure the client listens on an address reachable from your LAN, the system firewall allows the port, and the router doesn’t have client isolation enabled. Use this feature only on trusted networks, and configure authentication and access restrictions as needed. Don’t expose proxy ports or the controller interface to the public internet. Enabling the system proxy also won’t automatically cover every app on another device.

Changing a proxy group usually affects new connections. Existing downloads, video streams, and messaging connections may continue using the previous route. Check which policy group the connection uses, then close it or make a new request in the app if needed. A configuration may contain multiple policy groups, so changing the default group may not affect a particular site. Browser results can also be affected by cached data or background connections. Check the Connections panel instead of repeatedly running proxy tests.

Include the client and core names, operating system, time of the issue, reproduction steps, and error logs from around that time. Note whether TUN, the system proxy, or another VPN was enabled. Raise the log level only temporarily while reproducing the issue, then restore the normal level. Before sharing, redact subscription links, authorization parameters, proxy passwords, controller keys, and personal hostnames. Share the smallest reproducible excerpt you can; don’t post your full configuration in a public forum or upload unchecked screenshots.

Disable the proxy first and confirm your basic network connection works. Then check whether the subscription has expired, the system clock is correct, and the core logs show DNS or handshake errors. Test the same configuration on your current network and another trusted network to narrow down the cause. If only one proxy fails, check its status first. If all proxies time out, the test address itself may be unreachable; that doesn’t necessarily mean every server is down. Keep the configuration and test destination unchanged for each round, and avoid changing DNS, mode, and proxy at the same time.

Check that the system proxy address and port point to the active core. Also check whether a browser extension, an app-specific proxy setting, or a bypass list overrides the system setting. Some terminal tools don’t use the system proxy and need separate proxy options or environment variables; already-running processes may also retain old settings. If the Connections panel shows nothing, fix the traffic entry point first. Global mode is not a traffic-capture switch: it handles only connections that reach the core and can’t force every app to use the system proxy.

Some Windows apps isolated in app containers can’t access the local loopback address by default. This can cause a Store app to fail even when a browser works. First confirm the app uses the system proxy and that the proxy port is available. Then use the client’s loopback exemption tool or Windows CheckNetIsolation to check the app package. Grant exemptions only to the apps that need them; don’t enable them for every app. If enabling TUN fixes the issue, note the difference between the two traffic entry points rather than attributing every connection failure to loopback restrictions.

First decide which resolver should handle your domains. Then check whether the app’s secure DNS, system resolver, client DNS, and TUN DNS capture work as expected. A browser-based DNS test can offer clues, but it can’t establish how every app resolves domains; routing rules may also vary by domain. Verify each part using core logs, connection records, and test domains you control. Don’t copy a full DNS configuration without checking it—especially upstream resolver reachability and bootstrap resolution for proxy server hostnames.

Don’t ignore it or install a root certificate from an unknown source. Normal proxy forwarding doesn’t require decrypting browser HTTPS traffic. Check the system clock, destination hostname, and certificate chain, and look for HTTPS inspection by security software, a captive portal, or unexpected DNS resolution. Compare results with the proxy disabled, another trusted proxy, and other websites, and note the browser’s error code. If the page involves an account or payment, stop before entering sensitive information and investigate the specific error first.