Clash FAQ

The client imports configurations, switches policies, and configures the system proxy. The core parses configurations, establishes connections, and routes traffic. A subscription is how a service provider delivers nodes or configurations. Installing a client does not give you access to working servers; you still need to import a configuration you are authorized to use. Different clients in the Clash ecosystem may use different cores, and mihomo is one actively developed option. When a feature is unsupported, note both the client name and the actual core version rather than relying on the app name alone. This site provides downloads and configuration guides; it does not issue subscriptions or restore service-provider accounts.

For everyday use, start with Rule: connections captured by the client are routed according to the rules in your configuration. Global sends captured connections through the global policy, but you still need to select a working node in that policy. Direct sends captured connections straight to their destinations. Switching modes does not expand which traffic is captured, nor does it make an app that ignores the system proxy start using one. To troubleshoot, briefly test the same URL in Global mode. If Global works but Rule does not, check rule matching and policy selection first. If both fail, check the node, DNS resolution, and traffic-capture path, then switch back to your original mode.

A successful latency test only means the node completed the probe request configured in the client at that moment. It does not guarantee that every site, protocol, or exit works. Check the URL used for the test, then confirm which policy group the connection to your target site actually matched. Don’t mistake a test result from another node for the result of your current connection. Compare an ordinary site with the one that fails, and check the logs for DNS, handshake, or remote-server errors. The target site may restrict the exit IP, and some apps also rely on UDP. Don’t keep changing configurations based on a single latency number; first determine whether traffic capture failed, the node is unavailable, or the site itself is restricting access.

A YAML file extension alone does not guarantee compatibility. Clients may differ in their cores, supported protocols, rule types, and override mechanisms; older cores in particular may not recognize newer fields. Before migrating, keep a copy of the original configuration and check the target client’s core documentation. After importing, validate the configuration and read the first specific parsing error—don’t delete multiple sections at once. Mobile clients may capture traffic through the system VPN interface, so their settings differ from desktop clients. If your subscription provider offers multiple formats, choose one that matches the target core. Remember that subscription URLs contain access credentials; don’t submit them to unfamiliar conversion services.

First determine whether the download failed or the configuration could not be parsed. Connection timeouts, certificate errors, and unusual HTTP status codes point to a download problem. If the content downloads but the client reports invalid fields, indentation, or proxy types, the issue is with parsing. Check that the copied URL is complete and contains no extra spaces or line breaks, and make sure you didn’t use an account webpage URL instead of a subscription URL. If your current network can’t reach the subscription domain, try updating over an already working connection, but don’t keep changing multiple network settings. If the response is a login page or an error message, check the link status in your provider account. Before sharing a screenshot, hide the full subscription URL, account details, and node credentials.

Keep your current configuration and the update error, then check your provider account for the subscription’s expiration date, traffic allowance, whether the URL was reset, and any service announcements. HTTP 401 or 403 errors often indicate authentication or access restrictions, but the provider’s response is the best guide to the cause. Don’t assume every failed update means the account has expired. If the new configuration is empty or node names have changed, a policy group may still reference an old name; check the available options. Restoring an old configuration can recover local settings, but it can’t extend a subscription. Replace the URL only if your provider tells you to, and remove the obsolete entry to prevent scheduled updates from overwriting a working configuration.

Check your operating system version and processor architecture in system information, then choose the matching installer on the download page. x64 and ARM64 are different architectures; on macOS, check whether your Mac has Apple silicon or an Intel processor. Linux users should also choose the right package format for their distribution, such as deb or rpm. If the installer says your OS version is unsupported, check the client’s minimum requirements. Don’t force installation by renaming files or disabling system protections. If the app won’t start after installation, record the full error and check for a lingering process, missing runtime dependencies, or security software interference. Back up your configuration and local overrides before updating so uninstalling doesn’t erase information needed for troubleshooting.

Turn off TUN first and confirm that a regular system-proxy connection works. Then troubleshoot the virtual network adapter separately. Desktop clients may need to install or start a service and run with administrator privileges. macOS may also require you to approve system permissions; follow the client’s prompts. Check the logs for a stopped service, adapter creation failure, or route conflict instead of repeatedly toggling the setting. Temporarily quit other VPNs, accelerators, and TUN tools before retrying to avoid competing route changes. If turning TUN on cuts off all network access, turn it off to restore connectivity and save the error details. Then check the adapter, default route, and DNS. Don’t remove unfamiliar system adapters in bulk.

Check that the client core is running, then confirm the system proxy points to the local address and port the client is currently listening on. Browser extensions, custom proxy settings, or separate network settings may override the system proxy. Pause relevant extensions and compare with a browser window that follows system proxy settings. While visiting the target URL, check the connection list: if there’s no new entry, check how traffic is being captured; if there is an entry marked DIRECT, check the rules and mode; if the connection uses a node but still fails, check the node and target site. Changing the system proxy is not the same as enabling TUN, and a website’s language does not tell you whether traffic went through a proxy.

Many command-line tools don’t automatically use the desktop system proxy, so you may need to set proxy options or environment variables separately. Start with an explicit test: curl --proxy http://127.0.0.1:7890 https://example.com. Here, 7890 is just an example; replace it with the port your client uses for its HTTP or mixed proxy. If the test works, set http_proxy and https_proxy for your terminal and check whether no_proxy excludes the target. Git, package managers, and containers may have their own proxy settings. In WSL or a container, 127.0.0.1 may not refer to the host machine. Check the network boundary between environments rather than assuming the host’s loopback address will work.

Check the configuration actually loaded by the core, not just the file saved in the editor. Rules are generally evaluated in order: a broad rule or MATCH placed too early can prevent later rules from matching. The target policy group must also exist, and its name must match exactly. Use DOMAIN to match a full domain and DOMAIN-SUFFIX to match a domain suffix; don’t include the URL scheme or path. After saving, reload the configuration as required by your client and create a new connection to check the logs—existing connections may continue using their original route. If subscription updates overwrite remote content, use the client’s local override or merge mechanism.

Some apps isolated with AppContainer can’t access a local loopback proxy directly. If your browser works but certain Store apps don’t, check for loopback restrictions—but not every Store app is a UWP app. First confirm whether the app uses the system proxy and whether your client provides a loopback exemption tool. If access must be granted, enable it only for the affected app. To check the existing list manually, run CheckNetIsolation LoopbackExempt -s as an administrator, then make changes based on the app’s actual package identifier—not its display name. On a managed work device, consult your administrator first. If the connection appears in the logs, also check the rules and node rather than blaming loopback alone.

Turn off the proxy first and confirm that your basic internet connection works. Then check that your subscription account and configuration are still valid. Send a real request through one node and check the logs at the same time to distinguish DNS resolution failures, TCP timeouts, authentication errors, and TLS handshake failures; each points to a different fix. Next, change just one variable—for example, try a different network or a known-working node—and compare the results. If only latency probes fail while real traffic works, check whether the probe URL is reachable. If multiple nodes share an entry domain or provider, simultaneous failures don’t necessarily mean your device is at fault. Note when the problem occurred and the error type before reporting it to the provider.

First identify which DNS resolver is in use: the system, the core, or the browser’s encrypted DNS. Avoid changing all three at once, or you won’t be able to compare results. Check whether the upstream resolver is reachable over your current network. If the node server itself uses a domain name, confirm that it can be resolved before the proxy connection is established. Fake-IP returning a virtual address is normal; seeing a virtual IP range does not mean DNS is broken. If only a few domains are affected, check the logs and compatibility first, then make the smallest change supported by your core’s filtering options. Clear the relevant cache and reconnect after making changes. For local device names, keep a resolution path that works on your LAN.

First check whether the system proxy still points to a local port that is no longer listening. Turn off the manual proxy in your system network settings. If you used an automatic proxy script, check that setting too. Then confirm TUN is off, related services and virtual adapters are in a healthy state, and no manually configured DNS settings were left behind. Terminal apps may also need the proxy environment variables you set for this session cleared; alternatively, open a new terminal and test again. Restore settings in order, then decide whether to restart the network connection. Don’t reset all network settings right away. Work devices may rely on an organization’s proxy, so note the original values before changing anything to avoid removing required network settings.

Use the same browser and IP-checking page to compare results before and after enabling the proxy, and check the matching connection entry in the client. Your exit IP is only one clue: rules may send the test site DIRECT, and a cached page can also give a misleading result. If the browser has a connection entry but the target app doesn’t, check whether the app supports the system proxy, uses UDP, or has its own network settings. Then consider whether TUN is needed. IPv4 and IPv6 may take different routes, so check each actual connection instead of changing global settings as soon as you see a different address. TUN can capture more traffic, but routes and rules still apply; it doesn’t guarantee every connection will use the same exit.