Clash FAQ
Configuration & Connection Troubleshooting

The client handles subscription management, its interface, and system integration. The core handles protocol connections, DNS, and rule matching. Clash.Meta is a core fork developed within the Clash ecosystem and later maintained under the name mihomo; the original Clash and mihomo do not support the same feature set. To check whether a protocol is supported, look at the core the client actually uses and its support list—not just the app’s name. The same YAML may behave differently across cores. Back up your configuration before migrating, and check logs for unknown fields or unsupported protocols.

For a fresh install, compare Clash Plus, Clash Verge Rev, FlClash, and Clash Nyanpasu for OS support, core update methods, and service modes, then choose what fits your workflow. Clash for Windows is discontinued; an older version launching successfully does not mean it supports new protocols or future OS changes. Before migrating, export your subscription URLs and custom rules, then import them into the new client. Recheck ports, TUN, and startup settings rather than copying over the entire app directory. Once the new client connects successfully, disable the old client’s startup task and background service to prevent both proxies from taking over the network.

Rule mode routes connections according to the order of rules in your configuration and is suited to everyday use. Global mode applies the global policy to connections that reach the core, making it useful for checking whether a routing rule is causing an issue. Direct mode sends connections that reach the core straight out, which is useful for comparison tests. Global mode does not capture all device traffic: apps that bypass the system proxy or TUN may bypass the core entirely. For troubleshooting, compare Rule and Global results, then check which rule matched in the connection log. When you switch back to Rule mode, make sure the relevant policy group is set to an available node.

The system proxy registers a local proxy address with the OS, which browsers and apps that honor the setting typically use. TUN captures eligible traffic through a virtual network interface and routing, including traffic from some apps that ignore the system proxy. You do not have to enable both; the right setup depends on the client and the apps you use. To start, verify your subscription and nodes with the system proxy, then enable TUN if needed. If switching modes causes traffic capture conflicts or connection issues, test with just one traffic entry point at a time. Also check whether another VPN, virtual adapter, or security app has changed the same routes.

In the client’s Subscription or Configuration page, choose the option to import from a URL and paste the full address from your provider. Once the download completes, set that configuration as active. Seeing an entry in the subscription list only means the URL was saved; it does not necessarily mean the core loaded it. Next, check that the proxy groups contain nodes and that the core log shows no parsing errors. Select a node and enable the traffic entry point you need. Button names vary by client, so follow the current interface. Subscription URLs often contain access credentials—do not share them in public screenshots, support forums, or untrusted online conversion tools.

Start by checking the HTTP status and error details in the update log. A 401 or 403 may indicate an authorization issue, an expired URL, or server access restrictions; for a 404, check whether the address has changed. For a timeout, first confirm that your device can reach the subscription server. Some clients let you choose whether updates use a direct connection or the proxy; compare both if you already have a working connection. If the download succeeds but parsing fails, the response may be a login page, an error message, or an incompatible format. Ask your provider for a Clash- or mihomo-compatible subscription. Keep a backup of any working configuration, and don’t delete it after a failed update or keep retrying at a high frequency.

First confirm that your client and OS support the TUN implementation it uses, then follow the client’s instructions to install its service component or grant the required permissions. On Windows, this often means enabling the client’s service mode. On macOS, you may need administrator approval for a network component. On Android, confirm the VPN connection request the first time you enable it. On Linux, it depends on service permissions and whether the virtual network interface is available. After granting access, restart the core and check its logs instead of repeatedly toggling the switch. If another VPN is running, stop the conflicting connection first. On managed devices, follow your administrator’s permission policies.

Starting at login, starting the core, and enabling the system proxy are separate settings. Launching the app does not necessarily enable a proxy entry point. First check that the OS startup manager hasn’t disabled the client’s startup task. Then confirm the current configuration is still loaded and its proxy groups still point to working nodes. If TUN relies on a service mode, make sure the background service starts correctly. If the issue only happens right after login, the network may not be ready yet or another VPN may change routes afterward. Wait until the connection is stable, retry manually, and compare the logs. After migrating to a new client, remove the old app’s startup task to prevent it from restoring outdated ports or proxy settings.

A select group lets you choose a member yourself. A url-test group picks a member based on the configured test URL and results. A fallback group usually selects the first available member in its list. Automatic strategies depend on the test target, interval, tolerance, and node availability; they do not guarantee faster performance for every service. Groups can also reference other proxy groups, so trace those references to identify the final outbound node. For logins or sessions that need a consistent exit IP, manual selection can help avoid changes caused by strategy updates. Save your configuration before changing group types or members, and check whether a subscription update will overwrite your edits.

A latency test usually measures the time for a single request to a specific address. Whether it includes connection setup and TLS negotiation depends on the implementation. It does not directly measure bandwidth, sustained throughput, or how quickly a target website responds. The route from a node to the test address may also differ from the route to the service you’re using. First confirm in the connection log that your browser is using the node, then compare multiple nodes against the same target, on the same network, around the same time. Slow downloads may also be caused by server-side limits, packet loss, congestion, or your local network. Don’t rule out a node based on one test or assume a timeout means it is permanently down; check the logs and repeat the test.

Rules are generally evaluated from top to bottom. Once a broad rule matches, a more specific rule later in the list won’t determine the connection’s route. Check the connection log for the domain, destination IP, matched rule, and final policy. Keep in mind that an app may connect directly to an IP or reuse an existing connection. The no-resolve option can be used with IP-based rules that support it—for example, GEOIP,CN,DIRECT,no-resolve—to avoid resolving a domain just to match that rule. It does not disable DNS as a whole. Put specific domain rules before broad rules, and keep MATCH as the final catch-all. Reconnect after making changes to see the results.

Some Windows apps running in an AppContainer are restricted from accessing loopback addresses by default, so they can’t connect to a proxy listening on 127.0.0.1. Not all Store apps have this limitation. First check whether the app follows the system proxy and whether its connections appear in the core log. If loopback restrictions are the cause, use the client’s loopback exemption feature to grant access only to the apps that need it, following any prompts to run as an administrator. Don’t remove the restriction for every app. If you switch to TUN, verify that the app’s traffic is actually being routed through it; a loopback exemption is not a universal fix for connection issues.

First make sure the core is running. Then check that the address and port in the system proxy match the client’s listener settings. Other proxy tools, browser extensions, or corporate network policies may override the system settings, and the browser may have its own proxy configuration. Open the affected page and check the client’s connection log. If there’s no entry, check the traffic entry point, proxy bypass list, and whether the port is in use. If an entry appears but uses DIRECT, check the outbound mode and matched rule rather than toggling the system proxy again. Restart the browser to clear existing connections, then disable conflicting settings one at a time. Don’t run multiple clients that manage the system proxy at the same time.

If all nodes time out, first confirm that the device can access the internet, the system clock is correct, and the subscription is authorized. Then check whether a firewall is blocking the client and whether the test target is reachable. If only one node fails, compare it with working nodes and check that node’s server status, address, port, and protocol support. For QUIC-based protocols, confirm that the current network allows the required UDP traffic. An unreachable test target can also cause multiple failures, so compare actual access with the connection stages shown in the logs. Don’t reinstall the client first. Identify whether the issue is DNS resolution, a refused connection, or a connection timeout to narrow it down.

Check the logs for DNS resolution failures, upstream DNS timeouts, or unexpected connection targets. Then confirm whether the request reached the core and whether DNS is handled by the OS or the client. If switching nodes fixes the issue, the route from the node to the target may be the cause. If resolution still fails with several nodes, check the upstream DNS address, network path, and configuration compatibility. With fake-ip, some local network services or apps may need filtering rules configured as documented. Avoid stacking multiple DNS hijacking setups, and don’t rely on direct IP access instead of domain testing; HTTPS certificates and virtual hosting can introduce other errors.

First check whether the OS is still pointing to the client’s local proxy port. If the app crashed, the listener may have stopped while the system proxy setting remained. Reopen the client, turn off the system proxy and TUN, then quit normally. You can also disable an obsolete manual proxy in the OS network settings. If the problem persists, check whether a background service, VPN connection, or DNS settings are still managed by another tool. If you use manual DNS, restore the settings you recorded earlier. Don’t delete unfamiliar virtual adapters or routes. Reconnect and test a regular website; only consider a network reset, following your OS documentation, if standard recovery steps fail.