Clash FAQs

The Clash client provides the interface for importing configurations, choosing proxy groups, and viewing connections. The mihomo core parses configurations, matches rules, and handles network connections. Subscriptions are usually maintained by a service provider and deliver nodes or complete configurations. Installing a client does not provide proxy service. To troubleshoot, first check which configuration is active, then confirm the core is running, and finally verify that the nodes are available. This helps distinguish subscription issues from installation problems.

Rule mode matches connections against the configured rules from top to bottom, making it suitable for everyday traffic routing. Global mode sends connections entering the core to the global proxy group, which may still select Direct. Direct mode connects traffic entering the core straight to its destination. Global mode does not automatically capture traffic from every app. If one site has a problem, temporarily switch to Global mode for comparison. Then switch back to Rule mode and check the connection log to see which rule matched.

A system proxy provides apps with a local proxy address and affects only programs that honor that setting. TUN mode uses a virtual network interface and routes to capture traffic, so it can cover some apps that ignore the system proxy, but it usually requires administrator privileges or service mode. Coverage depends on routing, exclusions, DNS, and system restrictions. First use the system proxy to verify your configuration and nodes, then enable TUN if needed. Changing several settings at once makes problems harder to isolate.

A latency test usually measures the time for one request to a specific test address; it does not indicate a node’s sustained bandwidth. Video and downloads are also affected by congestion at the exit, the destination site, packet loss, service throttling, and your local Wi-Fi. First make sure the speed test and the app use the same node, then compare using the same file or video quality. Don’t rank nodes by latency alone or compare results from different test addresses or networks.

A file extension alone cannot tell you whether a configuration is compatible. Clients may use different cores or add DNS, TUN, or rule settings when importing a file. Some protocols and configuration fields are supported only by specific cores. Before migrating, keep a copy of the original configuration and local overrides, check which core the new client uses, and look for specific field errors in the parse log. If your old client is no longer maintained, move to a maintained version rather than repeatedly deleting fields it does not recognize.

Make sure you copied the subscription URL, not an account page or a web-sharing link, and check for spaces or line breaks at either end. Then review the update log: a login page, empty response, or unsupported format can all leave the list empty. Also confirm the configuration is selected as the active one and check whether the node provider needs to be updated separately. Never post a full subscription URL in a public forum; its access credentials may let others retrieve your subscription.

A 401 or 403 usually means the request was not authorized, though it may also indicate an access restriction imposed by the provider. Check your account page for the subscription’s expiry date, remaining data, and whether the URL has been reset; then copy the new URL and update it. Make sure the client’s subscription request is not blocked by an incorrect rule, and verify that your system clock is accurate. Don’t repeatedly retry to bypass service restrictions. If the new URL returns the same status, note the time and status code and contact the provider. Keep access credentials in the URL private.

Start with the line number and field name in the error log, then check nearby indentation, colons, list hyphens, and matching quotes. YAML indentation uses spaces, not tabs; quote values with special characters as needed. If the error involves a proxy group or rule target, make sure the referenced name exists and uses the correct capitalization. Save the original file before making changes, edit one thing at a time, and reload. Subscription updates may overwrite manual edits, so use the client’s override mechanism for long-term changes.

Turn off TUN first and confirm that the system proxy can connect normally. On Windows, install or repair service mode as described by the client, then confirm authorization succeeded. On macOS, check the required network extension or VPN permission. On Linux, check the permissions needed for the TUN device and process. If you have used another VPN, disconnect it temporarily and check for virtual adapter conflicts. Don’t leave security protections disabled to work around the error; use the log to identify whether permissions, drivers, or devices are at fault.

Some UWP apps are restricted by network isolation and cannot access a local proxy at a loopback address. First confirm that a regular browser can connect through the same proxy. Then check whether the client offers a UWP loopback exemption tool, and enable the exemption only for apps that need it. An exemption does not force an app to use the system proxy. If the app still bypasses the proxy, test TUN once permissions and routing are working. After an app update or reinstall, you may need to check its package’s exemption again.

Use the client’s rule overrides, extended configuration, or merge feature instead of editing the cached subscription file directly. First make sure the target proxy group exists, then put specific domain rules before broader rules and the final MATCH rule. Rules use first-match wins, so entries after MATCH will never run. Save and reload the configuration, then check the connection log to confirm the matched rule and policy. After a subscription update, verify that the override is still applied.

First check that the active group uses automatic testing rather than select, which requires manual selection. url-test chooses a node based on the configured test URL, interval, timeout, and tolerance; it does not continuously measure speed for every real-world connection. If the group references a node provider, make sure that provider has been updated. Existing connections may continue using the old node after a policy switch. Test with a new connection and, if needed, close only the relevant old connections instead of repeatedly restarting the entire client.

Consider subscription conversion only when the provider’s format differs from what the client requires and the client cannot import it directly. First ask the provider for a mihomo- or Clash-compatible configuration to avoid an extra conversion step. A third-party conversion service may gain access to the full subscription URL and may change rules, DNS, or proxy groups. Check how the service handles your data, then verify protocol settings and policy references after conversion. If the subscription imports directly, there’s no need to convert it just to change the interface.

Find the target domain or process on the client’s Connections page and check the matched rule, policy chain, and exit node against the current proxy group selection. The exit IP shown in a browser does not tell you how other apps are routed. If the app does not appear in the log, check whether it bypasses the system proxy or is excluded from TUN. Close the app’s existing connections before testing and make a new request. For domain rules, check DNS records too; don’t infer the route from the destination IP alone.

Back up local rule overrides, proxy group selections, custom DNS and TUN settings, and any configuration files you want to keep. Subscription URLs and configurations may contain access credentials, so store them securely rather than in a public repository or cloud drive. After migrating, confirm that the new client can load the configuration before restoring custom settings one at a time. Internal data directories may not be compatible across clients; use an export feature or readable configuration when possible, and don’t overwrite the entire application data directory.

Turn off the proxy and test your basic connection. Check that the system clock, gateway, and access to regular websites are working. Then verify that the active configuration contains valid nodes, the subscription has not expired, and the test address is reachable. Try another node and test against the actual destination site; if needed, switch to a mobile hotspot to distinguish local network restrictions from a server-side issue. If only the built-in speed test times out while regular access works, check the test URL and rules instead of assuming every node is down.

Confirm that the core is running and that its local listening port matches the port in the system proxy settings. Check for port conflicts. Then see whether the browser has a separate proxy extension enabled or uses proxy settings that ignore the system configuration. Temporarily disable other VPNs and proxy apps, and test with just one client running. If the request appears in the connection log, check the rules, node, and DNS. If there is no entry, focus on the path between the app and the local proxy.

Find the domain in the connection log and check whether it was rejected by REJECT, incorrectly routed to Direct, or sent to an unavailable proxy group. Temporarily test in Global mode with a verified working node. If access returns, the routing path likely differs, but that alone does not prove DNS is working. If the log shows a resolution failure or an unexpected address, check the DNS upstream, domain policies, and the browser’s Secure DNS setting. Change one setting at a time and establish a new connection to test.

First define the expected behavior: which resolver should handle each domain, and whether DNS requests should go through the proxy. Check core DNS, TUN DNS hijacking, the system resolver, and browser Secure DNS to make sure requests aren’t taking different paths. A browser’s encrypted DNS may bypass system resolution, and the system proxy does not guarantee that all DNS traffic is captured. Check the core logs and capture network traffic to investigate. The resolver location shown by a DNS test site is only a clue.

Check whether the system proxy still points to a local port that is no longer active; turn it off or restore its previous settings. If you used TUN, reopen the client, disable TUN, and exit normally. Then check for leftover virtual adapters, routes, and DNS settings. Don’t change existing proxy settings on a device managed by your organization. Record the original settings before restoring connectivity, and avoid a full network reset. Only proceed with further repair steps if the usual recovery steps clearly haven’t worked, following your operating system’s instructions.