Clash FAQ

Clash is a commonly used name for a proxy core and its configuration ecosystem. mihomo is an actively developed core project in that ecosystem. Clients such as Clash Verge Rev and FlClash provide a graphical interface for importing configurations, managing the system proxy, and controlling the core process; the core itself parses rules and establishes connections. When troubleshooting, note the client name and core version separately from the About or Core page. Similar interfaces don’t guarantee support for the same configuration, especially for TUN, DNS, and protocol fields. Choose a client for your device’s operating system, and check which core is running before editing a configuration rather than relying on the installer’s name.

You’ll need a working proxy configuration. The client reads the configuration and forwards requests; installing it doesn’t provide a remote proxy service. In most cases, get a Clash- or mihomo-compatible subscription from your existing service’s account page, then import it from the Configuration page. You can also import a YAML file you maintain yourself. After importing, check that the configuration is selected, proxy groups appear on the Proxies page, and the selected group has a working proxy. Subscription URLs often contain account details, so treat them as sensitive and hide the full URL in screenshots. Don’t use configurations from unknown sources with important accounts, or mistake a single node link for a complete configuration file.

For everyday use, start with Rule mode. Requests are matched against rules from top to bottom and routed to the corresponding proxy group. Global mode sends requests that reach the core to the global proxy group. It’s useful for temporarily checking whether rules are causing a problem, but you still need to select a working proxy in that group. Direct mode connects requests reaching the core directly, making it useful for comparison tests. The mode only determines how the core handles requests it receives; it doesn’t replace the system proxy or TUN, and it won’t automatically capture traffic from every app. If a site still won’t load in Global mode, first check whether the request appears in the logs, then check the proxy connection. Avoid changing DNS while switching modes, or it’ll be harder to identify the cause.

The system proxy uses your operating system’s proxy settings to direct apps that honor them to a local listening port. TUN uses a virtual network interface to receive routed IP traffic, making it better suited to apps that ignore the system proxy. Neither guarantees that all traffic will use a proxy; routing, app behavior, and rules also affect the result. When setting things up, start with the system proxy alone. Once your browser works, enable TUN if needed and follow the client’s guidance on combining the two. Don’t enable multiple proxy clients, VPNs, and virtual network interfaces at once just to troubleshoot. A single, clearly defined traffic-capture path is easier to diagnose than a stack of overlapping switches.

On the Configuration page, choose Import from URL or New Subscription, paste the Clash subscription URL from your service, and save it. Once it finishes downloading, select the configuration to make it active. Then check the Proxies page to confirm the groups have loaded, and look for parsing errors on the Logs page. Seeing a file in the list only means the configuration was saved, not that it’s active. If you see `yaml: unmarshal errors`, check the subscription format and core compatibility first; don’t delete unfamiliar fields without checking them. Finally, enable the system proxy, visit a site, and inspect the connection log. The matched rule, proxy group, and proxy shown there confirm what’s actually being used.

Check your device’s processor architecture before choosing an installer. On Windows, go to Settings → System → About and check System type. On macOS, check the chip under About This Mac: Apple Silicon models typically use ARM64, while Intel models use x64. Most newer Android devices use arm64-v8a, but check your device and the installer’s supported architectures. On Linux, run `uname -m`: `x86_64` usually means AMD64, and `aarch64` usually means ARM64. Also check the minimum OS requirements. If installation or startup fails, save the exact error and first rule out an architecture or OS version mismatch. Changing subscriptions won’t fix an installation issue.

Startup launch usually starts the client; it doesn’t guarantee that the core, system proxy, or TUN will be restored. Sign out and back in, check that the tray icon appears, then verify the core status, active configuration, and traffic-capture switches. On Windows, make sure the app isn’t disabled under Startup apps. If you use TUN, confirm that the required client service is installed and can start. Don’t configure duplicate startup entries for both administrator and standard-user accounts. If the subscription only fails to update right after sign-in, wait for the network to come up and update it manually, or use the client’s delayed-start option. Check each step in the startup process; a process in Task Manager alone doesn’t mean the connection is back.

First identify what the prompt is asking permission for: installing a service, creating a virtual interface, or authorizing a network extension. If a Windows client offers Service Mode or Install Service, authorize the installation as prompted, then enable TUN again. Don’t rely on repeatedly launching the client with elevated permissions to hide a service problem. On macOS, use the prompt to allow the relevant network extension or VPN configuration in System Settings; the process varies by client. On Linux, TUN typically requires access to `/dev/net/tun` and appropriate network permissions, so use the service setup recommended by the project. After authorizing, check the logs to confirm the interface was created. If you still can’t connect, investigate routing and DNS rather than granting unrelated disk permissions.

Latency tests mainly measure connectivity and response time to the test server. They don’t measure sustained bandwidth or guarantee that a website uses the same route. Fix one proxy and one download URL, then check the connection log to make sure the request isn’t being routed to a different group by a rule. Compare direct and proxied connections, different proxies, and different times of day to distinguish local network issues, the remote route, and limits imposed by the destination site. Pause heavy transfers on other devices during testing to avoid competition. If only one app is slow, check its proxy settings and connection limits. Don’t choose a proxy solely by its lowest latency or treat a single speed test as a guarantee of ongoing performance.

On the Connections page, check the rule and proxy group used by the request. Make sure you changed the group actually in use, not another group with a similar name. `select` groups let you choose manually, while automatic groups such as `url-test` may pick a different proxy based on test results. For nested groups, check each group in the selection chain. Existing long-lived connections usually won’t move to a new proxy when you switch nodes. Close the relevant connection or restart the app that made the request, then test with a new connection. A subscription update may also change group structure or reset your selection, depending on whether the client saves that state. Change one group at a time and check the proxy used by a new connection; an existing page that reuses an old connection isn’t a reliable test.

`mixed-port` is the combined listening port for HTTP and SOCKS proxy requests. Point an app’s manual proxy settings to this port. `external-controller` is the API address for managing the core, not a port for web traffic. `7890` and `127.0.0.1:9090` are common examples; check the values used by your client. If the logs show `bind: address already in use`, quit other proxy apps and check what’s using the port. After changing `mixed-port`, update any app’s manual proxy settings too. Bind the management API to the loopback address whenever possible, and configure access controls if you need to expose it. Don’t expose the management interface to your LAN or the public internet just to let a local app connect.

First confirm the affected app is a UWP app with app-container isolation, rather than a problem affecting all Windows apps. Some apps can’t access a local loopback proxy by default, so a browser may work while Microsoft Store apps fail. If the client includes a UWP loopback exemption tool, open it with the required permissions, enable the exemption only for the apps that need it, then restart the app and test again. An exemption only permits access to the loopback address; it doesn’t configure a proxy or fix a nonworking node. If the client doesn’t include a tool, follow Microsoft’s documentation to manage loopback exemptions for specific apps with `CheckNetIsolation`. Don’t enable exemptions for every app. If the app still fails, check whether it honors the system proxy and whether its requests appear in the connection log.

First distinguish an HTTP error from a network error. A 401 or 403 can indicate an expired URL, access restrictions, or an account issue. Check your service status on its account page and copy the full Clash subscription URL again. For a 404, first make sure you copied the entire path. An HTML login page instead of a YAML configuration can also cause an import parsing error. For `i/o timeout`, check your network and whether the subscription domain is reachable. If the client lets you choose whether updates use a proxy, test both direct access and a confirmed working proxy. This avoids relying on a configuration that hasn’t updated yet. When sharing an error, include only the status code and domain; remove account details and query parameters from the URL.

Start with the full error. `dial tcp` alone isn’t the cause; it indicates that the error occurred while establishing a TCP connection. `i/o timeout` afterward usually means the connection wasn’t established in time. `connection refused` often means the destination port isn’t listening or explicitly rejected the connection. For `no such host`, check DNS resolution first. Confirm the subscription is still valid and the node address and port are current, then test a different proxy for comparison. Temporarily disable other VPNs to rule out routing conflicts. If all nodes fail, check your local network, DNS, and the client’s traffic-capture status. If only one node fails, contact the relevant service provider. Don’t try to solve the problem by endlessly increasing timeouts or disabling your firewall entirely.

Open the Connections page and refresh the target site. If no new request appears, the issue is more likely with traffic capture than with routing rules. Check that the proxy address and port in your OS settings match the current `mixed-port`. Then check whether your browser uses its own proxy extension or network settings; apps such as Firefox may not follow the system proxy. Quit other proxy clients so they don’t override the system settings. If the request reaches the core but shows `DIRECT`, check the matched rule and mode instead of repeatedly toggling the system proxy. Turn off the system proxy before quitting the client. If all internet access stops after you quit, remove the manual proxy that still points to a local port in your system proxy settings.

First determine whether DNS lookup is failing for the node’s domain or the destination website. The domain shown in the logs can help narrow it down. Note the current `dns` configuration, then change one thing at a time: confirm the resolver is reachable, that its own hostname can be resolved during bootstrap, and that another VPN or security app isn’t intercepting DNS requests. If you use `fake-ip`, also make sure traffic to the virtual addresses is being captured correctly; clearing the cache alone won’t fix a routing problem. If your browser has its own Secure DNS setting, temporarily make it use the system resolver for comparison. After fixing the configuration, clear the system and app caches, then establish a new connection. Don’t combine DNS settings copied from multiple guides, especially fields that your core doesn’t support.