Clash FAQ and Troubleshooting

The core reads configuration, establishes proxy connections, matches rules, and handles DNS. The graphical client manages subscriptions, switches policies, displays logs, and controls the system proxy. mihomo is an actively maintained core implementation that continues the Clash configuration model, and many newer clients use it as their runtime core. When troubleshooting, record the client name, core type, and configuration source, because interface issues and core errors follow different diagnostic paths.

Rule mode routes requests according to the order of rules declared in the configuration and is best for everyday use. Global mode sends most requests through the currently selected proxy policy, making it useful for temporarily testing a node. Direct mode connects to destinations without using a proxy node. If a site will not open, briefly switch to Global mode for comparison. If Global works but Rule mode does not, check rule matches and policy-group selection instead of repeatedly toggling the system proxy.

A subscription URL is hosted by the configuration provider, and the client can periodically fetch and replace its contents. A local YAML file is stored on the device and maintained by the user. Subscription updates usually overwrite direct edits to the subscribed configuration, so persistent custom rules should go in the client’s supported override, merge, or scripting features. Before importing, confirm that the URL returns YAML or another supported configuration format—not a login page, error page, or regular webpage.

In Fake-IP mode, the core first returns a reserved address to the application, then restores the original domain through an internal mapping before matching rules. This usually reduces repeated lookups while preserving domain information. Some LAN devices, games, enterprise software, and applications that validate real addresses may be incompatible. For LAN access problems, first add the relevant domains to fake-ip-filter. If the issue is broader, temporarily switch to redir-host for comparison to determine whether Fake-IP mapping is responsible.

Start by finding the first parsing error and its line number in the client log, then inspect indentation, colons, hyphens, and quotation marks around that line. YAML requires spaces for indentation, and list nesting must be consistent. Put node names or passwords containing special characters in quotes. Also verify that fields such as proxies, proxy-groups, and rules are at the correct nesting level. If the configuration came from a subscription URL, inspect the response first so a webpage error is not imported as YAML.

Copy the subscription URL into a browser to check whether it returns content, and note the status, response body, and any redirect to a login page. If the browser cannot reach it either, contact the configuration provider about the URL. If the browser works but the client fails, check the client’s network permissions, proxy path, update interval, and local cache. You can delete the failed configuration copy and import it again, but back up override rules first. If the response is JSON, HTML, or blank, confirm that the client supports that subscription format.

TUN mode creates a virtual network interface and changes system routes, so it requires more privileges than a standard system proxy. On Windows, check that service mode is installed and running, and complete the initial setup as an administrator if necessary. On macOS, approve the network extension or helper service. On Linux, CAP_NET_ADMIN, administrator privileges, and an available TUN device are usually required. After fixing permissions, fully quit and relaunch the client, then check whether the firewall is blocking the new virtual interface.

First distinguish between the client not starting and the client starting without enabling the system proxy. On Windows, check the entry status in Task Manager’s startup apps and verify that moving the installation directory did not invalidate the client path. On macOS, review Login Items and background-item permissions. On Linux, check desktop autostart files or user services. If the client starts but does not capture traffic, confirm separately that the options to set the system proxy or enable TUN automatically at startup are enabled.

First verify that the HTTP or mixed port shown by the client matches the address and port in the system proxy settings; the usual local address is 127.0.0.1. Then check whether the browser or application uses its own proxy, a proxy extension, or ignores system settings. Enterprise policies, security software, and other proxy tools may also override the system proxy. Close other networking tools, toggle the system proxy again, and test with a browser known to honor system proxy settings. If only certain applications fail, investigate that application’s proxy behavior.

Some UWP apps run in restricted containers and cannot access a local loopback proxy by default, so a working desktop browser does not mean Store apps will connect. Use the UWP loopback tool provided by the client, select only the apps that need network access, and save the exemptions. Do not select every entry at once; keeping the scope narrow makes the impact easier to control. Restart the target app afterward. If it still fails, verify that the system proxy port is available and check whether the app uses QUIC, its own DNS, or another connection method that ignores the system proxy.

A failed latency test does not necessarily mean the node is completely unavailable; the test address, network egress, and protocol handshake can all affect the result. Confirm that the device’s basic network works, then update the subscription and compare a node in another region or using another protocol. Check the log to determine whether the failure is DNS, a connection timeout, TLS, or authentication. If many nodes time out at once, suspect the local network, subscription status, or test address. If only one node fails, the node itself is more likely unreachable or its parameters may have changed.

First determine whether only domain names are affected or IP addresses are unreachable as well. If IP addresses work but domains fail, check dns.enable, nameserver, fallback, enhanced-mode, and the listen address, and confirm that the configured DNS servers are reachable from the current network. Encrypted DNS left enabled on the system, browser secure DNS, or another local resolver may bypass or occupy Clash DNS. After making changes, clear the system DNS cache, restart the target app, and use the log to confirm that requests are reaching the core.