Troubleshooting Archive

Clash is an umbrella term for rule-based network proxy tools. The core logic is handled by the kernel: reading the config file, matching routing rules, and forwarding traffic. Development of the original Clash core stopped in 2023, and the current community-standard core is mihomo (formerly known as Clash Meta), which is compatible with the original config format while supporting more protocols.

Everyday clients like Clash Plus and Clash Verge Rev are GUI front-ends handling the interface, subscription management, and system proxy settings, and they all call into the mihomo core underneath. When choosing a client, confirm its core is mihomo to get current protocol support.

A subscription link is a URL pointing to a config file hosted by a provider, containing a node list and routing rules. The client periodically pulls this link to automatically sync node changes without manual entry.

Subscription links are provided by your proxy service provider in their user panel, usually labeled as a "Clash subscription" or "Clash config." This site only provides client installers and usage documentation - it does not offer any subscription service. Keep your link confidential once obtained - a leaked link is equivalent to sharing your account, letting others directly use the node traffic tied to it.

These three modes determine how traffic is routed. Rule mode matches traffic against the rules in the config file one by one: traffic hitting a direct rule bypasses the proxy, traffic hitting a proxy rule goes through the selected node - this is the recommended everyday mode. Global mode ignores all rules and routes all traffic through the current node, useful for temporarily testing node connectivity or as a fallback when rules misbehave. Direct mode routes all traffic without a proxy, equivalent to temporarily disabling it.

Most subscriptions ship with well-built routing rules, so Rule mode is usually sufficient. If a site is unreachable in Rule mode, temporarily switch to Global mode to check: if it works in Global mode, the issue is with the rules; if it still doesn't work in Global mode, the issue is with the node.

Clash for Windows stopped development and had its repository removed in November 2023; installers still in circulation are community-archived builds. The app can still run in the short term, but two problems keep growing: first, its bundled core is outdated and can't recognize newer protocols or config fields, causing some subscriptions to fail parsing; second, it no longer receives security fixes.

It's recommended to migrate to an actively maintained client, such as Clash Plus or Clash Verge Rev. Both use the mihomo core, your subscription link can be reused directly, and their interface logic is close to Clash for Windows, keeping migration effort low.

Proxy software needs to modify system network settings and install a virtual network adapter driver, and this behavior overlaps with characteristics of some malware, which easily triggers heuristic false positives in antivirus tools - a common phenomenon for this category of software.

Steps to resolve: first, confirm the installer came from this site's download page or the client's official release channel, not an untrusted reposted copy; second, restore any files removed to quarantine by your antivirus; third, add the client's install directory to the trusted list or exclusion list to prevent core files from being removed again during runtime; fourth, for Windows Defender's SmartScreen prompt, click "More info" and choose "Run anyway."

This is macOS Gatekeeper's default block on apps not distributed through the App Store. Open "System Settings → Privacy & Security," and a record of the just-blocked app will appear further down the page - click "Open Anyway" and enter your password.

If it says the app is "damaged," this is usually because the downloaded file carries a quarantine attribute; run xattr -cr /Applications/AppName.app in Terminal to clear the quarantine flag, then launch again. Also be careful to match chip architecture: download the ARM build for Apple Silicon machines and the x64 build for Intel machines - installing the wrong architecture runs through a translation layer, hurting performance and potentially causing virtual adapter issues.

Entry point names vary slightly across clients, but the logic is the same: find the subscription or profile management page, paste the link, and pull it. In Clash Verge Rev, go to the "Profiles" page on the left, paste the link in the top input box, and click "Import" - once successful a profile card appears in the list, left-click the card to activate it; in Clash Plus, go to the "Profiles / Subscriptions" tab, choose "Add Subscription" and paste the link; Clash Meta for Android requires creating a new profile on the "Profiles" page first, choosing type URL, entering the link, saving, then returning to the main screen and tapping Start.

After importing, be sure the profile is selected before enabling the system proxy, otherwise the core is still running an empty config. See the full walkthrough in the setup guide.

TUN mode takes over traffic at the system level by creating a virtual network adapter, and creating an adapter is a privileged operation. On Windows you need to run the client as administrator, or install the system service as prompted by the client so the service process holds the privilege, after which regular launches can still enable TUN; on macOS, the first time you enable it a permission dialog appears asking for your password to approve the network extension or helper tool; on Linux you need root privileges or the appropriate capability set on the executable.

If service installation fails, fully quit the client (including the tray process), then re-run it as administrator via right-click before installing the service again; if it still fails, check for leftover virtual adapters or services from other proxy software occupying the same resources, and uninstall the conflicting ones before retrying.

The proxy page in most clients has a latency test button; clicking it sends one HTTP probe per node and records the round-trip time in milliseconds. This number reflects the handshake time to reach the test address through that node - lower means faster response; but it is not the same as bandwidth - a low-latency node isn't necessarily faster for downloads, and latency is only meant for ruling out timed-out nodes and doing a rough quality screen. A test showing "timeout" means that node is currently unavailable.

It's recommended to test latency for the whole group before selecting a node, favoring ones with stable numbers; you can also use an auto-select policy group that lets the client switch automatically based on latency results.

This is done through custom rules. Clash matches rules top to bottom, first match wins, so placing custom rules before the subscription's rules lets them override the default behavior. Common syntax: DOMAIN-SUFFIX,example.com,DIRECT routes that domain and its subdomains directly; replacing the trailing DIRECT with a proxy group name forces it through the proxy; IP-CIDR controls by IP range, and PROCESS-NAME is available on some platforms to control by process.

Clash Verge Rev supports appending rules via the "prepend" option in its global extended config, which won't be overwritten by subscription updates; directly editing the subscription file isn't recommended since it gets lost on the next update. See a detailed rule syntax walkthrough in Rule-Based Routing in Practice.

GeoIP is a database mapping IP addresses to countries/regions; rules like GEOIP,CN,DIRECT in a config rely on it to determine where a destination IP belongs, enabling routing setups like sending mainland China IPs direct and everything else through the proxy. There's also a companion GeoSite database that classifies by domain.

These databases gradually go stale as IP ranges change, and outdated data can cause some traffic to be routed incorrectly. Most clients provide a Geo data update button on the settings page - it's recommended to update manually every one to two months; some clients support setting an automatic update interval. Update failures are usually due to the download source being unreachable, so try enabling the proxy first and then running the update.

A DNS leak happens when the traffic itself goes through the proxy, but domain resolution requests still go to your local ISP's DNS, exposing the destinations you're visiting. Key mitigations: first, enable enhanced-mode: fake-ip in the dns section of your Clash config so the client takes over resolution - the app gets a fake IP while real resolution happens on the proxy side; second, set nameserver entries to encrypted DNS (such as a DoH address); third, enable TUN mode and keep the default DNS hijacking config, which intercepts apps that bypass the system proxy and connect directly to port 53 for resolution.

After configuring this, you can verify with a browser-based DNS leak test site - the results should not show your local ISP's resolver. See a field-by-field setup example in DNS Configuration Explained.

Check three things in order. First, confirm a subscription has been imported and the profile is active - enabling the system proxy while the core is running an empty config leaves every request with nowhere to go, showing up as a total disconnect. Second, switch to Global mode and manually pick a node with normal latency to test: if it works, the issue is with rules or node selection; if it still doesn't work, test latency for that group of nodes, and treat an all-timeout result as an expired subscription. Third, check port consistency: the port the system proxy points to must match the client's mixed port; if you've changed the port setting before, turn the system proxy off and back on to let it rewrite the port.

To temporarily restore your network, turn off the system proxy and TUN, confirm the raw connection works, then locate the issue step by step as above.

When an entire group of nodes times out at once, the cause is usually not any single node. Check in order: first, whether your raw network connection is fine - can you open a normal webpage with the proxy off; second, whether the subscription has expired or used up its data allowance - log into the provider's panel to check account status, which is the most common cause; third, update the subscription once - after a provider rotates node addresses, the nodes in the old config fail en masse; fourth, check system time - some protocols are sensitive to time drift and a difference of a few minutes can break the handshake, so enable automatic time sync and retry; fifth, test on a different network (such as switching to a phone hotspot) to check whether the current network is interfering with the proxy port.

If everything still times out after ruling all this out, contact the provider to confirm server-side status.

First distinguish between a network issue and a content issue. Network issue: the subscription URL itself may be blocked by the current network - try enabling the option to "update subscription through proxy" in the client, or connect through a working node temporarily before updating; you can also open the subscription link directly in a browser - seeing a block of config text means the link is reachable.

Content issue: an error mentioning yaml or parse means the config failed to parse, commonly because the link isn't actually a Clash-specific subscription format - go back to the provider's panel and confirm you copied the Clash subscription link, not a link formatted for a different client; a truncated link or extra copied whitespace can also cause a 404 or parse error, so copy the full link again.

The system proxy setting only "announces" a proxy address to apps - whether an app actually follows it is up to the app itself. Browsers generally comply, while many desktop programs, command-line tools, and games use their own network stack and simply ignore the system proxy.

Handle it case by case: Windows UWP apps are restricted by network isolation and block connections to the local loopback address by default, so you need to lift that restriction for the relevant app in the client's UWP loopback exemption tool; command-line tools need the http_proxy and https_proxy environment variables set manually to point at the local mixed port; for programs that don't read any proxy setting at all, enabling TUN mode to take over at the network adapter level is the universal fix, with no per-app configuration needed.

Recommended order: first, switch nodes - load can vary noticeably between nodes on the same line, so try another node in the same region first; second, check the protocol and port - some network environments interfere with specific protocols, so try a different protocol entry point offered by your provider; third, test local bandwidth with the proxy off to confirm the bottleneck isn't on your local network; fourth, review the rules to confirm high-bandwidth apps haven't been routed by mistake into a low-speed node, and temporarily try Global mode to compare speed; fifth, check whether the client is currently downloading a large file through the proxy - actions like updating the subscription or updating Geo data also consume node bandwidth.

A general slowdown during peak hours is usually server-side congestion, which is an issue on the provider's end - switching time windows or lines is enough to confirm this.