Clash FAQ and Troubleshooting

Clash refers to a proxy core and configuration ecosystem; the original project is no longer maintained. mihomo is a compatible core that continues to develop, with expanded protocol, rule, and networking capabilities. Graphical clients manage subscriptions, proxy groups, system proxy settings, and service installation, while the core handles traffic forwarding. When troubleshooting, note both the client name and core details—not just “the latest version of Clash.” A toggle in the interface does not guarantee that the active core supports the corresponding field. If a configuration fails, check the core documentation first, then confirm whether the client overrides the original configuration.

A client provides local listeners, rule matching, and traffic forwarding; installing it does not create a working remote proxy. A subscription usually includes nodes, proxy groups, and rules, but some subscriptions provide only a node list that must be used with a local template. Check the import result on the configuration page, then confirm that the proxy groups contain selectable options. Never post a subscription URL in a public forum: it may contain account credentials. If it is exposed, reset the link through your provider. This site provides client information and configuration guides; it does not issue subscriptions or recover provider accounts.

Rule mode is the usual choice for everyday use: requests are matched against the configured rules in order. Global mode sends requests that reach the core to the selected global policy, which can help determine whether a routing rule is at fault. Direct mode connects requests that reach the core directly. None of these modes replaces the system proxy or TUN routing. If switching to Global restores access, that points to the original routing path as something to investigate—it does not prove that every network issue is fixed. Switch back to Rule mode after testing, then check the connection log for the rule and policy actually used.

The system proxy changes the operating system’s proxy settings, mainly affecting apps that honor them. TUN creates a virtual network interface and uses routing to capture traffic from more programs; it usually requires a service or elevated permissions. Some clients allow both, but whether that works correctly depends on route exclusions, DNS, and the core implementation. When setting things up, start with system proxy and test in a browser. Enable TUN only if you need coverage for games, command-line tools, or other apps. If using both causes connection loops, unusual resource use, or loss of connectivity, disable one capture method and keep the smallest setup that reproduces the issue.

Note your operating system, client name, core details, traffic-capture method, and the exact time the problem occurred. Save the logs around one failed request. Look for configuration load errors, listener addresses, DNS failures, connection targets, and matched policies. If needed, temporarily increase the log level, reproduce the issue, then restore the default. Before sharing logs, remove subscription URLs, credentials, node server details, and personal browsing records; check screenshots for visible addresses too. “The browser works, but one app fails” is more useful than “nothing connects.” Change one variable at a time so the logs help narrow things down.

Check the device clock and basic internet connection first. Then sign in to your provider’s account page to see whether the subscription expired, reached its data limit, or had its link reset. Check the update log’s HTTP status: 401 or 403 usually indicates an authorization or access restriction, 404 may mean the URL changed, and a timeout calls for checking DNS and the network path. If the client lets you choose an update method, try both a direct update and an update through an already working proxy. Keep the last known-good configuration instead of repeatedly deleting and recreating it. A downloaded login or verification page is not an importable configuration, even if the request succeeded.

First check whether you imported a complete Clash configuration, a node list, or an ordinary web page. A node list belongs in the relevant proxy provider or client template; it cannot be used directly as a complete running configuration. For YAML errors, check the line number in the log and the line above it. Make sure indentation uses spaces, list hyphens are correctly placed, and strings after colons are quoted when necessary. Then confirm that the active core supports the subscription’s protocols and fields. After importing, select the configuration and reload it: seeing it in the configuration list does not mean the core has switched to it.

Check the client log for the actual listening port of mixed-port. Then confirm that the system HTTP and HTTPS proxy settings point to the same local address and port, such as 127.0.0.1:7890. That port is only an example; use the one in your configuration. Disable browser proxy extensions and restart the browser. Check whether it uses separate proxy settings or is controlled by an organization policy. To test the explicit proxy, run curl -x http://127.0.0.1:7890 -I https://example.com. If the command works but the browser does not, investigate browser settings and how the system proxy was applied before changing nodes.

Close other VPNs and virtual network adapter tools first, then install or repair the service mode as described by your client. On Windows, check whether the service is running and whether security software blocked it. On macOS, check the relevant network extension or VPN permissions in System Settings. On Linux, confirm that /dev/net/tun exists and that the service has the network permissions it needs. Do not leave system protection disabled just to get TUN running, and do not grant permissions to unknown files. After granting access, restart the core. If it still fails, look for the first adapter or routing error in the logs rather than relying on the main toggle in the interface.

First confirm that you are editing the configuration currently in use. Then check whether the client adds overrides, scripts, or merged settings when loading it. Direct edits to a downloaded remote subscription may be overwritten at the next update. Use the client’s override feature for settings you want to keep, such as ports, DNS, and custom rules. Export a copy before editing, change one group of fields at a time, then save, reload, and check the logs. Array merge behavior varies between clients, so check whether rules are appended or replaced. Trust the final running configuration, not just one file open in an editor.

In Rule mode, place DOMAIN-SUFFIX,example.com,DIRECT before broader rules that might match first, and keep the fallback rule at the end. DOMAIN-SUFFIX matches the domain and its subdomains; use DOMAIN to match one exact hostname. Save and reload, close existing connections to the site, and make a new request. Check the connection panel for the rule type and final policy. A webpage may load resources from several domains, so allowing only its main domain might not cover every request. Rules do not change existing long-lived connections retroactively; disconnect them and retry if needed.

Enable allow-lan only if you need to share the proxy, and make sure the listening address covers the network adapter those devices will use. On other devices, enter the LAN address of the computer running the client—not 127.0.0.1, which always refers to the device itself. Configure the host firewall to allow access to the proxy port only from trusted subnets. Set proxy authentication if the client supports it, and confirm that your router is not forwarding the port to the public internet. The management interface is separate from the proxy port; do not expose it as well. Turn off LAN access after testing if it is no longer needed.

Start by testing the tool’s own proxy option, for example curl -x http://127.0.0.1:7890 -I https://example.com. Then set HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY as described in the terminal and tool documentation. HTTPS in a variable name usually describes the type of destination request; it does not mean the proxy endpoint itself must use HTTPS. Use a protocol supported by the local listener. Environment variables generally affect only the current process and its child processes, so existing terminals or background services may not pick them up. Remove temporary settings after testing so commands do not keep pointing to a dead port after the client exits. For DNS issues, distinguish local resolution from resolution through the proxy.

First check whether your provider already offers a subscription format that works with your current core. If it does, there is no need to add a conversion step. If conversion is necessary, prefer a trusted local tool and identify whether the input is a node link, node list, or complete configuration. Sending a full subscription to an online converter gives that service access to its credentials and node details. After conversion, check proxy group references, rule order, and protocol fields—not just whether the import succeeded. Conversion changes the format; it cannot fix an expired account, an unreachable server, or protocol features unsupported by the core.

Export the configuration currently in use. Record the client settings, listening ports, core details, and whether service mode is enabled; keep any necessary override files too. Backups may contain subscription URLs and credentials, so store them securely and never upload them to a public repository. Update the client, core, and subscription template separately, testing browser access, DNS, and commonly used apps after each change. If something breaks, restore the previous configuration first, then decide whether to roll back the program. For service or driver changes, follow the client’s uninstall procedure to avoid mixing an old service with a new program.

A timeout only means the test did not finish within its time limit. Possible causes include an unreachable test endpoint, an incorrect system clock, DNS failure, outbound network restrictions, or an unavailable node. First confirm that a normal direct connection works. Then use a known-good node for a real webpage request and check the connection log to see where it fails. If every node fails, check shared dependencies first, such as DNS, the network environment, and core configuration. If only a few fail, investigate server or protocol differences. A successful connection test does not guarantee that every website, UDP traffic, or long-lived connection will work; retest with the actual app and request you need.

Turn off the proxy first to confirm the underlying internet connection. Restart the client and check that the configuration loaded, the port is listening, and a usable node is selected in the proxy group. Next, use an explicit proxy request to distinguish a local listener problem from system proxy capture. Temporarily switch to Global mode to check whether routing rules are involved, then review DNS resolution and TUN routing logs. Record the result at each step; do not change the port, DNS, and node all at once. “Connected” in the interface usually means only that a local feature is enabled—it does not confirm that the target request succeeded. Follow one specific request from DNS lookup through to the connection failure.

First confirm that the browser works through the local proxy. Then check whether the failing app is subject to the app container’s loopback restrictions. Some UWP apps cannot access a local loopback proxy directly. Use the client’s loopback exemption tool to authorize only the apps that need it, or run CheckNetIsolation LoopbackExempt -s in an administrator terminal to view existing exemptions. Do not exempt every app just for convenience. If the app still fails, check its network interface, proxy settings, and firewall; test TUN separately if needed. Not every Windows Store app is a UWP app, so the installation source alone is not enough to tell.

Record the system DNS, browser secure DNS, client DNS, and current traffic-capture method. Do not judge a leak solely by the location shown on a test site. With fake-ip, confirm that dns.enable and enhanced-mode are active. Follow the core’s configuration guidance to check DNS hijacking under TUN, routing, and the DNS egress path. Check separately whether the browser is making its own encrypted DNS requests. Clear the system and browser DNS caches, establish a fresh connection, and test again. If respect-rules is enabled, also check DNS rules and bootstrap resolution for proxy server hostnames to avoid a loop where DNS depends on the proxy and the proxy depends on DNS.

If the internet stops working after you quit, check whether the system proxy still points to a local port that is no longer running. Clear any leftover proxy settings and confirm that the TUN service, virtual adapter, and routes were removed according to the client’s shutdown process. If a port is in use, identify the process before taking action. On Windows, use netstat -ano to find the listener and PID. On macOS or Linux, use lsof -nP -iTCP:7890 -sTCP:LISTEN to inspect the example port. Do not terminate unknown system processes. If you change mixed-port, update the system proxy, terminal environment variables, and LAN devices too; otherwise, a port conflict may simply become a connection refusal.