Clash FAQs

The client handles interface tasks such as importing configurations, toggling the system proxy, and viewing connection logs. The mihomo core handles protocol connections, DNS resolution, and rule processing. A subscription provides configuration or proxy data from a service provider. Installing a client does not provide working proxies or create a service account. When troubleshooting, first identify whether the issue is with the interface, the core, or the service: check the logs if the core will not start, check the format if a configuration will not import, and contact the subscription provider about expired accounts or disabled proxies.

Clash for Windows is no longer maintained. Choose a client that is actively maintained and compatible with your operating system. First note your subscription URL, ports, rule mode, and local overrides. Turn off the system proxy in the old client and quit it, then launch the new client and import your subscription. Don’t run two clients that both take over network traffic, and don’t copy the old application folder over the new one. After migrating, test one proxy and your most-used apps, then restore custom rules one at a time. Check experimental options from the old configuration against the new core’s documentation.

Rule mode is usually best for everyday use: connections that reach the core are handled by the matching policy, in rule order. Global mode sends those connections through the global policy and is useful for short troubleshooting tests. Direct mode connects them straight to their destinations. A mode is not the same as a traffic-capture method; switching to Global does not automatically capture traffic from every app. First make sure the system proxy or TUN covers the app you’re testing, then compare modes. If Global works but Rule mode doesn’t, check the matched rule and policy group instead of reinstalling the client.

The system proxy only affects apps that follow the system proxy settings. It may not cover games, some command-line tools, or software that opens its own connections. Browser extensions can also override the system proxy. Look for a new request from the app in the client’s connection log. If none appears, check the app’s own proxy settings, extensions, and traffic-capture method before switching proxies. TUN may capture more traffic, but you’ll still need to check routes, exclusions, and platform limitations. Even when a connection reaches the core, a rule may send it directly to its destination.

On the client’s configuration or subscription page, choose the URL import option and paste the full address from your service provider. Save it and wait for the download and parsing to finish. A successful import doesn’t necessarily mean the configuration is in use: set it as the active configuration, make sure its policy groups appear, and select an available policy. Then enable a traffic-capture method, visit the site you want to test, and check the connection log. Subscription URLs may contain account credentials, so don’t share them in screenshots, public logs, or group chats. If a URL is exposed, reset it in your provider’s dashboard and import the new one.

A full Clash YAML configuration, a proxy collection, and a Base64-encoded list of share links are different formats. A full configuration usually includes proxies, policy groups, and rules. A standalone proxy list may need to be referenced as a proxy collection; it can’t necessarily be loaded as the main configuration. Base64 is just an encoding format and doesn’t guarantee compatibility with your client. Ask your subscription provider for a configuration URL compatible with Clash or mihomo, and confirm which protocols are supported. Don’t give subscriptions with account details to untrusted converter sites, and don’t try to fix a format error by repeatedly changing ports.

First make sure the core is running, then follow the client’s instructions to install or start its service mode and grant the required system permissions. Windows usually requires administrator privileges or a correctly installed background service. On macOS, authorize the network components when prompted. On Linux, you typically need access to the TUN device and network administration privileges. Check whether security software is blocking the client and whether another VPN is controlling routes. Don’t elevate an app from an untrusted source or leave system protection disabled. Restart the relevant service after granting permission. If the issue persists, check the logs from the virtual adapter creation stage.

Some apps in the AppContainer sandbox are subject to loopback restrictions and can’t directly access the local proxy port that the client is listening on. First confirm that a browser can use the same proxy, then check whether the problem affects only a specific app. If the client provides a loopback exemption tool, learn what it does, enable the exemption only for the target app, and grant administrator permission as prompted. If no such tool is available, see how to use Windows CheckNetIsolation. Not all Store apps have the same restrictions. If TUN is enabled, check the connection log and routes first rather than adding unrelated exemptions.

First confirm that the active configuration loaded successfully and the core is running. Then check that the system proxy points to the correct local address and listening port. The port should match the active mixed-port or HTTP port; don’t use a SOCKS-only port for an HTTP proxy. Check browser extensions, app-specific proxy settings, and the system bypass list, then make another request and inspect the connection log. If the log shows DIRECT, the request may have reached the core but been routed directly by a rule; check which rule matched. If there’s no log entry, check the traffic-capture settings.

Rules are matched from top to bottom. Put specific rules before the fallback MATCH rule, and make sure they point to a policy group or built-in policy that exists in the active configuration. Prefer the client’s override, merge, or persistent-rule options; direct edits to subscription-generated files may be lost on update. Save and reload the configuration, then use the connection log to check which rule actually matched. Existing connections may continue using the old policy, so close only the affected connection and try again if needed. For domain rules, also check that the core can identify the connection’s destination domain.

A client’s latency test usually measures whether it can reach a specific test address; it doesn’t measure download speed or guarantee access to every site. First confirm that the test address is reachable, then test the same proxies under the same conditions. Avoid running many tests at once, as this can skew results. Choose a proxy based on access to your target sites, connection stability, and your provider’s traffic limits. If latency is low but a site still fails, check site restrictions and protocol compatibility. If a test times out but browsing works, check the test address and timeout settings first.

After changing DNS fields, reload the configuration and make sure the client’s interface settings or overrides aren’t replacing them. Check the logs for upstream resolution failures, then clear the DNS cache using a method supported by your client and reconnect to the destination. When updating GeoIP or other location data, use a format and configuration path supported by your current core, then confirm that the data loaded successfully. GeoIP affects relevant IP rules; it won’t fix domain name resolution. If the issue affects only certain domains, check the DNS results, matched rules, and selected policies.

Keep your current working configuration so you don’t lose useful troubleshooting evidence by deleting it repeatedly. A 401 or 403 usually points to an authorization issue, incorrect credentials in the URL, or an access restriction. A 404 may mean the URL has changed, but check your provider’s guidance. An HTML response often means you copied a login page URL or the request was stopped by a web verification page. Copy the dedicated subscription URL from your provider’s dashboard, check your account status and traffic allowance, then try a manual update. Don’t share the full response or subscription URL. If the issue is only a network timeout, check the network path used for the update request first.

First check that your regular internet connection works with traffic capture turned off. Then check your device’s time, account status, and subscription update results. Select a single proxy, make one request to your target, and check the logs for that time: distinguish DNS resolution failures, connection refusals, handshake failures, and timeouts to the test address. If all proxies come from one service, ask the provider to check its status. If only one protocol fails, confirm that the core supports it and that all required parameters are present. Don’t change DNS, ports, and rules all at once, or it will be hard to find the cause. Remove subscription credentials, proxy passwords, and other account details before sharing logs.

First confirm in the logs that the failure is caused by a listening port conflict. Use Windows netstat or lsof on macOS or Linux to identify the process using port 7890; don’t terminate an unknown system process. If an old client is still running, quit it normally. If you need to keep the port, change mixed-port in the current client’s port settings or active configuration, choose an unused port, and reload. Subscription files may be controlled by overrides, so check the value the client is actually using. Update the port in your system proxy, browser, and command-line tools as well, then confirm the listening error is gone from the logs.

A common cause is that your system is still pointing to a local proxy that is no longer listening. Reopen the client, turn off the system proxy and TUN, and quit normally. Then check your system network settings for a leftover manual proxy. Restore any separate proxy settings in individual apps and remove proxy environment variables from command-line configurations if needed. If you used TUN, manual DNS, or another VPN, check that routes and DNS have been restored, and reconnect to the network if necessary. Don’t start by resetting the network or deleting all network adapters. Note your current settings and check the proxy, DNS, and routes one at a time.