Clash FAQs and Troubleshooting

Clash usually refers to a proxy configuration syntax and rule-based traffic-routing ecosystem. Mihomo is a core that continues this configuration ecosystem, handling proxy connections, rule matching, DNS, and TUN interface creation. Graphical clients such as Clash Verge Rev and Clash Plus handle subscription imports, node selection, system proxy toggles, and log viewing. When troubleshooting, first determine whether the issue lies in the client interface, core process, configuration file, or upstream node.

Rule mode matches connections against the rules in the configuration file from top to bottom, then sends traffic to the specified policy group. Global mode typically sends every connection managed by Clash through one proxy policy. Direct mode lets managed connections access their destinations directly. Use Rule mode for everyday traffic. Switch briefly to Global mode only when comparing results to determine whether a rule is routing traffic incorrectly.

Global mode affects only traffic that has already entered Clash; it does not forcibly take over every connection on the device. Applications that ignore the system proxy, games with their own network stack, some command-line tools, and local-network traffic may bypass it. First confirm that the system proxy is enabled, then check the application's own proxy settings. To capture more TCP and UDP traffic, use TUN mode after verifying permissions and routing configuration.

Clash for Windows is no longer maintained. Existing installations may continue to run, but they will not receive ongoing compatibility fixes or core updates. Before migrating an old configuration, preserve the subscription URL, override rules, and policy selections, then move to a client that is still maintained. Do not copy the entire old application directory over a new client; configuration paths, core fields, and override mechanisms may differ between clients.

Open the subscription update log first and confirm that the server returned a Clash configuration rather than a login page, notice page, or empty response. Then inspect the line reported in the parse error, paying particular attention to the indentation and field types of proxies, proxy-groups, and rules. If the subscription downloads successfully but the node list is empty, delete its local cache and import it again, making sure the client has selected the newly updated configuration file.

Open the subscription URL in a browser first and confirm that it returns a normal response rather than an expiration notice. If the URL contains a temporary token, obtain the complete link again from the subscription provider. If content is returned but the client reports a parse failure, import it as a new standalone configuration so that old overrides do not continue to apply, then use the logs to locate the field causing the error. If it worked before an update and failed immediately afterward, check the remote configuration for indentation errors, duplicate keys, or fields unsupported by the client.

First confirm that the Clash core is running and that the system proxy address points to its current listening port. If the browser has a proxy extension installed, its settings may override the operating system configuration; disable it temporarily and test again. On Windows, check for an old address left in the proxy settings. On macOS, verify the HTTP and HTTPS entries on the proxy page for the active network service. Finally, use the client logs to confirm that browser requests are reaching the core; no log entries usually mean the traffic has not been captured.

Some apps that use UWP network isolation cannot access a loopback proxy on the local machine directly, so a browser may work while a Store app fails to connect. In the UWP loopback tool provided by the client, select the affected app, save the changes, and restart it. Select only applications that genuinely need the local proxy. If the client has no loopback tool, configure access with Windows' built-in CheckNetIsolation capability and test again after making the change.

A latency test shows only the response time between the current network and the test target. It does not, by itself, represent download speed, peak-hour stability, or availability of the destination website. Compare nodes using the same test address and network, and run several consecutive tests to see whether timeouts are frequent. After choosing a node, test actual browsing and sustained downloads. If latency looks normal but a specific site fails, investigate rules, DNS, or restrictions at the destination instead of repeatedly running speed tests.

Switching nodes usually affects only new connections; existing long-lived connections may continue using the old node. Close and reopen the target application, or terminate the relevant connection in the client's connection list before testing again. Also confirm that the policy group matched by the current rule is the one you changed. If the rule points to another group, changing an unrelated group will have no effect. With automatic selection or failover enabled, the final node may also be chosen based on the group's health checks.

Clash rules are generally matched from top to bottom. Once a connection matches the first applicable rule, matching stops. An overly broad DOMAIN-SUFFIX, IP-CIDR, or rule set placed too early can shadow more precise rules below it. MATCH is the fallback rule and should be last. After editing, inspect the matched rule and policy in the connection details. Validate one domain first, then expand the scope gradually so that you can identify the cause.

A remote subscription update usually replaces the main contents of its configuration, so local changes should not be maintained directly in the downloaded file. Prefer the client's override, merge, or script features, and keep local DNS, rule, and policy-group changes in a separate layer. Whether policy selections persist depends on whether the client saves state by policy-group name; changing a group name often requires selecting it again. Export local overrides before making changes, and verify the merged result with a copy first.

Disable the proxy first and verify that the local network can access common websites directly. Then update the subscription and confirm that the node details are still valid. Test at least two nodes to distinguish a single-node failure from a failure at the network entry point. If every node times out, check the system clock, firewall, other proxy software, and core logs. If only a specific protocol fails, verify the fields required by that protocol. Finally, test over a phone hotspot to quickly determine whether the issue comes from the current broadband connection or local network.

TUN creates a virtual network interface and changes routing, so it requires more privileges than a standard system proxy. On Windows, restart the client as an administrator and check that service mode is installed correctly. On macOS, allow the client to install or enable its network helper component. On Linux, confirm that the process has permission to create a TUN device and manage routes. After fixing permissions, disable other VPN and virtual-network-interface tools before enabling TUN again, preventing multiple programs from rewriting routes and DNS at the same time.

This usually points to the DNS path. Check the logs for query timeouts, then confirm that nameserver, fallback, or proxy-server-nameserver in the configuration is reachable from the current network. With Fake-IP enabled, also verify that enhanced mode, the exclusion list, and TUN DNS hijacking are configured consistently. Temporarily switch to a standard DNS configuration for comparison, but do not change nodes and rules at the same time. If resolution still fails after disabling Clash, restore the DNS settings on the system network adapter first.

A common cause is that the system proxy has been restored before the Clash core has finished starting, so system traffic is sent to a local port that is not listening yet. Disable the system proxy to restore direct access, then check for duplicate client launches, whether the configuration loads correctly, and whether another program is using the core's port. You can disable automatic system-proxy activation at startup and enable it manually after the core is ready. If the client supports startup delay or service mode, use it to adjust the startup order.