Clash FAQ

Clash originally referred to a proxy core and its configuration ecosystem. Clash Meta developed as a fork, and continued development under the name mihomo. The desktop client displays subscriptions, proxy groups, and settings; the core handles connections. Similar client names don’t guarantee that their cores support the same configuration fields. If a protocol or configuration isn’t compatible, check the client and core details on the About page, then compare them with your subscription requirements. Don’t choose a configuration based on the name alone.

The client reads configuration and routes traffic, but the installer usually doesn’t include a proxy service. You’ll need a subscription link or configuration file you’re authorized to use. Import it, select a proxy group, then enable the system proxy or TUN as needed. Seeing a configuration name only confirms that it was imported. Also check that the proxy group has available nodes, the configuration is enabled, and the target app’s traffic reaches the client. If your subscription has expired or you’ve used up its data allowance, contact the provider.

Start by choosing your operating system, then check the processor architecture and minimum OS requirements. Consider Clash Plus for Windows, macOS, Android, and iOS, and Clash Verge Rev for Linux. If you’re migrating an existing configuration, make sure the client’s core supports its protocols, rules, and DNS fields. Don’t mix up Apple Silicon and Intel installers; on Android, check whether you need ARM64 or ARM. See the platform lists in the download center for current options, download links, and archived releases.

Rule mode follows the rules in your current configuration to decide whether connections use a proxy or go direct, making it a good default for everyday use. Global mode routes regular connections handled by the core through the global proxy group. It can help with short-term troubleshooting, but you still need to select a working node. Direct mode sends connections handled by the core straight to their destinations; it doesn’t turn off the system proxy or close the client. These modes only affect traffic the client handles. Switching modes won’t change an app’s route if its traffic never reaches the proxy.

Subscription links often contain credentials that identify your account. Don’t post them on forums, in group chats, or in public screenshots. For troubleshooting, share the error message, client and core details, and configuration snippets with sensitive information removed. Redact more than just the subscription URL: check node passwords, authorization headers, and full URLs in logs too. If a link is exposed, reset or revoke it in your provider’s account portal and update it in the client. Deleting chat messages alone won’t stop the old link from working.

Make sure you copied the subscription URL, not an account sign-in or subscription management page. Check for spaces, line breaks, or missing parameters, then review the import result and logs. If the response is a sign-in page, access denied, or empty content, resolve account authorization or network access first. If the format isn’t supported, ask the provider for a Clash configuration compatible with your core. After a successful import, enable the configuration and check that its proxy groups reference the correct nodes or proxy providers.

TUN creates a virtual network interface and adjusts routes, so it usually needs more permissions than the system proxy. On Windows, install the service component as described by your client and confirm it’s running; test once with administrator privileges if needed. On macOS, approve the network extension or helper component when prompted. On Linux, check service permissions and whether the TUN device is available. Repeatedly toggling the setting won’t grant permission. After authorizing it, restart the client and check the logs for successful interface creation and route setup.

In your system network settings, confirm that the proxy points to localhost and uses the port the client is currently listening on. Don’t assume every client uses the same port. Quit other proxy tools and temporarily disable browser extensions that manage proxy settings. Browsers such as Firefox may have separate proxy settings, so check whether they’re set to use the system proxy. Open a new page and check the client’s connection log. If there’s no entry, troubleshoot how traffic is being intercepted; if there is an entry but the connection fails, check the rules, node, and DNS.

Android usually allows only one app at a time to use the system VPN connection. Turn off other VPN apps and any firewall or network filtering tools that use a local VPN, then authorize Clash to connect again. If Always-on VPN or “Block connections without VPN” is enabled, check which apps those settings apply to. Once connected, review the client’s per-app list to make sure the target app isn’t excluded. Don’t clear all your settings to resolve a conflict; keep your subscription and other settings intact.

Back up the configuration first, then check the lines around the line number in the error. YAML uses spaces for indentation; don’t use tabs. Check list items, the space after each colon, and matching quotation marks. The reported line may be where the parser detected the error, while a missing quote could be on the previous line. If the syntax is valid but a field is still reported as unknown, check whether your core supports it. Subscription-generated configurations are often overwritten on update, so use the client’s override or merge feature for lasting changes.

Open the client’s connection log, then make a new network request from the target app. Check the destination domain, matched rule, and selected proxy chain. Existing long-lived connections may keep using their old route, so reconnect after changing settings. An IP address shown on a website doesn’t explain every routing decision; in Rule mode, different sites may take different routes. If there’s no log entry, check whether the app follows the system proxy or is excluded by TUN’s per-app settings. Don’t rely on the color of a toggle to confirm that traffic is being intercepted.

You don’t have to enable both. The system proxy works well with browsers and common apps that follow system proxy settings. TUN can handle more apps that don’t use a proxy themselves, but requires route, DNS, and permission settings. When troubleshooting, start with just one traffic interception method and confirm it works before combining methods as your client’s documentation recommends. Enabling both doesn’t make connections faster or fix a failed node. If TUN causes problems, check the interface, routes, and DNS logs instead of adding more proxy tools.

Find the automatic update interval in the subscription or configuration settings and set it as needed. Check whether updates run only while the client is open or through a background service. After changing the subscription URL, refresh it manually once and check the update time and any errors. Save custom rules, proxy group changes, and DNS settings with the client’s override or merge feature rather than editing the downloaded subscription content. After an update, confirm the active configuration. If a node was removed, select another one in the proxy group.

Connect your computer and phone to a trusted local network where they can reach each other. Enable Allow LAN in the client and confirm its listen address accepts LAN requests. In the phone’s Wi-Fi settings, enter the computer’s LAN IP address as the manual proxy server and the client’s actual HTTP or mixed port—not the phone’s loopback address. Allow access through the computer’s firewall only for the local subnets that need it; never expose the proxy port to the public internet. A manual HTTP proxy won’t cover every phone app, so check whether each app uses the setting.

GeoIP data matches rules based on an IP address’s geographic location. A failed update can make location-based matches inaccurate, but it won’t disable all domain rules. Check the logs to confirm the data file path and update URL are accessible. Then check whether your configuration uses MMDB or another geographic data format and whether the corresponding file exists. Don’t rename files to swap between formats. After updating, reload the configuration or restart the core as your client requires, then use the connection log to verify that the relevant rules match.

First determine whether the download failed or the content couldn’t be parsed. For download failures, check whether the subscription expired or its URL was reset, whether your system clock is correct, and whether your network can reach the subscription service. For parsing failures, check whether the response is actually a web page or error message, then verify the configuration format and core compatibility. Don’t refresh repeatedly at short intervals; some services limit request rates. If the old configuration still works, keep it and pause overwriting it. When contacting the provider, include the status code and a redacted error message, not the full subscription URL.

A timeout for every node doesn’t necessarily mean the subscription is broken. The test URL may be unreachable, local DNS may be failing, a firewall may be blocking connections, or the node service may be down. First confirm that the device can access the internet without a proxy, then try reaching a real destination through one node and check the connection log. A test only probes a specific URL; it can’t replace a real request. If switching to a trusted network fixes the issue, check restrictions on the original network. If only one node fails, test another and tell the provider which node failed and when.

Turn off the system proxy and TUN in the client, then quit it. Check that your system network settings don’t still point to a local proxy. Once basic connectivity is back, restart the client, enable just one traffic interception method, and select a known working node. Check whether the failure occurs during DNS resolution, node connection, or rule matching; briefly switch to Global mode to compare if needed. If the internet still doesn’t work after quitting the client, check system DNS, routes, and other VPN settings. Don’t change multiple network settings before identifying the cause.

Some Windows apps that use the AppContainer sandbox can’t access a local loopback proxy by default. That can explain why a browser works while an app can’t connect. First confirm the app uses the local proxy, then use your client’s UWP loopback utility to grant loopback access only to the apps that need it. This may require administrator privileges. Not all Store apps have the same restriction; don’t guess a package name if an app isn’t listed. You can also assess TUN mode using the client’s documentation and verify the result in the connection log.

Check the logs for DNS timeouts, lookup failures, or resolver connection errors. Then confirm that your configured DNS upstream is reachable over the expected route. A valid encrypted DNS address doesn’t guarantee that it’s reachable from your current network; its hostname may also need a bootstrap lookup. If you use fake-ip, confirm that the client handles the relevant traffic and check for conflicts with other DNS tools. After changing DNS, reconnect and clear the system cache if needed. Don’t replace all DNS settings at once. Keep a rollback option and test resolution and actual access one change at a time.