Clash FAQ

The client handles interface tasks such as importing configurations, selecting policies, and setting the system proxy. The core handles connections, DNS resolution, and rule matching. Clash Meta was a former name for a related core project; mihomo is its successor. References to Meta in older guides do not necessarily mean a standalone client. Clients may bundle different core versions and manage configurations differently, so note both the client name and core version when troubleshooting. Similar-looking interfaces do not guarantee that the same configuration fields are supported.

Installing a client gives you a tool for handling traffic, but you still need a working proxy configuration or subscription and a network that can reach the relevant servers. After importing a configuration, check that it includes proxy nodes and policy groups, test a node, then enable the system proxy or TUN if needed. A “running” status only means the core has started—it does not confirm that the subscription is valid, nodes are reachable, or websites will load. Check each separately.

For everyday use, start with Rule mode, which routes connections according to the rules in your configuration. Global mode sends connections received by the core through the global policy. It can help with brief comparisons while troubleshooting, but it does not automatically capture traffic from every app. Direct mode is mainly useful for checking whether your local network works. After switching modes, test with a new connection; existing long-lived connections may keep using the previous policy. If Global mode works, that points to rules or groups worth checking, but does not identify the cause by itself.

An existing installation may still work, but an archived client will not receive ongoing compatibility fixes or security updates and may not recognize newer configuration fields or protocols. Before migrating, back up your subscription sources, policy selections, and local rules, then import them one at a time into a maintained client. Don’t overwrite the entire old program folder or run two clients that both manage network traffic. First verify the system proxy and a basic connection, then restore TUN, overrides, and other custom settings.

Subscription URLs often contain access credentials. Anyone with the complete link may be able to view node details or use resources from the associated service. Before sharing screenshots or logs, redact subscription paths, query parameters, node passwords, and controller secrets—not just account names. For subscription conversion, use a format provided by your service or process the link in a trusted local environment. Giving it to an unfamiliar converter site is like handing over access to your configuration. If a link is exposed, reset it in your provider’s dashboard; deleting a public post is not enough.

Check your plan, expiration date, and remaining data, then copy the complete link again from your provider’s dashboard. Make sure it hasn’t been truncated and contains no extra spaces or line breaks. Identify the error: a timeout, access denied, or configuration parse failure. Access denied usually points to an authorization issue; an HTML response may be a login or error page. If the link is only reachable through a proxy, update it over a working connection or use an alternative provided by your service. Avoid repeated rapid requests, which may trigger rate limits.

Check your processor architecture and OS version in system information before choosing a download. x64 or AMD64 is common for Intel and AMD desktop processors; ARM64 is for compatible ARM devices. On macOS, distinguish Apple Silicon from Intel. If the installer reports an unsupported format, verify the platform and architecture instead of repeatedly changing the file extension. Minimum OS versions, dependencies, and service installation requirements vary by client; follow the download page and installer instructions.

Turn off TUN first and confirm that a basic connection works through the system proxy. Then follow the client’s instructions to install service mode or grant the permissions needed to create a virtual network adapter. Windows may require administrator approval; Linux may need service permissions or network capabilities; mobile devices usually require approval for a system VPN request. After granting access, check that the service is running and review the specific error in the core log. Don’t bypass organization-managed device policies or run unrelated apps with elevated privileges as a substitute for proper service setup.

mixed-port accepts HTTP and SOCKS proxy connections; external-controller is used by the management interface. They serve different purposes. When configuring a browser or terminal, use the active mixed port—not the controller port. Check the listening address and port in the client, then enter the same values in the app. For local use only, prefer a loopback address. After changing the settings, reload the configuration in the core and update any apps with manually configured proxy settings so they don’t keep using the old port.

Subscription updates usually replace the downloaded configuration with the latest remote version, so direct edits can be overwritten on refresh. Use the client’s override, merge, or local rule features to keep your changes separate from the subscription. Available fields and merge order vary by client. After saving, check the effective configuration that’s running—not just the editor contents. Start with an easy-to-verify rule, confirm its position and target policy, then move over the rest of your settings. Keep a backup you can restore.

A latency test usually measures the time for one request to a specific test endpoint; it does not measure sustained bandwidth. Real-world speeds also depend on network congestion, server load, limits at the destination, and your local Wi-Fi. Compare nodes at roughly the same time against the same destination, checking both page response and sustained transfers. Avoid running multiple speed tests at once. If only one site is slow, check which rule it matches and how the connection is routed. A node’s lowest ping doesn’t make it the best choice for every task.

Open the client’s connections list or logs, revisit the site, filter for new connections by domain, and check the matched rule, policy group, and final outbound. Rules are generally evaluated from top to bottom, so a broad rule near the top may match before a more specific one below it. After making changes, close the relevant old connection or restart the test app to avoid reusing an existing connection. A page may request resources from several domains; if the main site loads but images do not, check the rules matched by its static assets and login endpoints too.

Some clients support both, but when setting things up, test one traffic-capture method at a time. The system proxy mainly affects apps that honor the OS proxy settings. TUN uses a virtual network adapter and routes to capture eligible traffic; the two are not interchangeable. If you use both, check for conflicts involving routes, DNS interception, and other VPNs that could create forwarding loops. Note your original settings and test each method on its own first. If something breaks, revert to the single method you’ve already verified rather than changing several switches at once.

Before updating, note your current configuration name, policy group selections, and local overrides, and back up any files you need to keep. Subscription updates and rule-set updates do different things: the former may replace nodes or policy groups, while the latter mainly changes matching data. After updating, confirm the configuration loaded, then test commonly used sites and local services. If a node has been renamed, its previous policy selection may not carry over. Set automatic update intervals according to your provider’s recommendations; there’s no need to update too frequently. If something goes wrong, keep the error and update time before deciding whether to restore a backup.

An exit IP shows where a particular connection went out; it doesn’t prove that DNS queries took the same route. Check the DNS services, upstream resolvers, and routing settings in the active configuration. Also check whether browser Secure DNS, encrypted DNS in the OS, or another VPN is using a separate DNS path. The resolver location reported by a test site may not reflect the actual query route, so use logs and, if needed, packet captures. After changing settings, clear the relevant caches and open a new connection so old DNS results don’t look like a current configuration problem.

Turn off the proxy first and confirm that your basic internet connection works. Then check whether the subscription has expired, nodes have loaded, and the system clock is accurate. Manually test a few nodes and check the logs to see whether the issue is DNS resolution, a refused connection, or a handshake timeout. If only the default test endpoint is unreachable, a test timeout doesn’t necessarily mean every destination is inaccessible; verify with actual websites. If all nodes fail on multiple networks, ask your provider to check their status. Avoid changing DNS, rules, and ports all at once, which makes the results harder to interpret.

Check that the system proxy address matches the port the client is actually listening on, and confirm that the core is running. Then check whether the browser has its own proxy extension, manual settings, or organization policies enabled. Look for a new connection while visiting a site: if none appears, first check whether traffic is reaching the client; if one does, check the matched policy and node. Terminals, games, and other apps may ignore the system proxy and need separate settings or TUN. Troubleshoot with only one proxy tool enabled so other software doesn’t keep overriding the system settings.

Some UWP apps are subject to app-container loopback restrictions and may not be able to connect to a proxy listening on a local loopback address. First confirm that a regular browser works and that the app actually uses this proxy route. Then follow the client’s documentation to grant loopback exemption to that specific app; administrator permissions may be required. Don’t grant exemptions to every app or assume the cause is the same just because an app came from the Store. If the app doesn’t use the system proxy at all, check its networking behavior or, if permitted, compare results with TUN enabled.

First identify whether the conflict is with the mixed proxy port or the controller port. On Windows, use netstat -ano to find listeners and process IDs; on Linux, use ss -lntp. You may need extra permissions to see process details. Once you identify what’s using the port, close a duplicate client or choose an unused port for the current configuration. Don’t terminate an unfamiliar system process. Reload the configuration after changing the port and update the app’s proxy address. If the conflict returns on every launch, check whether an old service or startup item is still running in the background.

While connected, check the subscription, node, mode, traffic capture, and DNS in that order. Use the connection log to tell whether a request never reached the core or failed after it arrived. If you lose internet after closing the client, first check whether the system proxy still points to a local port that is no longer running, or whether TUN or another VPN has left routes behind. Turn off the proxy and TUN normally through the client, then check your system network settings and restart relevant apps if needed. Keep the logs before resetting anything; clearing all settings at the outset can erase clues to a problem you could otherwise identify.