Clash FAQs

Clash refers to a proxy core and its ecosystem. ClashX is a macOS client, while mihomo is a compatible core that continues to be developed. The client handles menus, subscription management, and system integration; the core handles connections, DNS, and rule processing. Bundled cores, maintenance status, and feature locations vary between clients, so the name alone does not tell you whether TUN or a specific protocol is supported. Check the project documentation and core details before choosing a client, then follow that client’s instructions.

A client provides connection and traffic-routing features, but does not include a proxy service. Remote subscriptions typically contain nodes, proxy groups, and rules; you can also maintain a local YAML configuration yourself. Before importing one, make sure its source is trustworthy, the service is active, and its format is compatible with your core. Subscription URL tokens often grant account access, so don’t share screenshots or submit them to public conversion sites. Example URLs on this site only illustrate where to enter a URL and cannot be used to connect.

Rule mode is a good starting point for everyday use: connections follow the rules in your configuration to select an outbound route. Global mode applies the global policy to connections handled by the core, but does not mean every app’s traffic is being captured; system proxy or TUN must still be configured correctly. Direct mode bypasses the proxy and is useful for comparison tests. After switching modes, test with a new connection. Existing long-lived connections may keep using their original route, so refreshing the same page may not give you a reliable result.

A system proxy registers a local proxy address with the operating system and mainly affects apps that follow that setting. TUN captures traffic that matches its routing rules through a virtual network interface. It usually covers more traffic, but depends on permissions, routes, and DNS settings. You don’t have to enable both, and neither guarantees that every type of traffic will be captured. When setting things up, verify the system proxy first, then enable TUN if needed for games, command-line tools, or other apps. This makes it easier to isolate issues instead of changing multiple traffic-capture methods at once.

A latency test only shows that a probe reached a test address through a selected node at a particular time. It doesn’t prove that every website, protocol, or port is reachable. Browsing also depends on the selected proxy group, matched rules, DNS resolution, and restrictions imposed by the destination site. Check the destination domain, matched rule, and actual outbound route in the connection log, then make a new request from the app you’re testing. Don’t choose a node based only on the lowest latency; consistent success across repeated requests is more useful than a single test result.

Add a remote configuration from the client’s Subscription, Configuration, or Profiles page. Paste the full URL, save it, download the configuration, and select it. The menu names vary by client, and saving a URL doesn’t necessarily activate the configuration. If parsing fails, check that the provider outputs Clash-compatible YAML, not a web page, a single node link, or a Base64 string containing only node data. Use the provider’s client-specific option where available. If conversion is necessary, be aware that it can expose your token or rewrite rules.

First make sure the core is running. Check the local listening address and mixed port shown in the client, then confirm that the address and port in Windows proxy settings match. Don’t assume every configuration uses port 7890. Next, check browser extensions, custom proxy settings, and bypass lists that might override system settings. Open a new page and check the client’s connection log. If no new connection appears, investigate traffic capture; if there is a connection, check which rule matched and which outbound route the proxy group selected.

Move the app to the Applications folder, then follow the client’s first-launch instructions. Network extensions, helper services, or Keychain authorization prompts only appear in implementations that use those features; not every ClashX client shows the same prompts. The approval options in System Settings vary by macOS version. Check Privacy & Security and the network-related settings. Before granting permission, confirm the request comes from the app you just installed. If you previously denied permission, follow the project’s instructions to trigger the request again rather than disabling macOS security features.

Turn off TUN first. Confirm that the client supports traffic capture on your operating system, then check whether its service mode, helper service, or network extension is installed and authorized. Windows clients may require a system service; Linux often needs service permissions or network-management capabilities; macOS clients may use an authorized helper or extension, depending on their implementation. Grant only the permissions specified in the project documentation. Repeatedly launching as administrator is not a substitute for troubleshooting. After authorization, enable TUN again and check the interface, routes, and startup logs.

Mobile clients typically capture traffic through the system VPN interface and require system authorization on first connection. Check whether another VPN, ad blocker, or firewall app is already using that capability. Disconnect other VPNs and try again. On Android, check Always-on VPN, Block connections without VPN, and background battery restrictions. On iOS, check existing VPN configurations and on-demand connection settings. First make sure the configuration is enabled and the selected proxy group has an available node, then troubleshoot authorization. This helps avoid mistaking a subscription issue for a system-permission problem.

Choose a suitable update interval in the subscription settings, and check whether the client needs to be running to perform scheduled updates. Updates may be delayed while the device is asleep or offline. Remote configurations are often replaced in full when updated, so edits made directly to their rules may be lost. For persistent customizations, use the client’s override, merge, or rule-extension features where available. Keep a working copy before updating, then check proxy group names and selections afterward, especially if the provider has removed or renamed nodes.

A select group lets you choose an outbound node manually. A url-test group selects a node based on probe results, while fallback checks candidates in the order defined by the configuration. Their behavior depends on the test URL, interval, and candidate list; similar names don’t mean they work the same way. First check which group the rule points to, then see whether that group contains nested proxy groups. For troubleshooting, temporarily pin a verified node to reduce variables from automatic switching. When you’re done, adjust the candidates in your automatic groups for everyday use.

Rules are evaluated in order, and traffic usually follows the first matching rule. Check whether a broad rule or catch-all earlier in the list is matching first. Domain rules depend on the core receiving domain information, while process rules depend on platform support and process detection. Check the actual destination, matched rule, and outbound route in the connection details before editing the relevant rule. A rule’s presence in the configuration doesn’t guarantee that it will match. Save and reload the configuration, then verify with a new connection. For remote configurations, use an override to preserve your changes where possible.

Fake-IP returns a virtual address to an app, which the core later maps back to a domain when the connection is made. It isn’t the real server address. If a LAN device, specific app, or domain lookup has compatibility issues, first confirm that its request reaches the core and check which DNS server it uses. For domains confirmed to be incompatible, add them to fake-ip-filter using the syntax supported by your core, then reload the configuration and clear the relevant DNS cache as directed by the client. Don’t add every domain to the filter list. Back up the configuration and note the current settings before switching DNS modes.

Note when the issue occurred, your OS version, and the client and core versions. Temporarily set the log level high enough to reproduce the issue, usually starting with info. Export only the relevant log lines from around the time of the failure. Before sharing them, check for subscription URLs, tokens, credentials, node addresses, and personal domain names. Don’t post a full configuration file or a screenshot of the entire subscription page. When troubleshooting is complete, restore your usual log level and delete any sensitive copies created for testing to avoid retaining unnecessary browsing details.

Check that the URL is complete and contains no extra spaces, then review the update log. A 401 or 403 often indicates a credentials or access-permission issue; a 404 may mean the URL has changed; and a 429 means requests are being rate-limited. Check with the provider to interpret these statuses. For connection timeouts, check your network, DNS, and the outbound route used to download the subscription. If the response is a login page or error page, the client may report a parsing failure. Avoid repeated update attempts. Check that your service is active, then regenerate or retrieve the URL according to the provider’s instructions.

Close other proxy tools and make sure your internet connection works. Then select one node and test a known destination. Check the failed destination in the logs: if it’s the node server, investigate the node status, DNS resolution, port, and local network restrictions; if it’s the destination site, continue troubleshooting the outbound policy. Try another node and a different network, changing only one thing at a time. A timeout on one node doesn’t mean the entire subscription has expired. Don’t disable your system firewall just to eliminate timeouts.

First reopen the original client, turn off the system proxy and TUN, then quit normally and see whether the network recovers. If the app won’t start, clear any leftover local proxy from your operating system’s proxy settings, and check for manual DNS or VPN configurations. Don’t remove a proxy or DNS setting required by your organization; record the original values if you’re unsure. If you’ve used multiple proxy tools, check each one’s traffic-capture status. If needed, reconnect to the network and clear the DNS cache. Once connectivity is restored, start one client at a time to verify.

Some apps isolated by AppContainer can’t access a local loopback proxy directly, even when a browser works. First confirm that the affected app uses the system proxy. Then use the client’s UWP loopback tool to find the app and grant an exemption only to apps that need access to the local proxy. This may require administrator approval; restart the affected app afterward. Not all Store apps use the same network model. If the problem persists, check the app’s own proxy settings, DNS, and logs instead of granting exemptions to every app.

If a GeoIP update fails, check the download URL, network errors, and file permissions in the logs. Then confirm whether the configuration uses a GeoIP database or another geographic rule data format; these data files aren’t interchangeable. If the log says address already in use, the core couldn’t bind to a local port. Check whether another client or duplicate core is running. Stop the duplicate process, or change the listening port and update the system proxy settings to match. These errors occur at different stages; repeatedly importing the subscription won’t fix either one.