Clash FAQ.

Clash refers to a proxy core and its configuration ecosystem; the original core is no longer maintained. Clash Meta extended the original with additional protocols and routing features, and was later renamed mihomo. GUI clients such as Clash Verge Rev provide subscription management, a system tray, and settings interfaces, while the core typically handles connections. When troubleshooting compatibility, note both the client name and core version—don't rely on whether the window title includes Clash. Older configurations can usually be migrated, but check the target core's documentation for newer protocols, DNS fields, and TUN settings.

For everyday use, choose Rule mode so connections follow the rules in your configuration and are routed directly or through a proxy as appropriate. Global mode sends connections handled by the core to the global policy group, making it useful for briefly checking whether a rule is causing an issue. It does not mean every app on your system is being routed through the core. Direct mode sends core-handled connections straight to their destinations and is useful for comparison tests. After switching modes, check the selected policy in the relevant group—a global group can also select DIRECT. Existing connections may keep their current route, so start a new connection when testing.

The system proxy sets a local proxy address in the desktop environment or operating system settings. It mainly affects apps that read those settings and generally doesn't require a virtual network interface. TUN uses a virtual interface and routes to capture more connections, including traffic from apps that ignore the system proxy, but it usually requires a service component or additional permissions. Neither method guarantees that all traffic will use the proxy; routing, exclusions, and app behavior also matter. Start with the system proxy to confirm that your subscription and nodes work, then enable TUN if needed. This makes it easier to identify problems without changing several things at once.

Subscription links often contain account identifiers or access credentials. Anyone with the link may be able to view node details, so don't post it on forums, in group chats, or in public screenshots. For help, share the client name, core version, error time, and logs with sensitive details redacted. Hide node passwords, subscription URLs, and controller API keys as well. Clients don't provide node accounts; check with your subscription provider about expiry, data limits, or service status. If your link has been exposed, reset it in the provider's account portal and update the subscription in your client.

Open the client's configuration or subscription page and choose the option to add a configuration by URL. Paste the full link from your provider, download it, then select it as the active configuration. Button labels vary between clients; the important distinction is between downloading a configuration and activating it. If the client reports missing fields or a parse error, check that your provider offers a Clash- or mihomo-compatible format—not a sign-in page URL or a format intended for another client. Ask for a compatible format first. If conversion is necessary, find out whether the conversion service can access the full subscription, and don't submit a private link to an untrusted online service.

First, make sure you've installed and started the service component according to the client's instructions. Then check the logs for errors creating a virtual interface or permission denials. Linux typically also needs an available TUN device; check whether /dev/net/tun exists. Containers and restricted virtual environments may not expose the device or grant the required network permissions. Don't run the entire GUI client as an administrator indefinitely or loosen device permissions without a clear reason. Enable TUN once the service is running. If it still fails, note your distribution, package format, and exact error, then check each step in the client's permission setup.

Check that the package matches your Linux distribution and processor architecture. DEB packages are generally for Debian and Ubuntu-based distributions; RPM packages are typically for Fedora and similar distributions. Don't install a package just because its filename includes Linux. Run uname -m to distinguish x86_64 from aarch64. If the app won't start, launch it from a terminal and note any missing dependency or sandbox errors. Portable packages may also depend on system runtime components; check the project's documentation. Don't disable system security features as a first step. Use a package built for your distribution and confirm the available formats on the download page.

Some Windows apps running in an AppContainer are restricted from accessing loopback connections. Even when the system proxy points to a local port, they may not be able to reach the local proxy service. If so, use the client's loopback exemption tool to authorize only the apps that need it; you may need to approve the change as an administrator. Not all Store apps use the same runtime model, and loopback restrictions aren't the cause of every connection failure. Before changing anything, confirm that a regular browser can use the proxy and that the affected app reads the system proxy. If you're using TUN, test again with it enabled rather than granting access to every app by default.

A latency test usually sends a request to a specific test endpoint and measures its response at a particular moment. It doesn't measure sustained download speed or predict how every website will perform. Check whether the test endpoint is comparable to the site you're trying to reach, then test one node on the same site and network. Page load times also depend on DNS, the destination server, packet loss, and connection reuse. Running many speed tests at once can add connection overhead. When choosing a node, look for consistent latency and check real page loads and file transfers instead of chasing the lowest number on the list.

Rules are generally evaluated from top to bottom. First, confirm that the client is in Rule mode, then check the connection log to see which rule and policy group actually matched. Put custom rules before broader rules that might match first, and never after MATCH. Next, check whether the rule matches a domain or an IP address, and whether the core has the domain information it needs. Reload the configuration after editing and start a new connection; existing connections may keep their current route. If subscription updates overwrite your edits, use the client's override or merge feature to save local rules instead of repeatedly editing the downloaded file.

First, distinguish the remote subscription file from the client's local override layer. An update may replace the remote file entirely; use the override layer for changes to ports, rules, and personal policies. Before enabling automatic updates, check whether the client supports merging overrides and whether list fields are appended or replaced. Scheduled updates may not run on time while a laptop is asleep or the client is closed; whether they catch up later depends on the implementation. After an update, check the active configuration, policy selections, and logs to confirm it loaded successfully. When backing up, preserve the relationship between override files and configurations, and store backups containing private subscription URLs securely.

Many command-line tools don't automatically use the desktop system proxy. You may need to set proxy environment variables or configure the tool's own proxy option. First, confirm the local listening address and port in the client. Then temporarily set HTTP_PROXY, HTTPS_PROXY, or the tool-supported ALL_PROXY in your current terminal; don't copy someone else's port. Tools differ in support for variable capitalization, SOCKS, and where DNS resolution happens, so check the tool's documentation. Once it works, consider making the setting persistent. When disabling the proxy, clear old variables and Git-specific settings too, so the terminal doesn't keep trying to use a local port after the client exits.

Note the exact error first, then check your system time, current network, and subscription account status with your provider. A 401 or 403 may indicate an authorization issue, a link problem, or a provider restriction. A 404 could mean the path has changed, but a status code alone doesn't prove the cause. Timeouts and TLS errors call for further checks of the network, certificates, and device clock. If the response is a sign-in page, you're not receiving a configuration file. Check whether the client is configured to fetch subscriptions through the proxy, especially if updates depend on a node that may no longer work. Don't delete your last working configuration. Back it up first, then ask your provider whether the URL needs to be reset.

Turn off the proxy first to check your basic network connection. Then verify that the subscription is valid, the device clock is correct, and the active configuration has actually loaded. Select one node and inspect the connection log to distinguish DNS failures, connection timeouts, handshake failures, and authentication errors; each points to a different fix. If only the latency test times out but websites still load, try a different test endpoint before drawing conclusions. If no nodes connect, try another network and temporarily quit other VPNs or network filtering tools to rule out routing conflicts. A specific error is more useful than repeated reinstalls. Don't change DNS, the TUN stack, and node protocols all at once.

First, make sure the core is running and the local proxy port matches the system settings. Then check the client's connection log to see whether the target app appears. If there's no entry, the app may ignore the system proxy or have its own proxy settings. If an entry appears but uses a direct route, check the matched rule and selected policy. Linux desktop environments, browsers, and terminal tools don't all read proxy settings the same way. If the client exited unexpectedly, the system proxy may still point to a closed port. Turn off the system proxy to restore connectivity, then restart the client. Consider TUN only after confirming that the system proxy doesn't cover the apps you need; don't stack multiple proxy tools at once.

This can point to a DNS resolution issue, but accessing an IP directly and accessing a domain may use different certificates and virtual hosts, so one test isn't conclusive. Use a system DNS lookup tool to see whether the domain resolves, then compare the result with DNS requests and errors in the core logs. Check whether browser secure DNS, encrypted system DNS, and client-side DNS interception are all enabled, and identify the path each one uses. After changing settings, clear relevant caches and reconnect. Be especially cautious about mixing in untrusted settings when using fake-ip. First compare against the client's default DNS configuration, then add custom settings back one at a time.