Clash FAQ

Clash usually refers to a proxy core and its configuration ecosystem. Mihomo is an actively developed core in that ecosystem, previously known as Clash Meta. GUI clients such as Clash Verge Rev and Clash Meta for Android handle subscription management, policy selection, and system integration. The protocols and configuration fields they support still depend on the core they use. Before following a tutorial, check the core name in the client’s About or core settings and consult the matching documentation. A Clash label in the interface does not mean configurations are fully interchangeable between clients.

A client reads configuration and routes traffic, but installing it does not provide a working proxy connection by itself. Subscriptions usually come from your service provider and may include nodes, policy groups, rules, and DNS settings; a single node link typically describes just one connection. Make sure you have a configuration subscription compatible with your core, then import it and set it as the active configuration. Subscription URLs may contain account credentials, so do not post them on public forums, include them in screenshots, or paste them into unfamiliar online converters. When asking for help, share only error messages with sensitive details removed.

Rule mode routes traffic according to the rules in your configuration, making it suitable for everyday routing by domain, address, or app. Global mode sends connections that reach the core through the selected global policy; you still need to choose a working proxy, and it does not capture app traffic that never reaches the client. Direct mode usually sends connections handled by the core straight to their destination. To troubleshoot a website, temporarily switch to Global and select a known-working node, then compare the result with Rule mode. Restore your original mode afterward so temporary test settings are not left in place.

Not necessarily. System Proxy sets the local proxy address in the operating system and mainly serves apps that follow that setting. TUN routes traffic through a virtual network interface; its coverage depends on the platform, permissions, and routing configuration. If your browser works, you can keep System Proxy enabled without adding TUN just to turn on more options. For apps that ignore the system proxy, enable TUN according to the client’s documentation and check DNS. Some clients can use both modes together, but that does not guarantee all traffic is captured. Avoid conflicts with routes from another VPN.

In the client, open the Configuration, Subscription, or Profiles page, choose the option to import from a URL, paste the full address, and save it. Once downloaded, set that configuration as active, then open the proxy or policy group page and choose an exit. If you get a YAML parsing error, check that the URL returns a Clash-compatible configuration rather than a login page, regular webpage, or subscription in another format. Finally, enable System Proxy or TUN as needed, visit a website in your browser, and check the connection log. Seeing a configuration listed does not mean it is active or that traffic is reaching the core.

On Windows, check System Information in Settings to see whether your system uses an x64 or ARM processor. On macOS, check About This Mac for an Apple or Intel chip. For Android, use your device’s processor architecture and the client’s release notes; many newer devices use ARM64, but the Android version alone is not enough to determine this. Use a universal package only if the client offers one. On Linux, check both the processor architecture and the package format used by your distribution, such as deb or rpm. If installation fails, verify these details and the minimum OS requirements rather than repeatedly trying installers from unknown sources.

Save your working configuration first, then check the client log to see whether permission was denied, virtual interface creation failed, or route setup failed. On Windows, the client may need service mode installed or administrator permissions granted as documented. macOS may require authorization for a privileged helper or network component. On Android, approve the system VPN connection request and check whether another VPN is already active. Linux permissions depend on how the client runs, so follow its documentation. Do not change system security settings just because you see TUN in an error. If permissions are correct and it still fails, check for conflicts with other VPNs, virtual adapters, or routes.

First confirm that a regular browser can access the internet through the same proxy. Then check whether the issue occurs only in a UWP app subject to app-container restrictions. These apps may be blocked from accessing a local proxy address by loopback restrictions. Use the client’s loopback exemption tool, if available, or follow Windows documentation to configure an exemption for the specific app package with CheckNetIsolation. Administrator permissions are usually required. Exempt only apps that need it and note your changes so you can undo them. Not every Store app is UWP, and loopback restrictions are not the cause of every connection failure. If the exemption does not help, check whether the app uses the system proxy and review its network settings.

Check that the client core is running and that the system proxy address and port match the active listener in your configuration. Then check whether a browser extension, enterprise policy, or separate proxy setting overrides the system proxy, and make sure the destination is not on the system bypass list. Watch the client connection log while loading the website. If nothing appears, check how traffic enters the client; if a connection appears but goes direct, check the rules and policy group selection. Reapply the system proxy settings after changing the configured port. If multiple proxy clients are running, quit the others to prevent them from repeatedly overwriting the same system setting.

No. A client’s latency test usually sends a request through a node to a specified test endpoint. The result shows whether that request connected and how long it took at that moment; it does not measure sustained bandwidth or guarantee that a particular website is reachable. If the test endpoint is unavailable, a working node may still time out. Choose nodes based on real-world access, connection logs, and your provider’s status, and avoid running large numbers of tests in quick succession. To compare download performance, use the same destination, similar times, and the same network conditions. Keep in mind that tests may use subscription data, and the lowest single latency is not necessarily best for every use case.

Fake-IP is a DNS enhancement supported by some cores. It returns a mapped address for a domain, which the core then associates with the original domain when handling the connection. It is not the actual address of a proxy server. Local network devices, apps that rely on real DNS responses, and certain discovery protocols may need additional handling. First check whether the issue occurs only when this mode is enabled. Then review local DNS resolution, DNS interception, and LAN routing. If needed, follow the core documentation to configure fake-ip-filter for specific domains or adjust the relevant DNS policy. Avoid broad exclusions; after making changes, clear old app or system DNS caches and test again.

A remote subscription update may replace the entire configuration, overwriting edits made directly in the subscription file. Renamed nodes or policy groups can also prevent previous selections from matching. First identify whether you are editing a cached remote configuration, a separate local configuration, or a client-provided override layer. For rules that must persist, use the client’s supported override, merge, or scripting mechanism, and check the rule order in the generated configuration. Automatic updates and remembered policy selections are separate features; enabling updates alone will not preserve every selection. Save a restorable copy before making changes.

Start by noting the HTTP status or error in the log. A 401 or 403 may indicate an authorization, access policy, or credential issue; a 404 may mean the URL is no longer valid; timeouts or DNS failures call for checking the network and DNS first. A status code alone cannot confirm the cause, so check your provider’s account page for expiration, data limits, or a changed subscription URL, then copy the full URL again. If the response is a login or verification page, ask the provider for a client-compatible link. A URL opening in your browser does not mean the client uses the same network route. If needed, test direct and proxied updates using the client’s options, and avoid repeated retries that could trigger rate limits.

Usually, checking shared causes is more effective than reinstalling. Confirm that your device can access the internet directly, your subscription is still valid and has data remaining, and your system date, time, and time zone are correct. Then make sure the active core supports the subscription’s protocols and parameters, and check the logs for handshake, certificate, or DNS errors. If every node times out, the test endpoint itself may be unreachable, so verify actual browsing separately. If the issue occurs only on your current network, test another network where use is permitted to distinguish a local problem from a network-path issue. Do not disable certificate verification just to bypass a certificate error.

Check traffic entry, DNS, rules, and the proxy exit, in that order. First see whether browser requests appear in the connection log. If not, check whether System Proxy or TUN is actually working. If requests appear but domain resolution fails, review the DNS configuration and whether DNS is reachable on the current network. Next, check which rule and policy group matched the connection to make sure it is not using an unavailable exit or going direct unexpectedly. Finally, compare with another known-working node and check whether the website itself is down. A “connected” status may only mean the core or virtual interface has started; it does not verify end-to-end access. Change one setting at a time and record the results before and after.

First check whether the error refers to a proxy listener such as mixed-port or to the external controller port; these are different ports. On Windows, use netstat -ano to find the listening entry and PID, then identify the process in Task Manager. On macOS or Linux, use lsof -i :7890 to check what is using the port; you may need additional permissions. If it is an old client, exit it normally rather than terminating an unknown system process. To run both clients, choose an unused port for the new one and change it in the active configuration or the client’s port settings. Update the system proxy and any app-specific proxy settings too, then restart and test.