Clash FAQ and Troubleshooting

Clash usually refers to a rule-based proxy project and its ecosystem. Mihomo is a core that supports the Clash configuration format while extending its features. Clash Verge Rev, Clash Plus, and FlClash are graphical clients. Graphical clients handle configuration imports, policy switching, and system proxy control, while the built-in core usually handles connections and rule matching. When choosing a client, also check its maintenance status, operating system support, and core in use.

Rule mode follows the rules in the configuration file to send connections direct, through a proxy, or to be blocked, making it suitable for everyday use. Global mode routes most traffic through the currently selected proxy policy and is useful for briefly testing whether a node works. Direct mode bypasses the proxy and helps determine whether a problem comes from the proxy path. During troubleshooting, test the node in Global mode first, then return to Rule mode to inspect rule matches.

The system proxy affects apps that follow the operating system proxy settings, such as most browsers and some desktop software. Command-line tools, games, and apps with their own network stack may ignore those settings. TUN mode uses a virtual network interface to capture a broader range of traffic, but it requires administrator permission and may conflict with security software, virtual machines, or other network filters.

Proxy nodes store server connection parameters. Policy groups combine multiple nodes or other policies, while rules send domains, IP addresses, or network types to a designated policy group. A connection typically matches rules from top to bottom, enters the matched policy group, and then selects the final node through manual selection, automatic latency testing, or failover. When renaming items, also check policy-group references and rule targets.

Subscription configurations are convenient when a provider maintains nodes and basic rules centrally, but refreshing them may overwrite edits made directly in the subscription file. Local configurations are better for keeping custom DNS settings, rules, and policy groups over time. If both are needed, prefer the client's override, extension-script, or configuration-merge features instead of editing an original file that subscription refreshes may replace.

After importing, confirm that the configuration is enabled and that proxy nodes and policy groups appear correctly. Select a working node, enable the system proxy, and visit a familiar website in a browser to verify the connection. Enable TUN according to platform permissions only when you need to capture command-line tools, games, or more apps. Do not change DNS, rules, and ports at the same time before basic proxy access is verified, or the source of the problem will be harder to identify.

First open the subscription URL in a browser and confirm that it returns content rather than a login page, error page, or empty file. Then check the system clock, network connection, and HTTP status in the client log. If the old configuration still connects, switch to a working node and try updating again. If the provider reset the URL, obtain a new subscription link. Because subscription URLs contain access credentials, never share them in screenshots, logs, or public text.

First check that indentation uses spaces consistently, that spaces follow colons, and that list-item hyphens have the correct nesting level. Confirm that fields such as proxies, proxy-groups, and rules are at the right level, and that referenced policy-group names match exactly. Restore the last configuration that loaded successfully, then add changes section by section, reloading after each save to locate the faulty section.

On Windows, quit the client, relaunch it as administrator, and reinstall or enable service mode. On macOS, allow the network extension when prompted and complete administrator authorization. If it still fails after permission is granted, check for leftover services from older versions, a disabled virtual adapter, or security software blocking the driver. Restart the client afterward, and restart the system if necessary to release old network components.

Some UWP apps cannot access the local proxy listening port by default, so Store apps may remain offline even when the browser works. In the client's UWP loopback tool, select the target apps and save. If there is no built-in option, use Windows loopback exemption management. Restart the target app afterward and confirm that Clash's local listening address and port have not changed.

Rule mode is usually best for everyday use because it classifies connections by domain and IP, reducing unnecessary proxy traffic. Global mode is better for briefly testing a node, ruling out a mistaken rule match, or handling a temporary case not yet covered by the rules. If Global mode works but Rule mode fails, inspect matched rules and policy groups in the connection log instead of leaving Global mode enabled.

Switch to other nodes in the same subscription first to determine whether one node or all nodes are unavailable. Then update the subscription and verify the system clock, since TLS connections depend on accurate time. If every node times out, temporarily disable TUN, restore the default DNS settings, and check whether the local firewall is blocking the client. A failed latency-test endpoint does not necessarily mean every website is inaccessible; use actual connection logs for confirmation.

First confirm that you updated the provider actually referenced by the current configuration, not a same-named provider in another disabled configuration. Check the provider's update time and download result in the log, then reload the configuration. If cached content was not refreshed, delete that provider's local cache and fetch it again. For configurations generated through a subscription converter, also confirm that the converter returned new content instead of serving an old cache.

Enable launch at startup in the client settings, then make sure the system's startup manager has not disabled the client. To take over network traffic automatically, also save the enabled state for the system proxy or TUN separately. Windows service mode and the macOS network extension may require separate authorization. Restart the system once to test, and confirm that the client loads the expected configuration instead of opening an empty configuration page.

Browsers usually read the system proxy, while terminal programs may ignore it. Set the HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY environment variables for the current terminal session, using the Clash HTTP, mixed, or SOCKS listening port as appropriate. You can also use TUN to capture the traffic. Open a new terminal after setting the variables, and check whether the tool has its own proxy configuration that could override them.

Check that the client is running, the configuration is enabled, and the local listening port matches the address in the system proxy settings. Then close other proxy software and browser extensions that may repeatedly rewrite those settings. Open the client's connection log to see whether requests reach Clash. No entries usually mean the app is not using the system proxy; entries with failures point to rules, policy groups, or nodes for further investigation.

Restore the client's default DNS settings and clear the operating system DNS cache first to rule out stale records. If you use fake-ip, check application compatibility and add LAN devices, printers, or special domains to the filter list. Confirm that nameserver and fallback are reachable from the current network. If only specific domains fail, inspect the DNS log and matched rules instead of changing several resolvers at once.

Disable TUN and quit the client first, then confirm that direct connectivity returns. Check the TUN stack, auto-route, and DNS hijacking settings, and temporarily disable other virtual adapters, VPNs, traffic-filtering software, or virtual-machine networks. If routes were not restored after an abnormal client exit, restart the system to clear stale routes. When enabling TUN again, test the default configuration first and restore custom options one at a time.

A port conflict usually comes from another running proxy client, an old process, or a duplicate Clash instance. Fully quit the related programs, then use system networking tools to find the process occupying mixed-port, port, or socks-port. End the conflicting process or move Clash to an unused port. Afterward, update the port in the system proxy, browser, and terminal environment variables.

Check whether the current policy group uses automatic latency testing or failover, and whether its interval is too short. Network fluctuations can repeatedly reorder nodes and rebuild connections. Temporarily select one stable node manually and see whether the problem disappears; also check the health-check URL, timeout threshold, and client log. If a fixed node still disconnects, investigate the local network, system sleep, and server status.