Clash FAQ

The client provides the interface for importing configurations, selecting nodes, and managing the system proxy. Cores such as mihomo handle connections, apply rules, and resolve DNS. Your service provider supplies nodes or a complete configuration through a subscription. Installing a client does not automatically give you usable nodes. When troubleshooting, first identify which layer is failing: if the interface will not start, check the client and operating system; if the configuration will not load, check the subscription format; if the configuration loads but connections fail, check the nodes, proxy groups, and network. Different cores may support different protocols and configuration fields, so a file extension alone cannot confirm compatibility.

For everyday use, choose Rule mode so connections are assigned to proxy groups according to the matching order in your configuration. Global mode generally sends connections entering the core through the global policy; it does not mean every app is being routed through the proxy. Direct mode sends connections entering the core straight out. If a particular site is having trouble, temporarily switch to Global and select a node you know works to see whether a routing rule is the cause, then switch back to Rule mode. Changing modes does not replace the system proxy or TUN, and cannot fix an expired subscription, unavailable nodes, or server-side restrictions.

The system proxy registers a proxy address with the operating system. It usually works for browsers and apps that use that setting, but may not affect programs that connect directly or ignore the system proxy. TUN routes traffic through a virtual network interface; its coverage depends on the client, platform permissions, and routing configuration, and it often handles DNS as well. Start by testing basic connectivity with the system proxy. Consider TUN only if an app is not being routed. Before enabling it, turn off other VPNs and note your current network settings. If you lose connectivity, turn off TUN first and confirm your normal connection is back before making further changes.

A subscription link opening successfully does not guarantee its contents are compatible with your core. A complete Clash YAML configuration, a node-only list, and subscription formats for other clients are not interchangeable. Choose a subscription option for Clash or mihomo on your provider’s site, then import it using the client’s remote configuration feature. If you see an unsupported protocol or unknown field, check the core’s requirements rather than deleting configuration entries at random. Subscription URLs often contain access credentials; don’t submit them to untrusted conversion sites or post them publicly when asking for help.

First, make sure your service account is still active. Then copy the full subscription URL again from your provider’s site, taking care not to omit parameters or include spaces. Check the update log: 401 or 403 may indicate expired authorization or access restrictions, 404 may mean the URL has changed, and a timeout may point to your network or the route used for the update request. Check with your provider for the exact meaning. Keep your current working configuration and test the update separately instead of clearing everything. If the response is a login or error page, get the correct subscription URL. If it still fails, send your provider the status code and time, with credentials removed from the URL.

A successful import only means the client saved the configuration; it may not be active yet. Select the intended configuration in the config list and make sure the core loaded it without errors, then open the proxy page and check the proxy groups. If you use proxy-providers, confirm the provider fetched nodes successfully and that the proxy group references it with use. Some interfaces show nodes only after you expand a proxy group rather than listing every server separately. Don’t replace a complete configuration with a node-only file. If the list is still empty after an update, check the logs for invalid fields, provider request failures, and subscription service issues.

Follow the client’s instructions to install or repair service mode, then enable TUN again. Turning on a switch in the interface may not be enough to create a virtual network adapter or change routes. Windows typically requires administrator permission to install the service; macOS may require approval for a helper tool or network extension; Android requires approval for the system VPN connection request. Follow the steps for your specific client. Make sure the permission request comes from the client you installed, and don’t run privileged commands from unknown sources. If service installation fails, check system security alerts and client logs, and see whether another VPN is using the required capability. Restart the client to verify the fix.

Yes, but first check whether another proxy client is still running on that port. Closing the duplicate instance and trying again usually keeps settings simpler than changing the port. If you do need to change it, choose an unused port in the active configuration or the client’s port settings, save, and reload. 7890 is a common choice, not a requirement. Then update the system proxy, browser extensions, terminal environment variables, and any apps with a manually configured proxy so they use the new port. Don’t enable LAN access just to connect from the same computer, and don’t expose the proxy listener to the public internet.

A latency test usually measures the response time of one test address. It does not measure download bandwidth, video throughput, or how every site will perform. Compare nodes against the same site, at around the same time and on the same network, and avoid background downloads that could skew results. Then check the connection log to confirm traffic is using the selected proxy group. If only certain sites are slow, the cause may be the exit route, restrictions imposed by the destination service, or DNS results. If every node is slow, check your local network first. Too many simultaneous speed tests may trigger server-side limits. Test a few nodes and judge them by actual use, not a single latency number.

First, make sure you changed the proxy group that the connection actually uses. A configuration may route video, downloads, and regular browsing through different groups, so changing the main selection group may not affect them all. A URL-test group may also choose nodes automatically. Open the connections panel, find a new request to the target domain, and check its matching rule, proxy chain, and final outbound. Existing long-lived connections may continue using the old route; make a new request after switching, or disconnect only the relevant connection if needed. If the client supports local overrides, use one to adjust rules or group references so subscription updates don’t overwrite your changes.

Use the client’s rule overrides, extensions, or persistent merge feature instead of editing a downloaded subscription file directly. For example, add DOMAIN-SUFFIX,example.com,DIRECT for example.com and its subdomains, placing it before any broad rule that would match the traffic first. Clash rules are generally evaluated from top to bottom, and the first match determines the policy. Back up your configuration before editing. After saving, check the configuration load log and verify the result in the connections panel. If the site uses multiple domains to serve content, add rules based on the connections you observe. Avoid routing large numbers of unrelated domains directly for convenience.

At a minimum, note the active configuration, manually selected proxy groups, ports, system proxy settings, and TUN status. Back up local rule overrides and DNS changes. Before updating a subscription, check whether it will replace remote configuration content. Before upgrading the client, read the migration notes and look for changes to the core, service mode, or configuration directory. Change one key setting at a time, then check your usual sites and apps so you can pinpoint the cause if something breaks. Backups may contain subscription credentials or node authentication details, so keep them somewhere secure. Don’t post your entire configuration directory on a public forum; share only the necessary redacted excerpts.

First, make sure the active configuration is loaded and the selected node works. Then check that the proxy address and port recorded by the operating system match the client’s listening address and port. Create a new request in a regular browser and look for it in the connections panel. If it appears but goes direct, check the mode and rules. If it doesn’t appear, check whether the app ignores the system proxy, has its own proxy settings, or is being overridden by another tool. Browser proxy extensions, company policies, and other proxy clients can all affect the result. Terminal programs may not use the system proxy either; configure their environment variables according to the program’s documentation. Consider TUN only if you need broader traffic routing.

Turn off the proxy first and check your basic network connection. Then make sure your subscription hasn’t expired, your system clock is correct, and another known-good node or test destination gives you a point of comparison. A timeout can occur during DNS resolution, the connection to the server, or access to the destination site; use the address in the log to narrow it down. A connection refused error often means nothing is listening on the port, but the remote server may also have rejected the connection, so it doesn’t automatically mean the node is down. If only one route fails, contact your provider. If all routes fail, check your local firewall, other VPNs, and network restrictions. Don’t change DNS, rules, and TUN all at once, or you won’t know which change helped.

Some Windows apps isolated with AppContainer can’t access the local loopback address directly. If your browser works but one of these apps doesn’t, check for loopback restrictions. If your client includes a UWP loopback tool, follow its instructions and open it with administrator privileges. Add exemptions only for apps that need access to the local proxy, then restart those apps. The same mechanism doesn’t apply to every Store app, and loopback restrictions aren’t the cause of every connection problem. First confirm how the app is supposed to use the proxy and what exactly is failing. TUN may provide another way to route traffic, but verify the routing result; it’s not a universal fix.

Turn off TUN and the system proxy, quit other VPNs, and check whether your normal connection comes back. If the client is closed but the system proxy still points to a local port, turn it off in your system network settings. When you reopen the client, enable only one traffic-routing method at a time. Check the logs for DNS request timeouts, route conflicts, or virtual interface creation failures. Don’t copy an entire DNS configuration without checking it; restore settings one at a time based on your core and network. If the problem persists after turning off the related features, reconnect to the network or restart the system to clear temporary state. Have an administrator review routing and security settings on managed devices.