Clash FAQs and Troubleshooting

A Clash client usually consists of a graphical interface, configuration manager, and proxy core. The interface imports subscriptions, selects policies, and switches the system proxy; the core parses configuration, matches rules, and forwards connections. Mihomo is an actively maintained core that continues the Clash configuration model. Different clients may bundle different core versions, so similar interfaces do not guarantee identical field support.

A subscription link is a web address used to retrieve configuration data; the client downloads and updates the configuration through it. A YAML configuration file is the text actually read by the core and contains fields such as proxy nodes, policy groups, rules, and DNS. Links can update periodically, while a locally imported YAML file usually does not follow server-side changes automatically.

Rule mode is usually best for everyday use: the configuration rules determine whether each connection uses a proxy or connects directly. Global mode sends most interceptable connections through the current policy group and is useful for temporarily testing node availability. Direct mode bypasses the proxy and helps rule out client-side network interference. Return to the mode that matches your needs after troubleshooting.

Start by choosing Windows, macOS, Android, iOS, or Linux, then check the processor architecture and OS version. On desktops, prefer a maintained graphical client with an active core. Run Mihomo directly mainly on servers and routers. Older clients can read legacy configurations, but may not recognize newer fields.

A Clash client only reads configuration, applies rules, and forwards connections; it does not provide subscription services. The subscription URL, node status, traffic allowance, and expiration date are managed by the relevant provider. When the client reports a subscription error, determine whether the cause is local importing, network access, or an unavailable subscription service.

The location depends on the client and operating system. Common access points are the client’s Configuration, Profiles, or subscription-management page. When editing manually, use the client’s option to open the configuration directory instead of overwriting a file based on another client’s path. Stop automatic updates before editing, then validate and reload the configuration.

Make sure the copied URL is complete, has no leading spaces, and has not been truncated by a chat app. Open it in a browser to confirm it still returns content and that the response is Clash-readable YAML rather than a login page, error message, or another subscription format. Then check the system clock, network access, core compatibility, and provider status.

Confirm that the client core is running and that the system-proxy switch was actually written to the OS settings. Check that the HTTP or Mixed port matches the system proxy port, disable separately configured browser proxy extensions, and fully restart the browser. Some apps do not read the system proxy; use TUN mode or configure a proxy inside the app instead.

TUN mode creates a virtual network interface, adds routes, and adjusts DNS, which typically requires administrator or system-level privileges. On Windows, follow the client’s instructions to install its service or complete the initial setup as an administrator. macOS requires approval for the network extension, while Linux usually requires network-management capabilities. After granting access, restart the core and verify that the virtual interface appears.

Check loopback restrictions when a Microsoft Store or legacy UWP app cannot connect to the local proxy while regular desktop apps work normally. Use the client’s built-in UWP loopback tool, select the apps that need local proxy access, save the changes, and restart those apps. Do not select every entry at once, as this can expand network access unnecessarily.

Do not keep editing rules directly in an auto-updating subscription file, because the next update will usually overwrite them. Prefer the client’s override, merge, script, or local rule-set features to store custom content separately from the remote subscription. After updating, check whether policy-group names changed and confirm that the policies referenced by custom rules still exist.

Rules are matched from top to bottom and usually stop after a match, so more specific rules should come before general ones. Custom domain, process, or network-range rules must appear before fallback rules such as MATCH and point to policy groups that actually exist in the configuration. Validate the syntax after saving, then use connection logs to confirm which rule matched.

Latency tests usually measure only the round-trip time to a test target; they do not fully represent bandwidth, packet loss, congestion, or the route to the destination site. Test multiple nodes repeatedly on the same network and compare page loads, file transfers, and runtime logs. Also check the node’s traffic multiplier, protocol compatibility, regional routing, and any server-side concurrency limits.

First confirm that the current connection is actually being handled by Clash, then check which DNS servers the system, browser, and client are each using. A browser’s Secure DNS may bypass system settings, and TUN and system-proxy modes use different DNS paths. After changing the configuration, clear the system DNS cache and restart the browser. Use resolution logs to confirm that requests reach Clash’s DNS module.

Enable LAN access in the client and make sure the listen address is not bound only to the local loopback address. Then allow the proxy port through the system firewall. Other devices should use the LAN address of the computer running Clash as their proxy server, not 127.0.0.1. Open ports only on trusted networks and never expose the control interface directly to the public internet.

Check the subscription’s last-update time, expiration status, and response content to ensure the URL has not redirected to a login or error page. If the old configuration still works but the updated one has no nodes, keep the old file and contact the provider to verify the account and format status. Do not repeatedly overwrite the local configuration; export the working configuration first and fetch the subscription again after service is restored.

Switch to Direct mode first to confirm that the underlying network works, then pause the system proxy and restart the core. Next check the system clock, subscription expiration, support for the node protocol in the current core, and whether the local firewall blocks the client. If only latency tests time out while websites load, try another test target so an unreachable target is not mistaken for a failure of every node.

Exit other proxy clients and use Task Manager or the system process list to confirm that no old core process remains. Check whether port, mixed-port, socks-port, and the control port are duplicated, and verify that none is used by another program. After changing a port, update the system proxy settings accordingly, restart the core, and watch the first listening log entry.

Turn off TUN and the system proxy first and confirm that basic connectivity returns. Exit the client and check for leftover virtual adapters and routes. After restarting, enable only TUN and temporarily test with a simplified DNS configuration. If the problem continues, check administrator privileges, automatic interface selection, default-route conflicts, other VPN apps, security software blocks, and log entries showing failures to create the interface or add routes.

End any leftover client and core processes, then try starting with a known-valid basic configuration. If the issue began after an update, check deprecated fields in the old configuration, corrupted interface data, and system runtimes. If the window is missing, check the system tray and saved multi-monitor position. If it still crashes, inspect the application log for the final configuration-parsing or permission error.