Clash FAQs

Clash is a familiar name in the proxy ecosystem. mihomo is an actively developed proxy core that supports the Clash configuration format and handles connections, DNS, and rule matching. GUI clients provide subscription management, proxy selection, logs, and access to system proxy settings. Similar interfaces do not guarantee the same core version or features. When troubleshooting, note the client name and version, as well as the core version. Whether a protocol or configuration field works depends on support in the core actually running—not just the client’s name.

A client runs a configuration; it does not provide a working proxy service by itself. A subscription usually includes proxy nodes, proxy groups, and rules, though some subscriptions provide only nodes that need to be combined with a client configuration template. Before importing one, make sure the source is trustworthy, the service is still active, and the format is supported by your core. After importing, enable the configuration and select a proxy group and mode. Simply saving the subscription URL will not change how your traffic is routed. Never share a full subscription URL in screenshots, public support tickets, or chat logs: it may contain credentials that others could use.

Rule mode checks rules in order and routes each connection according to the first matching policy. It’s suited to everyday routing by domain or network range. Global mode sends connections that reach the core through the selected global policy, making it useful for checking whether rules are causing an issue. Direct mode connects those incoming connections straight to their destinations. Global mode does not send every app through the client: traffic that does not use the system proxy or TUN may never reach the core. After switching modes, test with a new connection; existing long-lived connections may keep using their previous route.

The system proxy registers a proxy address with the operating system and mainly affects apps that read that setting. TUN routes traffic through a virtual network interface, which is often useful for apps that ignore the system proxy. You don’t need to enable both. Start by testing the system proxy, then enable TUN if your apps require it. TUN can also involve permissions, routing, DNS, and compatibility with other networking software. If your connection drops after enabling it, disable TUN and compare before trying a different subscription. Check your client’s documentation for supported combinations.

Check the update error on the configuration page first, then determine whether the URL could not be reached or its contents could not be parsed. For a 401 or 403, check whether the subscription expired, its credentials changed, or the server restricts access. For a 404, ask the provider whether the URL has changed. A login page, web verification page, or format error may mean the response isn’t a configuration file. For timeouts, check your local connection and whether the client fetches subscriptions directly or through a proxy. Keep your last working configuration until an update succeeds; reinstalling the client should not be your first response to a subscription issue.

Make a copy of the original file, then check the lines around the one mentioned in the log. YAML uses spaces for indentation; avoid tabs. Check list-item hyphens, spaces after colons, and strings containing special characters. Once the syntax is valid, make sure rule targets exist, node names referenced by proxy groups match exactly, and the running core supports the fields you use. The reported line may mark where parsing stopped, while the actual error is on the line above. Change a small section at a time and validate again. Enable the configuration only after it loads successfully, so it’s easy to roll back if needed.

First make sure the core starts normally. Then check whether the client’s required service mode, helper program, or administrator approval is in place. Windows clients may need a service installed and running; macOS may require permission for a helper; Linux may require access to virtual interfaces and network management capabilities. Don’t grant elevated permissions to software from an unknown source—verify where it came from and read the client’s documentation first. After granting permission, restart the client and check the logs to confirm that the interface and routes were created successfully. If the device is managed by an organization, ask an administrator about the permitted access rather than bypassing its restrictions.

Some packaged Windows apps are affected by AppContainer network isolation and may need a loopback exemption to reach a local proxy. However, this isn’t the cause of every Microsoft Store app connection issue. First confirm that the browser works through the same system proxy, then check whether the affected app appears in the client’s connection logs. If the client provides a loopback exemption tool, use it only for trusted apps that need it. An administrator can also use system tools to check an app package’s exemption status. Fully exit and reopen the app after making changes. A loopback exemption only addresses local access restrictions; it won’t fix subscription, DNS, or remote connection problems.

Compare the system proxy address and port with the values the client is actually listening on, and make sure the core is running. The default example port 7890 may not be the port in your current configuration. Then check whether the app has its own proxy settings, ignores the system proxy, or has a destination on the system bypass list. Send a new request from the app while watching the client’s connections page or logs. If nothing appears, investigate how traffic reaches the client before changing routing rules. Also check whether another proxy app or network tool is overriding the system settings; if needed, test with just one tool enabled.

Many command-line tools don’t automatically use the desktop system proxy. Configure an HTTP, HTTPS, or SOCKS proxy according to the tool’s documentation. With mixed-port, enter the local address and port for tools that support HTTP proxies. Don’t enter external-controller: it’s a control interface, not a traffic proxy. Terminal environment variables affect only programs that read them, and their names and behavior vary by tool. After changing them, test by starting a new process in the same terminal. Start with a temporary setting for the current session; make it persistent only after it works. Remove it when you close the client to avoid stale proxy settings breaking connections.

A client speed test usually probes a specific address. Its result reflects that connection at that moment; it doesn’t prove every site is reachable or indicate your download speed. Check that the selected node in the active proxy group matches the one being tested, then see which policy handles the website connection. If only certain sites fail, check DNS resolution, rule matching, and access restrictions on the destination service. If all targets fail, check the node and your local network. An unreachable test address can also skew the result, so compare logs with actual browsing rather than switching nodes repeatedly based only on latency.

Subscription files are usually downloaded again during updates, so edits made directly to them may be overwritten. To keep settings, use the client’s supported override, merge, or scripting mechanism. First check whether it prepends, appends, or replaces list entries. Custom rule order matters: put specific rules before broader rules that might match first, and usually put MATCH as the fallback at the end. Check the final effective configuration and confirm that policy references still exist. Override formats aren’t necessarily compatible between clients, so review them when switching instead of copying another client’s override file as-is.

Turn off the client proxy and confirm that your local network can reach a known direct-connection target. Then check the subscription’s validity, whether nodes loaded correctly, and whether the device clock is accurate. Try accessing a destination through one node and use the logs to distinguish DNS failures, connection timeouts, authentication errors, and certificate errors. If every node fails, the cause may be a shared network path or subscription issue; don’t assume that every node is individually invalid. If possible, compare using another trusted network. If only the speed test fails, check its probe address. When reporting the issue, share redacted errors and steps to reproduce—never expose node passwords or subscription credentials.

Check the logs to see whether the affected domain resolved successfully, and confirm that the connection matched the expected policy. Fake-IP uses mapped addresses to help route traffic, and some apps or network environments may not support it. But a page failing to load alone doesn’t prove Fake-IP is the cause. Keep a copy of the original configuration and temporarily switch the DNS mode using a method supported by your client. If only a few domains are incompatible, check the core documentation before considering fake-ip-filter rather than excluding every domain. Reconnect after making changes, clear the system or app DNS cache if needed, and check whether the browser’s secure DNS is bypassing the expected resolution path.

Check whether the client was started twice or another proxy app is running. On Windows, use netstat to find the listening port and associated process. On macOS and Linux, use lsof or ss. Identify the process before deciding what to close; don’t terminate an unfamiliar system process. If you need to keep the existing process, change mixed-port to an unused port and update the system proxy, browser-specific proxy, and terminal settings accordingly. Also confirm whether the error refers to a proxy port or a controller port; they aren’t interchangeable. After changing the setting, make sure the core is listening successfully and test a new connection.

Check whether the system proxy still points to a local port that is no longer listening, and remove any proxy settings configured separately in your browser or terminal. If you enabled TUN, reopen the client and use its normal shutdown process to disable TUN and turn off the system proxy before exiting. Then check whether the virtual interface and routes have been restored. If the problem persists, check whether system DNS was manually set to an address that is now unreachable, and reconnect to the network. Record your original network settings first, especially on a work network or one with a static address. Don’t reset all network settings as a first step; you could lose settings you still need.