Clash FAQ

Clash is a common name for the proxy core and its configuration ecosystem. Clash Meta was a name used by a related fork, which later continued development as mihomo. Clients provide graphical features such as importing configurations, setting the system proxy, and viewing connections. To determine whether a feature is supported, check the core and version bundled with the client—not just the app’s name. Compare fields in older guides with the current core documentation to avoid mixing configurations for different cores.

The client loads a configuration and runs the core; installing it does not automatically provide a working remote proxy service. A subscription typically supplies proxy connection details, proxy groups, and rules. You can also configure these manually. First make sure the configuration comes from a trusted source, then check that it loaded successfully and that proxy groups have available options. Subscription URLs often contain access credentials, so never post them in public comments, screenshots, or online conversion tools. When troubleshooting, share only error details with sensitive information removed.

Rule mode routes connections handled by the core according to the order of the rules, making it a good choice for everyday traffic routing. Global mode sends those connections through the global policy, which is useful for temporarily comparing a proxy route. Direct mode connects them straight to their destinations. These modes only control how the core handles traffic it receives; they do not change which traffic the system captures. After switching modes, create a new connection and check the connection log. Existing browser connections may continue using their original route.

The system proxy setting directs apps that respect it to a local proxy port. TUN captures traffic through a virtual network interface and routing, including traffic from some apps that ignore the system proxy. For an initial setup, verify the system proxy first, then enable TUN if needed; there’s no need to turn on both at once. TUN coverage still depends on routes, exclusions, permissions, and platform limitations. The toggle alone doesn’t prove that every app’s traffic is reaching the core.

An import succeeding doesn’t mean every field will work. Mobile clients may support different subscription formats, rule syntax, extra fields, and traffic capture methods than desktop clients. Before choosing a client, check which configuration formats it supports, then review import messages and connection logs. Find Clash Plus in the iOS section of the downloads page to open its App Store listing; its website is clashplus.io. Desktop service installation and system proxy steps don’t apply to iOS.

First check the device’s date and time, network connection, and subscription account status. Then make sure the URL was copied in full and doesn’t contain extra spaces, line breaks, or expired access parameters. Note the HTTP status code reported by the client: 401 and 403 often indicate authorization or access restrictions, while 404 may mean the URL has changed. A timeout calls for checking the network path. If the client lets you choose a proxy for subscription updates, test both direct and proxied access. Don’t repeatedly delete an older configuration that still works, and never share the full subscription URL.

Start with the line number and field name in the error, then check the indentation, colons, and list markers on that line and in the section above it. YAML indentation must use spaces; full-width colons and tabs can cause parsing failures. If the syntax is valid but the core still refuses to load the file, check that referenced policies exist and that the current core supports the fields in question. Keep the original file and undo recent changes one section at a time in a copy. Don’t submit a full configuration containing subscription credentials or proxy passwords to a public online validator.

mixed-port accepts both HTTP and SOCKS proxy connections on the same port. 7890 is a common value, not a required port for every client. After changing it, reload the configuration and confirm that the core is listening on the new port. Then update the system proxy, browser extensions, and command-line environment variables. If you use client overrides, check whether they override the port in your subscription. Changing the configuration but leaving the old system port in place can leave the client running while apps fail to connect.

Check the logs to distinguish insufficient permissions from virtual interface creation or route update failures. On Windows, the client may need a background service installed and running, or administrator privileges as described in its documentation. On macOS, approve the required network permissions. On Linux, check access to the TUN device and network management permissions. Service mode is a way for GUI clients to run; it isn’t a standard YAML field. After granting permissions or installing the service, restart the core and check the virtual interface and routes. Avoid running unrelated programs with elevated privileges long term.

Don’t put long-term rules in a cache file that subscription updates replace. Prefer the client’s override, merge, or scripting features to keep your custom rules and DNS settings separate. First check how the client merges configurations: lists may be replaced or appended, and rule order may change. After updating, inspect the final effective configuration rather than just the local file in your editor. Back up override files before upgrading the client, and note any dependencies on proxy group names.

Use select to choose an outbound manually. url-test picks a member based on results from a specified test URL. fallback typically selects an available member in order. Automated tests only reflect the test target and conditions at the time; they don’t represent every site or protocol. You can put an automatic group inside a select group to keep a manual override available. When troubleshooting, pin a confirmed working member and create a new connection so automatic switching doesn’t mix results from different routes in the same test.

Open the client’s connection list, revisit the website, then filter by domain or process to see the matched rule, target policy, and actual outbound route. Rules are generally checked from top to bottom, and the first match wins. Put new rules before broader rules that would otherwise catch the traffic first. If you see only an IP address and no domain, check the DNS path and sniffing settings. After making changes, close the site’s existing connections and test again. A page loading successfully doesn’t prove that the intended rule matched.

With Fake-IP enabled, the core can return a mapped address to an app, then use the mapping to recover the domain and route the connection. If your configuration uses fake-ip-range: 198.18.0.1/16, seeing an address in that range doesn’t by itself indicate a problem. What matters is whether the subsequent connection returns to the core that maintains the mapping. If you run into LAN device discovery or app compatibility issues, use fake-ip-filter for the specific domains that need it. Don’t disable DNS entirely just because you see a mapped address.

First make sure both devices are on a network that allows them to communicate. Then check allow-lan, the listening address, and the host firewall. On the other device, set the proxy server to the LAN IP of the computer running the client—not 127.0.0.1—and use the actual mixed-port. Limit access to a trusted LAN and configure authentication if needed. Don’t expose the proxy port to the internet through router port forwarding. A changing host IP, guest network isolation, or wireless client isolation can also prevent connections.

Choose a target to test, clear its existing connections, then check whether the request appears in the client’s connection list and follows the expected route. To rule out browser settings, run curl -I -x http://127.0.0.1:7890 https://example.com in a terminal to test an explicit HTTP proxy; replace the port with the one you actually use. This command checks only the proxy path for that request. It doesn’t confirm that the system proxy, UDP, or every app is being captured correctly.

Compare the results across several members and different networks. If only one member fails, check its connection details, service status, and protocol support. If they all fail, start with the device time, network connectivity, DNS, and whether the configuration loaded. Also check whether the test URL is reachable; a failing test endpoint can cause every test to time out. A successful probe doesn’t guarantee real traffic will work, and a failed probe alone doesn’t prove the service is down. Check real requests and logs for handshake, DNS resolution, or connection errors.

First confirm that the system proxy points to the same address and port the core is listening on. Then check browser extensions, proxy bypass lists, and other proxy apps that may have changed the settings. Terminal programs don’t always use the operating system proxy; you may need to set HTTP_PROXY or HTTPS_PROXY separately, or pass an explicit proxy option to the program. Compare a request using an explicit proxy with a regular request, and check the connection log. If the explicit proxy works but regular requests never reach the core, focus on how the app reads proxy settings instead of repeatedly changing nodes.

First confirm the request reaches the core, then check the logs for resolution failures, DNS query timeouts, or upstream connection errors. Make sure the nameserver is reachable. With encrypted DNS, also check the bootstrap path used to resolve the DNS server’s hostname. For TUN, check whether dns-hijack or the app’s built-in secure DNS is changing the expected path. Change one thing at a time, reload the configuration, and clear the system DNS cache or reconnect as needed. Don’t replace every DNS field at once, or it’ll be difficult to identify the cause.

Some apps that use AppContainer are subject to loopback restrictions and can’t connect to a local proxy like regular desktop apps. First confirm that the app is affected, then use the client’s loopback exemption feature if available, granting access only to apps that need it. You can also run CheckNetIsolation LoopbackExempt -s in an administrator terminal to check existing exemptions, then follow the Windows documentation to configure a specific package. Don’t exempt every app. Restart the target app afterward and confirm the request path in the connection list.

Check whether the system proxy still points to a local port that has stopped listening. Clear the stale setting, or restart the client and exit normally. If you use TUN, check whether the background service, virtual interface, and routes have been restored. Avoid stopping several network programs at once, which makes it harder to identify the cause. If needed, restore automatic DNS in the operating system’s settings and reconnect. Don’t delete unknown network adapters or clear all routes. Keep the settings and logs from before and after the issue, then re-enable related features one at a time once connectivity is restored.