Clash FAQ and Connection Troubleshooting

Clash usually refers to a family of rule-based proxy tools and its configuration ecosystem. mihomo is the core that handles protocol connections, rule matching, and DNS. Desktop clients provide a graphical interface for importing configurations, selecting proxy groups, managing the system proxy, and viewing logs. Even when clients use the same core, their menus, service installation, and override features may differ. When troubleshooting, note the client name and version as well as the core version; saying only that you use Clash isn’t enough. Whether a configuration field is supported depends on the core actually running.

The client reads a configuration and establishes connections, but installing it does not provide a working proxy service by itself. You’ll usually need to import a YAML configuration you prepared or get a subscription link from a service provider, then download and enable it from the configuration page. A file containing rules but no usable proxy entries cannot create remote connections on its own. After importing, make sure the configuration is selected, then check that the proxy page has selectable options in its proxy groups. Subscriptions are sensitive: hide the full link, user ID, and access parameters before sharing screenshots.

Rule mode selects a policy according to the order of rules in the configuration, making it suitable for routing traffic by domain, address, or region. Global mode typically sends connections that reach the core through the global policy group. Direct mode connects those requests straight to their destinations. Global mode does not take over all traffic on the device: apps still need an entry point, such as the system proxy or TUN, to reach the core. If a site is behaving unexpectedly, briefly switch to Global for comparison, then return to Rule mode. If Global works but Rule does not, check which rule matched and which policy group it selected.

Not necessarily. The system proxy sets a proxy address in the operating system and mainly affects apps that honor that setting. TUN uses a virtual network interface and routes to capture eligible traffic, making it useful for apps that ignore the system proxy. When setting things up, start with the system proxy alone. Once your subscription, proxy groups, and connection are working, test TUN if needed. Some clients support running both, but enabling both is not a universal fix. If another VPN or proxy app is running, disable one temporarily to prevent route and DNS conflicts.

Open the client’s configuration page and look for an option such as New, Remote Configuration, or Import Subscription. Paste the full address from your service provider into the URL field and confirm. Once it downloads, enable or select the configuration, then open the proxy page and choose an available proxy from a policy group. Finally, enable the system proxy in Settings and test the destination site in a browser. Button names vary between clients. To import a local YAML file, use the file import option rather than pasting its path into the subscription URL field.

Manually update the subscription from the configuration page and check the logs from the same time. For a request timeout, check your current network and the proxy route used for subscription updates. For responses such as 401 or 403, ask the service provider to confirm the link’s access and expiry. If the response is a webpage or login page, it cannot be imported as YAML. If the log points to a line number, check indentation, spaces after colons, duplicate fields, and options unsupported by the core. Avoid changing several settings at once, and never publish logs that contain the full subscription URL.

Port 7890 is a common example; check the client settings or active configuration for the actual mixed-port value. If the log says the address is already in use, quit other proxy clients and check whether an old process is still running in the background. If the conflict persists, change the mixed port to an unused local port and apply the setting. Update any browser extensions, terminal environment variables, and manually configured proxy addresses as well. Don’t change only the configuration file while leaving apps set to the old port. Check in system settings that automatic system proxy settings have also been updated.

First check that the client’s service mode is installed and running. On Windows, you’ll usually need to authorize service installation or perform the relevant steps as an administrator. On macOS, you may need to approve a network extension or helper service in System Settings, depending on the client. Note the exact permission, driver, or interface creation error in the logs, then follow the client’s instructions to repair its service. Don’t repeatedly install drivers from unknown sources. If your device is restricted by organizational policies, contact your administrator. In the meantime, turn off TUN and test the basic connection with the system proxy.

A speed test usually checks only the test address specified in the configuration. A successful result confirms that one test worked; it doesn’t mean every site, protocol, or DNS request will work. Check which proxy is selected in the active policy group, then visit a known HTTPS site and inspect the Connections page. Check which rule matched the domain, which policy was ultimately used, and whether the logs show a DNS resolution failure or connection reset. Try another proxy if needed, changing only one thing at a time. If other apps work but the browser doesn’t, check browser extensions, custom proxy settings, and Secure DNS.

Use the client’s local rules or override feature where possible. Add a rule for the target domain before broader rules and the final MATCH rule. DOMAIN matches an exact domain; DOMAIN-SUFFIX matches a domain and its subdomains. The policy name at the end of the rule must match a policy group in the active configuration. Save and apply the changes, then visit the site again and confirm the match on the Connections page. A webpage may also request resources from other domains, so add rules for those as needed. Direct edits to files generated from a remote subscription may be overwritten on the next update.

Enable Allow LAN in the client settings, make sure the listen address isn’t restricted to 127.0.0.1, and note the computer’s LAN address and actual mixed port. On the other device, enter this computer’s LAN address, not its own loopback address; the devices must also be able to reach each other. If the connection fails, check the host firewall, guest network isolation, and wireless access point isolation. Only expose the proxy on a trusted LAN. Set authentication and limit access as needed; never forward the proxy port to the public internet. Connections will also drop if the computer sleeps or its address changes.

A remote subscription update usually regenerates the configuration, which can overwrite rules, DNS settings, and policy groups added directly to the downloaded file. Back up a working configuration first, then use the client’s local override, configuration merge, or script extension feature to preserve custom settings. Merge order varies between clients, and new rules may not automatically be placed before MATCH. After applying changes, check the active configuration and verify which rule matches. If you have multiple override sources enabled, disable them one at a time to identify conflicts where the same field is defined or replaced in different places.

Check that the system proxy address and port point to the current client, and confirm that the core is running and the configuration is enabled. Browser extensions can override the system proxy. Some terminal tools only read HTTP_PROXY, HTTPS_PROXY, or their own proxy options, which must be configured separately. Visit the target address and check the client’s Connections page. If there’s no corresponding connection, check how traffic enters the core. If there is a connection but the policy is wrong, check the rules. Temporarily quit other proxy apps and check the system proxy bypass list to make sure it doesn’t exclude the target domain or address range.

Some UWP apps isolated with AppContainer can’t access loopback addresses by default, so the Store or Mail app may fail even when a browser works. If the client provides a UWP loopback exemption tool, follow its instructions and run it as an administrator. Grant exemptions only to the apps that need them, then fully close and reopen those apps. Users familiar with Windows can also manage the exemption list with CheckNetIsolation. Don’t grant access to every app in bulk. If the connection reaches the core but still fails after adding an exemption, check the rules, DNS, and the app’s own service status.

Turn off the proxy and check whether your basic network can reach services that normally connect directly. If not, troubleshoot the Wi-Fi, gateway, or network authentication first. Once the basic network works, enable the configuration, test two available proxies separately, and check the logs for DNS resolution, handshake, and connection timeouts. If only one proxy fails, focus on the remote service. If they all fail, check the subscription, system clock, outbound network restrictions, and conflicts with other VPNs. A speed test timeout alone doesn’t mean the configuration is broken; the test address itself may be unreachable.

First determine whether the domain fails to resolve or resolves but the connection fails, then check the active DNS configuration. Fake-IP is designed to return mapped addresses, so a result that isn’t a public IP does not by itself indicate a problem. Check that DNS requests follow the expected resolution path, that both direct and proxy DNS routes are reachable, and that the browser’s Secure DNS setting isn’t bypassing the client. After making changes, close and reopen the test connection; clear the system and browser caches if needed. For incompatible LAN services, configure Fake-IP filter rules as needed. Don’t replace all DNS and TUN settings at once.