A Q&A handbook organized into basics, installation, usage tips, and troubleshooting. Each answer comes with actionable checks, covering subscription update failures, node timeouts, system proxy not working, TUN permission issues, and other common problems. Use the category nav below to jump straight to a section.
The fundamentals of Clash: how the core and client relate, what a subscription actually is, and where to go once Clash for Windows stops receiving updates.
Clash is an open-source rule-based proxy tool. Its core capability is routing network traffic to different outbound paths based on rules such as domain, IP, and geography. It's built as a command-line core, and day-to-day use happens through a graphical client. It supports proxy protocols like Shadowsocks, Vmess, and Trojan, and runs on Windows, macOS, Android, iOS, and Linux.
The core handles the actual traffic forwarding and rule matching, while the client is the graphical shell around it that manages subscriptions, node switching, and toggling the system proxy. The same core can be used by different clients — for example, Clash Plus, Clash Verge Rev, and FlClash are all built on the mihomo core. Choosing a client mainly comes down to platform support and interface preferences, since routing capability is determined by the core. See the side-by-side review for how each client differs.
Clash for Windows is no longer maintained and no longer receives new protocol or system compatibility updates. Current alternatives include Clash Plus, Clash Verge Rev, and FlClash, all built on the mihomo core with support for newer protocols like VLESS and Hysteria2. Their configuration files are largely compatible with Clash for Windows. To migrate, simply re-import your existing subscription link into the new client — no need to rewrite rules. You'll find these alternatives in the Windows section of the download page.
The Clash core and mainstream clients are all open-source software, free to download and use. A subscription refers to a node configuration link provided by a proxy service provider, offered for a fee or for free by that third party — it has nothing to do with the client itself. The client only reads node information from the subscription and forwards traffic according to rules; it doesn't provide any nodes of its own.
Installation, permissions, and initial configuration across platforms: importing subscriptions, system permissions, and launch at startup. See the tutorial page for the complete walkthrough.
After installing and launching the client, go to the subscription or profile page, paste the subscription link provided by your service, and click import or download. The client will fetch the configuration and display the node list. Then select a node on the proxy page and turn on the system proxy toggle to take effect. If the first import fails, first confirm the link was copied in full and hasn't expired, then check whether your network can directly reach that link.
If you see a message that the developer can't be verified the first time you open the app, go to System Settings > Privacy & Security, and under the Security section click Open Anyway; or right-click the app icon in Finder and choose Open. Also make sure you have the right build: download the arm64 version for Apple Silicon Macs and the x64 version for Intel Macs — an architecture mismatch will also cause the app to fail to launch or crash repeatedly.
The Android client takes over traffic through the system's VPN interface. The first time you tap start, the system will show a VPN connection request — just tap Allow. If the prompt didn't appear, or you accidentally denied it before, go to the VPN page in system settings, remove the app's entry, and start it again. On some manufacturer-customized systems, you'll also need to exempt the client from battery optimization so it isn't killed in the background and cause frequent disconnects.
The Windows client usually has a launch-at-startup toggle in settings; once enabled, it starts with the system and restores your last proxy state automatically. On macOS, check the launch-at-login option in the client's settings, or add it manually under Login Items in System Settings. On Android, allow the app in the system's auto-start manager. If you use TUN mode, it's best to also enable launching with administrator privileges — otherwise the virtual network adapter can't be created after a reboot.
Day-to-day usage: choosing modes, testing node speed, maintaining subscriptions, and syncing across multiple devices.
Rule mode decides, per request, whether to route through the proxy or go direct based on the routing rules in your configuration — typically local traffic goes direct and everything else goes through the proxy, which is the recommended everyday mode. Global mode sends all traffic through the currently selected node, useful when a target site isn't covered by your rules or when you need a temporarily unified exit. When diagnosing routing issues, you can switch to global mode as a control test to quickly tell whether a rule isn't matching or the node itself is unreachable.
On the client's proxy page, click the speed test icon to run a latency test against every node in the current group. The value shown is the HTTP round-trip time to the test address, in milliseconds. Lower is faster, but latency only reflects connectivity, not bandwidth. When choosing a node, prioritize consistency — a node that reliably returns a value across multiple tests is more trustworthy than one that's occasionally very low but frequently times out.
Most clients offer an update interval option in subscription settings, pulling the latest configuration on an hourly or daily schedule so you don't need to intervene manually when the provider adjusts nodes. It's also worth enabling update-on-launch so you always get the latest nodes when opening the client. If the provider changes its subscription domain, automatic updates will keep failing — in that case you must manually replace the link with the new one.
It's best to import the same subscription link on all devices — since nodes are maintained centrally by the provider, enabling scheduled updates on each device keeps them naturally in sync. If you rely on a lot of custom rules, you can place the configuration file in a cloud sync folder, or use the client's export/import feature to migrate it manually. See the articles section for a detailed comparison of when each approach makes sense and what to watch out for.
Common failure points across subscriptions, nodes, and the proxy chain, with a layer-by-layer diagnostic approach. Protocol-level selection questions are covered separately in the technical reference.
Check in this order: first, open the subscription link directly in a browser — if it returns content, the link is valid. A 404 or timeout means the subscription has expired or the provider changed domains, and you'll need to contact them for a new link. If the link is valid but the client still fails to update, try turning off the system proxy before updating, or toggle whether updates go through the proxy in the subscription settings. Finally, check that your system clock is accurate — a large time offset can cause TLS handshake failures.
A fixed diagnostic sequence: first, update the subscription to make sure node info is current; second, turn off the proxy and access the network directly to confirm your local network itself is fine; third, switch DNS servers and try again; fourth, compare nodes across different protocol types — if only one protocol type times out entirely, it's usually a connectivity issue with that protocol on your current network. If everything times out and the subscription is otherwise fine, it's usually a provider-side outage — wait for it to recover or contact the provider to confirm.
The system proxy only affects applications that actively read the system proxy settings — browsers generally do, command-line terminals generally don't by default. If a browser isn't using it, check whether a proxy-related extension has overridden the settings, and confirm the client's listening port matches the port in the system proxy settings. For terminals, manually set the http_proxy and https_proxy environment variables to point at the local port; alternatively, enable TUN mode directly, which takes over all traffic at the network layer and bypasses the system proxy mechanism entirely.
Windows UWP apps are blocked by default from accessing the local loopback address, so they can't reach the local proxy port. Solutions: use the client's built-in UWP loopback exemption tool to lift the restriction for the target app, or use the system's CheckNetIsolation command to exempt it manually. Enabling TUN mode also works around this restriction, since traffic is intercepted at the network layer and doesn't rely on a loopback connection.
Didn't find your issue here? For log error meanings and how to trace them layer by layer, see the log-reading guide in the articles section; for the full install-to-connect walkthrough, see the tutorial page; for a comparison of protocols and cores, see the technical reference.