Clash FAQ

Clash usually refers to the proxy-tool ecosystem, though it can also mean an earlier core project. mihomo, derived from Clash Meta, is the core that parses configuration, handles DNS, matches rules, and establishes outbound connections. The client provides the interface for managing subscriptions, selecting policies, and setting the system proxy. When troubleshooting, note the client name and core details separately; saying only that Clash is installed is not enough. The same interface does not necessarily mean the same core is in use. Check the documentation for the core actually running and its startup logs to confirm which configuration fields it supports.

The client manages connections and routes traffic, but installing it does not provide a working proxy by itself. You’ll usually need a valid subscription URL or the details for nodes you’re authorized to use. A subscription may include nodes, proxy groups, and rules, or just a node list, so check the provider’s format before importing it. Treat the access token in a subscription URL like a password, and redact the full URL from screenshots, shared logs, and online converters. This site offers client downloads and setup guides, but does not issue subscriptions or restore accounts disabled by a provider.

For everyday use, start with Rule mode: connections are checked against rules in order, and the first match determines the outbound policy. Global mode applies one global policy to connections that have entered the core, making it useful for brief comparison tests. Direct mode attempts to connect without a proxy. Global describes the outbound decision; it does not automatically route traffic from every app into the client. Whether an app is intercepted still depends on the system proxy, its own proxy settings, or TUN. After changing modes, test with a new connection—existing long-lived connections may keep using their original route.

For a new installation, consider Clash Plus and compare its platform support and workflow with clients such as Clash Verge Rev and FlClash. If you need a specific feature, check the current release notes instead of relying on names from old tutorials. Before migrating, back up your subscription URL, custom rules, and essential preferences, then import your configuration into the new client. Databases, service components, and interface settings from the old client may not transfer directly. During migration, let only one client manage the system proxy or TUN at a time. Remove the old service after confirming the new configuration works.

Check your OS version and processor architecture in system information, then review the download card’s compatibility notes. Don’t guess based on a device’s appearance: Windows x64 and ARM64, macOS Intel and Apple Silicon, and Android arm64 and arm are different targets. On Linux, also check the package format and runtime dependencies for your distribution. If the installer reports incompatibility, verify these details instead of renaming the file extension. Minimum requirements are listed in the client’s current release notes. Older systems may lack components needed for the system proxy or virtual network adapter, even if the app starts.

First, determine whether the download failed or the content could not be parsed. If the download failed, check whether the subscription expired, its token was reset, and whether updates use a direct or proxied connection. If the proxy is not working yet, try a direct update if the client allows it. If the download succeeds but no nodes appear, check whether you received a login page, an error message, or an unsupported format, and confirm whether the subscription provides a full configuration or a proxy-provider entry. Never paste a private subscription into a public converter. If the URL is correct but access is denied or the account is rejected, contact the subscription provider; reinstalling the client repeatedly is unlikely to help.

A remote subscription update may regenerate the entire configuration, overwriting edits made directly to the generated file. First confirm which file the client actually loads, then use its supported override, merge, or configuration extension features to preserve local changes. Rule lists may be replaced entirely or inserted at a specified position, depending on the client. Any new rule must also reference an existing proxy group. After editing, check the effective configuration and core logs—not just the source snippet in your editor. Back up the original, change one type of field at a time, then update the subscription to verify the changes persist.

TUN creates a virtual network interface and may modify routes, so it usually requires a client service component or system authorization. Follow the current client instructions to install and start the service, then confirm any system prompts for a network extension, VPN, or administrator access have been approved. On Linux, check permissions for the TUN device and the process. Don’t leave the firewall disabled or broadly loosen file permissions just to clear a warning. If it still fails after authorization, check the first relevant error in the logs and rule out another VPN controlling routes. TUN only determines how traffic enters the core; you still need working nodes and valid rules.

A proxy group selection affects only connections that ultimately route to that group; it does not override every rule. Check the connections panel to confirm the target connection entered the core, then inspect the matched rule and final outbound. If the rule points to DIRECT, changing a different proxy group won’t affect the result. Rules are usually matched from top to bottom, so a broad rule near the top can prevent a more specific one from matching. Also check whether nested groups point to another group and whether the app bypasses the system proxy. Close the existing connection and retry after a change; this makes it easier to identify the setting that caused the result than switching between several nodes.

Add custom rules through the client’s persistent override feature, usually before broad rules that might match first. DOMAIN matches a specific domain; DOMAIN-SUFFIX matches a domain suffix. For both, enter a domain—not a full URL with a scheme, path, or query string. The policy at the end of each rule must match an existing node, proxy group, or built-in policy. MATCH is a catch-all rule with no other conditions and usually belongs at the end of the rule list. If placed too early, it prevents later rules from matching. After saving, check the match record for a new connection to confirm the rule loaded and took effect.

In Fake-IP mode, the app receives a mapped address from a reserved range. The core stores the mapping to the domain and uses it to handle the actual connection; this does not change the website’s authoritative DNS records. Some LAN discovery, device-control, or other apps that rely on real DNS results may need entries in fake-ip-filter. Filtering affects DNS resolution; it does not change the domain’s routing policy to Direct. If you hit a compatibility issue, narrow it down to the specific domain, add only the necessary filter entries, then clear the relevant DNS cache and reconnect. Avoid filtering every domain, which can hide the real cause.

Some Windows apps isolated by AppContainer cannot access the local loopback address directly, where local proxies commonly listen. As a result, those apps may fail to connect even when a browser works. First confirm that the app is affected by this restriction, then use the client’s UWP loopback tool or the Windows CheckNetIsolation tool to grant loopback access only to the apps that need it. Administrator access may be required; restart the affected app afterward. Not every Store app is a UWP app, and loopback restrictions are not the cause of every connection failure. If the logs already show the app’s connections, keep checking rules and nodes instead of repeatedly adding exemptions.

First confirm that your local network can access the internet. Then check the logs to see whether the failure involves resolving the node server, connecting to it, or reaching the speed-test target. A timeout only means the test request did not finish in time; it does not prove the node is permanently down. Compare against a known-working outbound using the same target, and check the device clock, subscription status, server port, and protocol settings. If all nodes fail, start with local network and shared configuration settings. If only some fail, ask the provider to check their status. Change DNS only when the logs show a clear resolution error.

Record the failed domain, error time, and resolver first. Determine whether the problem is resolving the node server’s domain or the destination website’s domain. Check that the configured DNS upstream is reachable and that encrypted DNS upstreams have a working bootstrap resolution path for their own hostnames. With TUN enabled, confirm system DNS requests enter the core as expected and aren’t being intercepted by another DNS tool. Change only one upstream or routing setting at a time, clear the cache, retry, and keep logs for comparison. Avoid enabling multiple DNS interception features at once; even if that temporarily restores service, it will be hard to tell which setting fixed the issue.

The system proxy is a setting apps can choose to use; it does not force every program to use it. Some command-line tools, games, and apps with their own network stack ignore it. First confirm that the system proxy address and port match the client’s listening settings, then check whether the target app’s requests appear in the connections panel. If there’s no record, check the app’s own proxy settings, proxy environment variables, and bypass list. If needed, use TUN after confirming you have the required permissions. If requests do appear, troubleshoot the rules and outbound route. Disable other proxy clients during testing so they don’t overwrite system settings, and remember that TUN and Global mode are separate settings.

A port-in-use error means another process is using the address the client needs to listen on. Check whether the client was launched twice or an old background core or service is still running. Identify the process before stopping it normally; don’t terminate an unfamiliar system process. You can also change the local listening port, but update the system proxy and any apps with a manually configured port to match. If the network acts up after quitting, check whether the system proxy still points to the stopped client, then check other VPNs, routes, and DNS settings. First use the client to disable traffic interception and exit normally. Consider a system network reset only if standard recovery steps fail, and record your original network settings beforehand.