Clash Troubleshooting

The Clash client provides the interface for importing configurations, switching modes, setting the system proxy, and viewing logs. The mihomo core handles connections, applies rules, and resolves DNS. A subscription is a way to obtain a configuration, which typically includes proxy servers, proxy groups, and rules; its contents depend on the provider. Installing a client does not provide a working proxy service. When troubleshooting, first confirm that the configuration loads, then check that the subscription service is active, and finally verify that system traffic reaches the core. A successfully launched interface does not mean the connection is working.

Rule mode selects a policy for each connection according to the order of rules in the configuration, making it suitable for everyday traffic routing. Global mode sends connections entering the core through the selected global policy, but you still need to choose a working outbound. Direct mode connects to destinations directly. If you’re new to Clash, start with rule mode. To troubleshoot a site, briefly switch to global mode for comparison. If global mode works but rule mode doesn’t, check which rule matches and which proxy group is selected. Global mode does not automatically capture traffic from every app; you still need to configure an entry point such as the system proxy or TUN.

A subscription link fetches a configuration from a remote source and downloads the provider’s latest content when updated. A local YAML configuration is saved and edited by the user and usually does not update automatically from a remote source. Whether either can be imported depends on the configuration format and core support, not the filename. Before editing a subscription-generated configuration, check whether an update will overwrite your changes. For custom rules you want to keep, use the client’s supported override feature. When backing up, note the configuration name and source, and hide subscription credentials before sharing screenshots or logs.

The Clash client does not include a generally usable proxy service, and publicly shared free proxies can stop working at any time. Their operators and data-handling practices may also be unclear. Check the source, applicable rules, and service authorization before use. Never install an unfamiliar certificate or submit account credentials just to import a proxy. Public configurations may also change DNS, rules, and external control interfaces, so review these settings after importing. A successful connection only confirms that the network was reachable at that moment; it says nothing about long-term reliability or privacy. Keep HTTPS certificate verification enabled, especially when signing in or making payments.

Check your operating system version and processor architecture in system information, then choose the matching installer. Common Windows options include x64 and ARM64. For macOS, distinguish Intel from Apple silicon. Android commonly uses arm64 or arm; check the download notes to see whether a universal package is available. On Linux, choose the appropriate deb or rpm package for your distribution. Don’t infer the architecture from a device’s appearance, and don’t mistake a compressed core package for a desktop client. If the system blocks installation, first verify the source and compatibility requirements, then follow the specific prompt. Avoid disabling all system security settings.

Check that the subscription link is complete and doesn’t contain spaces or line breaks, and make sure you copied the subscription URL rather than a webpage address. Then review the specific error in the client logs. For a 401 or 403, check authorization and account status first. For a 404, check whether the URL has changed. For a timeout, determine whether the network is unreachable or the server isn’t responding. If the response is a login page or an unsupported format, get a configuration intended for the Clash core. Don’t keep retrying updates, as this may trigger rate limits. Keep your current working configuration and ask the provider to confirm the link status, expiry, and data allowance.

After importing, select the configuration as the current one on the configuration page and check for syntax errors or load failures. Next, open the proxy page and select a working outbound for the proxy groups used by your rules, then enable the system proxy. On mobile, also allow the system to create a VPN connection. Visit the target site and check the connections or logs page for its request and the matching rule. If no request appears, check the traffic entry point before trying different proxies. Switching configurations affects new connections, but existing long-lived connections may continue using the previous policy. Close the relevant apps and test again.

TUN mode creates a virtual network interface and changes routes, so it typically requires administrator privileges, a client service, or system VPN authorization. On Windows, follow the client’s instructions to install and start service mode, then enable TUN again. On macOS, check for pending permission prompts. On Linux, check the user account, required capabilities, and virtual interface support. On mobile, confirm that VPN authorization was not denied. If it still fails, note any interface creation or route-writing errors in the logs and check whether another VPN is using the same resources. Turn off TUN to restore connectivity, then troubleshoot one issue at a time. Don’t change DNS and routing settings simultaneously.

Startup launches the Clash client, but it may not enable the system proxy or TUN, or restore the configuration you last used. First enable startup in the client settings. Then check for options to restore the proxy state or start the core. Finally, sign out and back in to verify what actually happens. On Windows, service mode and launching the user interface at startup may be separate settings. On mobile, background activity and battery policies may also affect behavior. If Clash can’t connect after a reboot, check the current configuration and authorization, then verify that the core is running. Don’t assume traffic is being proxied just because the tray icon is visible.

Give each configuration a name that identifies its source and purpose, and keep track of its update interval, proxy groups, and custom overrides. Most clients load the entire selected configuration rather than automatically merging all subscriptions, so a proxy group you used before may not exist in the new configuration. After switching, check the main proxy groups and see which rules match your requests. To combine proxy sources, use a supported proxy provider or merge feature, and avoid conflicts between entries with the same name. Back up configurations before remote updates. Replace your everyday configuration only after verifying the update, and never overwrite your only working copy.

Find the site’s request on the connections page and note the destination domain, matched rule, and selected policy. Rules are generally evaluated from top to bottom, so an earlier broad rule can take precedence over a more specific one below it. Also check whether the proxy group selects direct access or a different outbound. If the connection shows only an IP address, check whether DNS and domain detection are working as expected for the configuration. When adding a rule, use a specific domain condition and place it before any rule that would match first. Reconnect before testing your changes; simply refreshing a page may reuse an existing connection. Don’t replace a focused diagnosis with an overly broad rule.

Fake-IP returns a mapped address for a domain. The core uses the mapping to recover the domain and handle the connection; this is not the actual server address. For Fake-IP to work properly, DNS requests and subsequent connections must follow the expected traffic path. If local network discovery, a particular game, or an app has a confirmed compatibility issue, check the logs and try adding a filter rule for the affected domain instead of disabling the feature entirely. After changing the enhanced mode, you may need to clear DNS caches in the system and apps, then reconnect. A mapped address in DNS results is not, by itself, a sign of a problem. Check whether the request reaches the core and whether the destination is accessible.

First turn off the proxy and confirm that the underlying network works. Then check whether the subscription has expired, the server address and port are valid, and the system clock is correct. Next, review the logs to distinguish DNS resolution failures, connection timeouts, and authentication failures. For DNS errors, check DNS; for timeouts, check reachability; for authentication errors, verify the service credentials. Compare with another outbound in the same configuration and temporarily disable other VPNs to rule out routing conflicts. A client test only reports results for its test destination; it doesn’t prove that every site is accessible. Change one setting at a time and keep the logs from when the error occurred to avoid conflating issues.

The system proxy provides a proxy entry point to apps that support it; it doesn’t guarantee that every program will use it. First confirm that the core is running and that its listening port matches the system proxy address. Then check whether the browser has its own proxy settings or an extension that overrides the system settings. If no request appears on the connections page after you open a site, the problem is likely with the traffic entry point. If a request appears but shows a direct connection, check the mode and rules. Some command-line tools, games, and specialized apps need a proxy configured separately, or may require TUN after you understand its routing effects. Also check whether another proxy tool is repeatedly changing system settings. Avoid running multiple traffic-capture tools at once.

Some Windows app containers are subject to loopback restrictions and may be unable to connect to a local proxy port even when a regular desktop browser works. First confirm that the issue affects only this type of app. Then use the UWP loopback tool provided by the Clash client to exempt only the apps that need access, following its prompts and granting the required permissions. Fully close and restart the app afterward. Don’t exempt every app or disable the firewall instead of configuring loopback. If the app still can’t connect, check whether it uses the system proxy and whether its requests appear in the logs. TUN is a different traffic entry point; whether it’s suitable depends on the permissions and routing environment.

Start by identifying the error. For a DNS resolution failure, check whether the DNS server is reachable, whether requests follow the expected resolution path, and whether the encrypted DNS endpoint can resolve its own address. For a certificate error, check the system date, certificate validity, and system trust store, then compare the result with the proxy disabled. Standard proxy forwarding does not require replacing a website’s certificate. Don’t disable certificate verification or install an untrusted root certificate just to dismiss a warning. If the problem occurs only on a particular network or outbound, try another network for comparison and note the certificate issuer. Reconnect after changing DNS. If the issue persists, keep the logs and full error message for further troubleshooting.