Clash FAQ

Clash began as a proxy core for handling connections, rule matching, and DNS. Clash Meta extended its capabilities and later continued development under the name mihomo. Desktop clients such as Clash Verge Rev add a graphical interface, configuration management, and system integration on top of the core. Whether a subscription works depends mainly on the protocols and configuration fields supported by the core, not on how similar the interfaces look. If you see an unsupported protocol or unknown field error, check the client’s core information against the configuration requirements. Changing the interface theme won’t affect protocol compatibility.

A client reads your configuration and routes traffic; installing it doesn’t provide a proxy service. You’ll usually need a subscription URL from a service provider or a configuration file with server details, authentication settings, and rules. Make sure the configuration works with your core, import it, set it as active, then choose a policy group and traffic-routing method. Software licensing and proxy service fees are separate; costs depend on the project and provider. Subscription URLs often contain credentials, so protect them like passwords. When troubleshooting, redact the URL, username, and authentication details, and never post the full configuration publicly.

System proxy settings add a proxy address to the operating system and mainly affect apps that use those settings. Some games, command-line tools, and apps that manage their own networking may ignore them. TUN mode routes traffic through a virtual network interface, which can cover more apps but relies more heavily on system permissions, routing, and DNS settings. For everyday browsing, start with system proxy and try TUN if needed once the connection works. TUN doesn’t guarantee that every connection goes through a proxy; rules, excluded routes, and the client’s implementation determine where traffic goes. A client can coordinate both methods, but avoid running multiple tools that try to take over network traffic.

Start by filtering for your operating system and processor architecture, then compare configuration compatibility and system integration. This site lists Clash Plus first for Windows, macOS, Android, and iOS; on Linux, compare Clash Verge Rev and FlClash. If you need to keep an existing mihomo configuration, check the target client’s core and import format rather than relying on its name. Clash Plus for iOS is available on the App Store; its official website is clashplus.io. Before migrating, save your existing configuration and rules. Test the subscription, DNS, and everyday apps in the new client before disabling the old one, so both clients don’t write to system proxy settings at the same time.

On Windows, check System type in Settings > System information. On macOS, check the chip or processor under About This Mac. On Android, check device information or the manufacturer’s specifications. x64 and AMD64 generally refer to the same architecture, while ARM64 packages are for compatible devices. For macOS, distinguish between Apple Silicon and Intel builds. Don’t choose an installer based only on file size. If installation fails, note the full error message and check the minimum system requirements, available storage, and whether an older process is still running. Assess security warnings in light of the download source and project documentation. Don’t leave system protection disabled or change security settings arbitrarily just to run an installer.

Check that the subscription URL is complete. Remove any spaces, line breaks, or trailing punctuation added when copying it, then look for a specific error in the update log. A 401 or 403 usually points to authentication, permissions, or access restrictions; a 404 may mean the URL has changed. If you get a webpage instead of configuration data, ask the provider for the correct subscription endpoint. For connection timeouts, check your internet connection and how update requests are routed. If the log reports a configuration parsing error, make sure the subscription format is compatible with your client and core. Don’t keep importing the same broken URL or submit a private subscription to an unknown conversion site. If credentials are exposed, reset the subscription URL with your provider.

Turn off TUN and confirm that a regular proxy connection works, then check the logs for errors creating a service, virtual network adapter, or route. Windows desktop clients may require their service mode to be installed or repaired; follow the client’s instructions. On macOS, approve the requested network extension or VPN permission. On Linux, make sure you have permission to create a TUN interface and modify routes. Android usually prompts you to authorize a VPN connection; confirm the request comes from the client you’re using. An existing VPN, old virtual adapter, or security software may also cause conflicts. Change one setting at a time and retry instead of running the client as an administrator indefinitely.

Some Windows apps isolated in app containers can’t access a local loopback proxy directly. That may explain why a browser works while a Store app doesn’t, but not all Store apps are affected. First check whether the app uses the system proxy and whether the client logs its connections. If loopback restrictions are the cause, use the client’s UWP loopback exemption tool to authorize only the apps that need it. This usually requires administrator permissions. Restart the affected app and test again. If it still fails, check the app’s network settings, DNS, and rules; you can also test TUN if supported. Don’t grant access to every app by default.

For everyday use, start with Rule mode, which routes connections according to the configuration’s rules. Global mode applies the selected global policy; the actual route depends on the policy currently chosen. It can help you briefly check whether a problem is related to routing, but it doesn’t automatically select a particular proxy server. Direct mode generally connects to destinations without using a proxy. After switching modes, new connections use the new policy, but existing long-lived connections may stay open. Reopen the app you’re testing or close affected connections once you understand the impact. Modes with the same name may appear in different places across clients, so check both the mode and the selected policy group when troubleshooting.

Use the client’s override, merge, or persistent rule features where possible. Direct edits to subscription-generated files may be overwritten the next time the subscription updates. Rules are usually matched from top to bottom, so put specific domain rules before broader rules that could match first. The catch-all MATCH rule generally goes last. After adding a rule, check YAML indentation, rule type, policy group name and capitalization, and make sure you’ve reloaded the active configuration. Domain rules also depend on whether the client can identify the connection’s domain; results may differ if only the destination IP is visible. Check connection logs for the matched rule and actual route—it’s more reliable than repeatedly refreshing a webpage.

Treat launching the client, starting the proxy core, and enabling the system proxy as three separate steps. Check which options your client supports. First save a working configuration while starting the client manually, then enable launch at login and check for duplicate startup entries. If your connection briefly stops working after login, the system proxy may be set before the core is ready, or a subscription update may start before the network is available. If supported, add a startup delay, avoid launching multiple networking tools at once, and check the startup logs. Don’t put a private subscription URL in a public script. Before disabling auto-start or uninstalling, exit the client normally and turn off the system proxy to avoid leaving a proxy setting pointed at a closed local port.

A latency test usually measures how long one request takes to reach a test address. It doesn’t measure sustained download speed or reflect how every website performs. The destination’s location, server load, network congestion, packet loss, and selected policy group all affect real-world speed. Confirm that the webpage is using the same route you tested, then compare the same destination on the same network at roughly the same time. Avoid running multiple speed tests at once. If only one site is slow, check its matched rule, DNS results, and service status. If everything is slow, compare another route or network connection. Don’t change a lot of DNS and TUN settings based on a single latency result.

Turn off the proxy and confirm your internet connection can reach ordinary services. Then check that the subscription updated successfully, authentication is still valid, and your system clock is correct. Test with an actual webpage request and connection logs. If webpages work but latency tests time out, the test address may simply be unreachable or unsuitable for your route; that doesn’t mean all nodes are down. If real requests fail too, note the specific error, such as a timeout, authentication error, or TLS error, then try another route and another network connection. If every route fails, check the subscription status, local firewall, and network environment first. Change one factor at a time and keep the error details to share with your provider.

First confirm that the core is running and that the system proxy address and port match the values it’s actually listening on. Don’t assume a port from another guide applies to your setup. Then check the connection list to see whether the target app’s requests reach the client. Browser extensions, separate proxy settings, and environment variables used by some command-line tools can override the system proxy. Some apps don’t use system proxy settings at all. Try a one-off test with a tool that supports an explicit proxy, then decide whether to configure the app separately or enable TUN. If your network still has issues after closing the client, check for a leftover local proxy address in the system settings. Remove outdated proxy environment variables and restart your terminal.

First decide which domains should be resolved over which route. Then check whether DNS is handled by the client, operating system, browser Secure DNS, or another VPN. A test site’s reported resolver location is only a clue, not proof of a leak; use the configuration, logs, and, if needed, a packet capture to see where queries actually go. Fake-IP returns mapped addresses to help the core associate domains with connections. It isn’t the same as encrypted DNS, and it isn’t required for every setup. If it causes local device discovery or app compatibility issues, configure exceptions as documented. After changing the DNS mode, clear relevant caches and restart the app, then repeat the same test to avoid mistaking cached results for new ones.

Turn off TUN and the system proxy in the client, exit normally, and check whether your internet connection recovers. If the client crashed, look for leftover system proxy settings or a service that’s still running. Make sure only one VPN or traffic-routing tool is active, then check for conflicts involving DNS, routes, or virtual adapters. When you reopen the client, test system proxy first. If it works, enable TUN separately and check the logs for interface creation, route setup, and DNS changes. If your connection is still down, reconnect to the network or restart your device and test again. Don’t start by deleting every network adapter, clearing all routes, or running network reset commands from unknown sources; these actions can disrupt remote access and other work networks.