Clash FAQ

The client handles config imports, interface controls, and system integration. The mihomo core listens on proxy ports, resolves DNS, and applies routing rules. A subscription is the service provider’s way of delivering config or node details. Installing a client does not provide working nodes, and importing a subscription does not mean app traffic is passing through the core. On first use, make sure the config is enabled and a working exit is selected in the proxy group before enabling the system proxy or TUN. Keeping these three layers distinct helps avoid mistaking an expired account for a failed installation, or a system proxy issue for a node outage.

For everyday use, choose rule. The core checks rules from top to bottom and routes each connection according to the matching policy. global sends connections to the GLOBAL policy, but you still need to check which exit that policy selects. direct connects to the destination without a proxy. Global mode does not automatically capture app traffic that never enters the core, nor can it fix an unavailable node. If a site is routed unexpectedly, check the matched rule and final policy in the connection log before changing rules or proxy groups. Switching modes without checking the selected exit can blur the difference between a routing issue and an unavailable node.

The availability, operators, and data handling practices of public nodes are often difficult to verify, so avoid using them for sensitive accounts or important work. HTTPS protects data in properly encrypted connections, but it does not replace checking the client, certificate, and service provider. Subscription links often contain account identifiers or access credentials. Treat them as sensitive: never post them on public forums, include them in screenshots, or enter them into unfamiliar conversion sites. For troubleshooting, share error messages and config fields with credentials removed. If a link has been exposed, reset it through your provider’s account page and update the client config.

You can usually migrate a subscription URL and standard YAML config, but don’t assume every setting from the old client will import as-is. Choose a maintained client that supports the protocols you need, reimport the subscription, and check that the current core accepts its proxy groups, rules, and node protocols. You may need to recreate interface preferences, service installation, scripts, and override logic separately. Before migrating, quit the old client and disable its system proxy and background services. Then launch the new client to avoid port conflicts or repeated changes to proxy settings. Keep a backup of the original config, and remove the old setup only after confirming everything works.

Make sure you copied the full subscription URL, not the account page address, and check for spaces or line breaks. Then review the client’s update log: 401 or 403 usually indicates an authorization or access restriction; 404 may mean the URL has changed. If the request succeeds but the content cannot be parsed, check whether the response is a login page, error page, or unsupported format. An expired account, exhausted data allowance, or a provider changing the URL can also make a subscription unavailable. If updates must go through a proxy, select a working exit when the client supports it. Don’t keep overwriting your local config. Save the last working copy and ask your provider to confirm the subscription URL is still active.

Use the reported line number to check indentation, spaces after colons, and list nesting. Indent with spaces, not tabs. The line number may point to where the error was detected, while the actual problem could be on the previous line. If a node name or password contains special characters, quote it according to YAML syntax. If the syntax is valid but the client reports an unknown field or unsupported proxy type, check which core and version the client is using instead of changing indentation. Work from a copy of the original config, restore recent changes one section at a time, and make only one change before confirming it loads successfully.

mixed-port accepts both HTTP and SOCKS proxy connections on the same port. port is for HTTP proxies, and socks-port is for SOCKS proxies. Configure each app with the proxy protocol it supports; matching port numbers alone don’t make a setup correct. With mixed-port: 7890, apps on the same device usually connect to 127.0.0.1:7890, but use the port in the active config. If you see address already in use, find the process occupying the port, then decide whether to stop the old instance or choose another port. If you change it, update the system proxy, browser extensions, and terminal environment variables too.

TUN creates a virtual network interface and changes routes, so it generally needs the relevant system permissions. However, that does not necessarily mean the entire client must always run as an administrator. Some clients use an installed service for privileged operations; the details depend on the platform and implementation. First check whether the service is installed and running and whether the virtual interface was created. Then review the logs for permission or routing errors. Running another VPN at the same time can cause interface or route conflicts, so temporarily quit the other network client to compare. Don’t leave the firewall disabled to work around a permissions error. Fix the service, authorization, or specific conflict instead.

A speed test usually checks a node’s response to a specific test address; it doesn’t prove that every website, protocol, and port will work. First check whether the failed request reached the core and whether the selected proxy group is actually using the node you tested. Then check the destination domain’s DNS resolution, whether the node can reach that site, and whether the server imposes restrictions. If the speed test result is old, test again and visit the destination yourself. If only video, games, or voice calls fail, also check UDP support and routing rules. Don’t keep switching nodes based only on speed rankings. For a useful comparison, test the same destination under the same network conditions.

Don’t put rules you need to keep in the body of a remote config that gets replaced during updates. Use the client’s override, merge, or extended config features to keep your rules separate from the subscription, and confirm the merge order. Rules usually need to go before the fallback MATCH rule; otherwise, a connection may match earlier. Any referenced proxy group must also exist in the final config. Clients handle array additions, insertions, and replacements differently, so after an update, check the active config rather than just the editor snippet. After setting this up, manually update the subscription once to make sure your changes still apply.

First make sure the two devices can reach each other over your local network. Then enable allow-lan and check that bind-address allows connections from the local network interface. On the other device, enter your computer’s local IP as the proxy address, not 127.0.0.1, and use the current HTTP or mixed listening port. Check that your computer’s firewall allows the port only on trusted networks, and that wireless client isolation is disabled on the access point. Expose the listener only on trusted networks, use proxy authentication if needed, and never forward the proxy port to the public internet. Setting up an HTTP proxy usually won’t route all traffic from the device.

Many command-line tools don’t automatically use the desktop system proxy. You may need to set the tool’s proxy options or environment variables. To test a single request, run curl -x http://127.0.0.1:7890 https://example.com, replacing the port with the active listening port. If it works, set http_proxy, https_proxy, or ALL_PROXY according to your terminal and tool documentation, and check whether no_proxy excludes the destination. Environment variables usually affect only the current process and its child processes, so you may need to restart an open terminal. For HTTPS destinations using a local HTTP proxy, the proxy address can still use the http:// prefix.

If all nodes time out, first confirm your local network can reach regular websites directly. Then check that the subscription updated successfully, the account is active, and the client loaded the correct config. Next, check the system clock, node hostname resolution, port connectivity, and any protocol errors in the logs. Try the same node on another network to distinguish local network restrictions from a server-side problem. If only some nodes time out, compare their server addresses, ports, protocol settings, and service status. Don’t change DNS, TUN, and node settings at the same time, or you won’t know what fixed the problem. Save the error time and logs with credentials removed, then ask your provider to check the affected exit.

Check that the system proxy points to the same address and port the core is listening on, and confirm the core is still running. Then check whether a proxy extension, separate browser proxy setting, or organization policy is overriding it. Temporarily disable conflicting extensions and retry the same URL. The client’s connection log is especially useful: if the connection isn’t listed, check how traffic enters the core; if it appears but uses DIRECT, check the rules and selected policy; if it uses a proxy but still fails, check the node and DNS. Quit other apps that modify the system proxy to prevent them from overriding each other. Find the cause before enabling TUN; it isn’t a default fix for every issue.

Some Windows apps that run in app containers can’t access the local loopback address by default. So even if your browser works, those apps may not be able to use a proxy at 127.0.0.1. First confirm the app actually uses the system proxy. Then use the client’s loopback exemption feature to authorize the specific app, or review the existing exemption list if you know how to use the relevant system tools. This may require administrator permissions, and networking behavior varies by app, so don’t grant access to every app by default. Fully quit and reopen the target app, then check the connection log. If it still fails, check the app’s own service, account status, and routing rules.

Don’t disable DNS to hide the problem. Fake-IP assigns synthetic addresses to domains, and local network services or apps that rely on real IP addresses may need exceptions. First check which DNS server should resolve your local domains. Then use fake-ip-filter and nameserver-policy to exclude those domains or direct their DNS queries to the right resolver. Switching to redir-host alone may not fix routing, caching, or multicast discovery issues. After changing the config, clear the relevant DNS cache, restart affected apps, and check the resolved addresses and connection log. If device discovery uses multicast, also check network isolation and TUN routes; changing DNS alone won’t solve it.