Clash FAQ
and Help Center

A client provides the interface for importing configurations, choosing proxy groups, and toggling the system proxy. The core handles connections, resolves domain names, and applies rules. mihomo is an actively developed core in the Clash ecosystem and was previously known as Clash Meta. A subscription is usually a configuration link provided by a service provider to retrieve nodes or a complete configuration. Installing a client does not provide working nodes; you also need a compatible configuration and an active service. When troubleshooting, note the client name, core name, and subscription type separately so you can distinguish interface features from core capabilities.

Rule mode routes connections according to the order of rules in the configuration, making it a good choice for everyday traffic routing. Global mode usually sends connections handled by the core to the GLOBAL policy, where you still need to choose an available node. Direct mode connects traffic handled by the core straight to its destination. These modes only control how the core handles connections it receives; they do not route every app through the core automatically. Start with Rule mode, and switch briefly to Global mode if you need a comparison. Restore the original mode afterward and check which rule matched so temporary settings aren’t left in place.

The system proxy is mainly used by apps that read the operating system’s proxy settings. Browsers usually do, but some games, command-line tools, and apps with their own network stack may ignore them. An app may also have its own proxy or bypass list, so a working browser doesn’t mean other apps are using the proxy. Check the client’s connection list to see whether requests from the app appear. If they don’t, start by checking how its traffic enters the core. You can configure a local proxy in the app itself, or enable TUN mode after understanding the routing and permission requirements.

Start by choosing your operating system, then check your processor architecture, OS version, and required features. Where supported, our download center lists Clash Plus first and also offers options such as Clash Verge Rev and FlClash. Interfaces, configuration overrides, service installation, and TUN controls vary between clients, so don’t assume menus work the same way. If you already have a stable configuration, keep a copy before migrating and check which core the new client uses. Choosing a maintained release that supports your system matters more than comparing appearances.

A latency test usually checks a single request from a node to a specific test address. It doesn’t prove that every site, protocol, or app is reachable. A website may fail because a rule selects the wrong proxy group, the site blocks access, DNS resolution fails, or the app isn’t using the proxy. First confirm that the website request appears in the connection list, then check the matched rule and selected node. Test another site and another node in the same group to narrow down the issue. Don’t keep changing DNS based only on latency, or treat one successful test as proof that the entire connection path works.

Get a configuration link for Clash or mihomo from your service provider. In the client’s configuration or subscription section, choose the option to import from a link, paste the full URL, and save it. The link may contain personal access credentials, so don’t post it publicly or include it in screenshots. After importing, enable the configuration, check that proxy groups appear, select a node, and turn on the appropriate traffic entry point. If the import includes nodes but no rules, add a configuration using a method supported by your client. Menu names vary, so you can follow our guide to verify a complete connection.

mixed-port is a local listening port that accepts both HTTP and SOCKS proxy connections. With mixed-port: 7890 in your configuration, apps on the same device typically use host 127.0.0.1 and port 7890, selecting the proxy protocol they require. Use the value shown in your client if it differs. If the startup log says the address is already in use, close other proxy software or switch to an available port and update the app settings too. Don’t use the external controller port as a proxy port. If the proxy is for local use only, keep LAN access disabled to avoid exposing the listener.

Check the logs first to distinguish insufficient permissions, a missing service, and a driver loading failure. Windows clients often require their service component to be installed or running; some can also be run as administrator, but follow the client’s documentation. macOS may require approval for a helper service, while Linux needs the appropriate network permissions. After installing the service, restart the client and check whether the virtual adapter and routes were created. If it still fails, temporarily quit other VPN or TUN software for comparison. Avoid repeatedly creating virtual adapters or leaving system protections disabled as a permanent workaround.

TUN captures network traffic, while DNS settings handle name resolution and domain mapping, so check both. Fake-IP returns mapped addresses for some domains, which the core translates back to their destinations for later connections; it is not a public DNS server address. Start with the TUN and DNS defaults provided by your client, then check dns.enable, dns.enhanced-mode, and the TUN DNS interception settings in your configuration. Don’t copy just one enhanced-mode field. If a LAN device or specific app is incompatible, add Fake-IP exclusions based on the symptoms, then restart affected apps to clear old connections.

Starting the client at boot, starting the core service, and restoring the proxy setting are separate options; enabling one may not do all three. On desktop, check the startup setting, active configuration, and whether the system proxy or TUN state is restored. Test the connection after a restart. On Android, check background activity, battery optimization, and VPN permissions. On iOS, verify the VPN status in system settings. Mobile operating systems usually allow only one active VPN, so another VPN or filtering app may replace the connection. Check the system status before troubleshooting nodes to avoid mistaking background restrictions for a subscription problem.

Use your client’s rule override, configuration merge, or extension feature to keep local changes separate from the remote subscription. Rules are matched from top to bottom, so specific domain rules generally belong before broad rules and MATCH. For example, DOMAIN-SUFFIX,example.com,DIRECT sends example.com and its subdomains direct. The policy must exist, and its name and capitalization must match the configuration. Reload after editing and confirm the matched rule in the connection list. Direct edits to downloaded subscription files may be overwritten during updates, so keep a copy and check the client’s merge order.

select lets you manually choose a node or nested proxy group, which is useful when you want a specific, fixed exit. url-test automatically selects based on results from a specified test URL. Its interval, tolerance, and other settings affect switching, but it doesn’t rank nodes by download speed. fallback usually picks an available option in list order, making it useful for keeping a preferred route and switching when it fails. Group members, test URLs, and the sites you visit all affect the result. If a site behaves unexpectedly, pin a node with select for comparison before changing automatic policies; avoid changing multiple groups at once.

Open the client’s connections page and trigger a new request in the app. Find the connection by process, domain, or destination address, then check the rule type, policy chain, and final outbound. Existing long-lived connections may keep using the old policy, so close them or restart the app after changing configurations. If no connection appears, first check whether the app is using the proxy instead of changing rules. If the logs are too sparse, briefly increase the log level and restore it afterward. Before sharing logs, remove subscription URLs, credentials, and personal browsing data; include only the error details needed to diagnose the issue.

Enable allow-lan only if you specifically want other devices to use the proxy on this computer. Check bind-address, the proxy port, and inbound firewall rules. On other devices, enter this computer’s LAN address—not 127.0.0.1—and update it if the address changes. Limit access where possible and enable authentication if the client supports it. Don’t forward the proxy port to the public internet from your router. The external controller and proxy listener are separate services and should be managed separately. Turn off sharing when you no longer need it to prevent unknown devices from using your network connection.

The proxy toggle alone can’t tell you where DNS requests go. Apps may use the system resolver, built-in encrypted DNS, or their own network settings; whether TUN and DNS interception work also depends on your configuration. First confirm that the app’s requests enter the core, then check the core’s DNS logs, upstream resolver, and routing policy. If your browser uses secure DNS, include that setting in your checks. A DNS leak test site can offer clues, but it can’t prove the traffic path for your whole device. Consider the connection logs and actual network configuration together.

First find out whether the failure occurred during download or parsing. HTTP 401 or 403 may indicate an authorization or access restriction; 404 may mean the endpoint is no longer valid. Check with your service provider for the exact meaning. For a timeout, check whether your current network can reach the subscription URL. If the download succeeds but parsing fails, check whether the response is a login page, whether its format supports your core, and whether the YAML indentation is valid. Change the User-Agent only if your provider explicitly requires it. Keep your last working configuration and get a fresh link before updating. Don’t submit credential-bearing URLs to untrusted conversion sites.

Turn off the proxy first and check whether your regular internet connection works. Then confirm the configuration is enabled, your service account is active, and node details are present. Test one node and inspect the connection error to distinguish DNS failures, connection timeouts, authentication errors, and unsupported protocols. All nodes timing out could also mean the test address is unreachable, so verify with an actual website request. Quit other proxies or VPNs and try a different network. If the same configuration works on another device, check local ports, firewall rules, and how traffic enters the core. Don’t reset the configuration, DNS, and network settings all at once, or you won’t know what fixed the issue.

Check that the operating system’s proxy settings point to the local address and port the client is actually listening on, and confirm the core is still running. Browser extensions, separate proxy settings, or other network tools may override the system settings; temporarily disable them and restart the browser to compare. If you can’t get online after quitting the client, the system may still be pointing to a proxy port that is no longer open. Turn off the system proxy or restore its previous settings, then test a direct connection. To enable it again, start the core before turning on the proxy. On managed devices, follow your organization’s policies rather than overriding them.

Some Windows apps that use AppContainer are subject to local loopback restrictions and may not be able to connect to a proxy at 127.0.0.1. First confirm that a regular browser works and that the app uses the system proxy. Then use your client’s UWP loopback tool to grant access only to the apps that need it. Windows also includes CheckNetIsolation, but verify the app’s package identity and your permissions before using it. Don’t enable loopback for every app. Restart the app after granting access. Not every Store app has this restriction, and loopback access won’t fix node, DNS, or server issues; check the connection list to diagnose those.

For slow speeds, compare direct access with proxy access, then test the same destination with a fixed node to distinguish node load, route fluctuations, and local settings. Low latency doesn’t guarantee high throughput. If only one app is slow, check its rule and traffic entry point. If the client crashes, keep your configuration and logs, revert to the last working configuration, and check recently added rules, providers, and core compatibility. If it exits on startup, follow the client’s documentation to temporarily move the configuration directory and test again; update to a client version that supports your system. Don’t delete all your data or keep reinstalling instead of finding the cause.