Clash FAQ

The client provides subscription management, policy selection, logs, and system network settings. The core parses configuration, matches rules, and establishes connections. Clash Meta is a Clash-derived core that continued development under the name mihomo. Different clients may bundle different cores or let you replace them, so similar interfaces do not guarantee the same protocol or field support. If a configuration is incompatible, check the About page or core information to identify the core actually in use, then consult its documentation rather than relying on the client name alone.

The client manages configuration and connections; installing it does not provide a working remote proxy service. A subscription or local configuration must include the necessary proxy nodes, policy groups, and rules, and the remote service must be available. Before importing, make sure the source is trusted, the current core supports the protocols, and you understand the service's terms of use. A subscription containing only a node list may not be a complete Clash configuration. The client may need to merge it with a configuration template, depending on the import option and supported format.

Rule mode applies policies in the order defined by the configuration and is suited to everyday traffic routing. Global mode sends connections captured by the core through a single global policy, making it useful for temporary comparison tests. Direct mode lets captured connections reach their destinations without a remote node, helping rule out node-related issues. These modes only control how traffic is handled after it reaches the core; they do not determine which apps' traffic gets captured. If Global mode still does not capture an app, check the system proxy or TUN instead of repeatedly changing rules.

They capture traffic at different points. The system proxy uses OS proxy settings to direct apps that honor them; some command-line tools, games, and apps with their own network stacks may ignore those settings. TUN captures matching traffic through a virtual network adapter and routes, and also involves permissions, DNS, and coordination with other VPNs. If a browser works but another app does not, first check whether that app supports an explicit proxy, then consider TUN. Most issues do not require enabling both methods at once.

Matching protocol names is only a starting point. Check the transport, TLS, authentication, and any extra parameters too. For example, different VLESS transport combinations and Hysteria2 bandwidth settings may depend on core support or the client's import implementation. Share links, Clash YAML, and other clients' configuration formats are not interchangeable. Prefer a format explicitly supported by the service provider, then verify the node type and key parameters after import. Do not remove authentication or security fields just to silence an error.

Add a remote configuration from the client's configuration or subscription page, paste the complete URL, and save it. Wait for the download and parsing to finish, then set that configuration as active. Open the policy groups, select a working node, enable the system proxy or TUN if needed, and check the connection log. Button names vary by client, but a successful download, an active configuration, and traffic capture are three separate steps. Subscription URLs may contain credentials, so do not share them in public screenshots, online converters, or discussion forums.

Start with the update log and distinguish DNS resolution failures, connection timeouts, HTTP status errors, and configuration parsing failures. For a 401 or 403 response, check your account and URL authorization; for a 404, confirm whether the address has changed. If the request succeeds but parsing fails, the download may be a login page, an error message, or an unsupported format. If the client offers the option, try updating directly or through an existing proxy so a failed node does not interfere. Avoid rapid repeated retries, and never post the full subscription URL publicly.

Keep a copy of the original configuration and check the first error reported in the log. Unsupported fields usually mean you need to check core capabilities and configuration format. If a policy group is missing, verify that rule targets, group names, and node names match exactly, including capitalization and spaces. YAML indentation must use spaces, with list levels correctly aligned. If the configuration comes from a subscription, update its template or use the client's override settings so manual changes are not lost on the next update. Change one thing at a time, then run the client's configuration check.

TUN uses a virtual network adapter and system routes, so it typically needs elevated permissions. If the desktop client provides a service mode or privileged helper, authorize it through the installation process and let the service perform operations that require elevation. Running the entire interface as administrator all the time should not be the default. If TUN still fails after installing the service, check that the service is running, the virtual adapter was created, and security software is not blocking it. On mobile, you must allow the system VPN configuration; without that permission, traffic capture cannot be set up.

mixed-port is the listening port for both HTTP and SOCKS proxy connections. Set an app's proxy address to the actual listening address and port, not the control interface port. If you only use it on the same device, listening on the loopback address is sufficient. For LAN access, check allow-lan, the bind address, the system firewall, and authentication, and restrict access to trusted networks. Never expose the proxy listener or control interface directly to the public internet. If you change the port, update any explicit proxy settings in your apps as well.

Select a specific node, then start a new connection to a destination. In the client's connection list, check the destination domain, matched rule, policy group, and node actually used. If necessary, close and reopen the app to clear old connections, which may continue using the previous route. Checking your public IP can help, but a browser icon, the system proxy toggle, or a successful node test alone is not conclusive. If the app uses another proxy or VPN, rule out overlapping routes first; otherwise, your test may be checking a different connection.

Rules are usually evaluated from top to bottom, and the first match determines the policy. Put specific custom rules before broader rules that could match first, and make sure the target policy group exists. For subscription configurations, use the client's override or rule-merging feature instead of editing a generated file that may be replaced during an update. Confirm the active configuration has been reloaded, then check the rule log for a new connection. If an app connects by IP and the core has no domain information, domain rules may not match; investigate DNS and the traffic-identification method as well.

Fake-IP is a virtual address assigned by the core to preserve the association between a domain and its connection; it is not the destination server's real public IP address. After an app receives this address, the core should capture its subsequent connection. Some LAN discovery, device-management, or real-DNS-dependent apps may need exceptions. Add filters for specific domains or adjust their DNS path instead of excluding all domains at once. After changing DNS mode, restart the app and clear relevant caches so old mappings do not affect your diagnosis.

Automatic updates typically refresh remote configurations or proxy-provider data. Whether policy selections are retained depends on the client's persistence behavior and whether policy group names remain stable. Changes made directly to a remote configuration file are likely to be replaced on the next download. Put persistent rules and DNS changes in a client-supported override layer, then check the effective configuration after an update. Updating the full configuration and updating proxy-providers are different operations; before scheduling updates, confirm which update option the client provides.

Command-line tools do not necessarily use the desktop system proxy. Check the tool's documentation and use a supported proxy option, dedicated configuration, or environment variable, pointing it to the local address and port the client actually listens on. Support for HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, and uppercase or lowercase variants differs between tools, so setting one variable will not necessarily work for every program. When you no longer need the proxy, remove the setting from the relevant terminal session or configuration file. If the client is closed but an explicit proxy setting remains, the tool will keep trying to connect to a local endpoint that no longer exists.

The subscription URL and node servers are different destinations, so a successful subscription update does not prove that a node is working. Check your account, traffic allowance, and service status, then compare with other nodes in the same group. If only one node fails, check that node's service first. If all nodes fail, check your local network, DNS resolution, system clock, and core protocol support. Hysteria2 and TUIC also depend on UDP connectivity. An unreachable test URL can cause a timeout too, so compare real access attempts with the connection log. Do not repeatedly reinstall the client based on a single test result.

First confirm the core is running and the local proxy port is listening, then verify the address and port in the system settings. Check whether a browser extension, enterprise policy, or separate proxy setting is overriding them, and whether the destination is on the proxy bypass list. Next, check the client for a new connection: no entry usually points to a traffic-capture issue, while an entry means you should check the rule, policy, and node. Close other programs that modify proxy settings before testing, so the toggle and the system's actual settings stay in sync.

Some Windows apps isolated in an app container cannot access a local loopback proxy directly, so a loopback exemption may be needed for a specific app. First verify that a regular desktop browser works with the same proxy. Then use the client's UWP loopback tool or a system management tool, selecting only the apps that need it and granting the requested permissions. Not all Store apps use the same network model, so do not assume every connection problem is caused by loopback restrictions. If you switch to TUN, still check routes, DNS, and the app's actual connection log.

Turn off TUN first, then pause other VPNs and similar traffic-capture tools to see whether the basic network connection returns. Enable only one traffic-capture method at a time, and check the default route, DNS settings, and virtual adapter status. If problems persist after closing the client, use its service-stop or network-restore feature and check for manually configured proxy or DNS settings left behind. Do not delete system routes or network adapters in bulk unless you know what they do. Once the basic connection is restored, enable features one at a time and use the logs to find the smallest configuration that triggers the issue.

For a port conflict, check whether another client, an old core process, or a background service is listening on the same address. Do not terminate an unknown system process. Stop duplicate instances, or change the listening port and update the apps' proxy settings. If network access fails only after closing the client, check whether the system proxy was turned off and whether browser extensions or terminal environment variables still point to the local port. TUN users should also confirm that the service and routes exited cleanly. When auto-start is enabled, closing the interface does not necessarily stop the background core, so check them separately.