Windows
The main desktop platform, with both an installer and a portable build. Supports system proxy and TUN mode; the UWP loopback exemption issue is covered separately on the download page.
Go to Downloadclash-verge.us — All-Platform Client
Here you'll find installer links for Windows / macOS / Android / iOS / Linux clients, along with subscription import tutorials and advanced setup guides covering TUN mode, Fake-IP, and more — everything from first install to rule tuning, in one place.
Each of the five platforms has its own recommended client and install method — click through to jump straight to that section of the download page. You'll also find a system requirements table and notes on which client fits which use case; if you're not sure which to pick, check the client comparison page first.
The main desktop platform, with both an installer and a portable build. Supports system proxy and TUN mode; the UWP loopback exemption issue is covered separately on the download page.
Go to DownloadPackaged separately for Intel and Apple Silicon. First launch requires approval in System Settings — the exact steps are listed on the download page.
Go to DownloadInstall the APK directly, with separate builds by architecture (such as arm64). See our blog and docs for background-service and battery-optimization settings across device makers.
Go to DownloadGet Clash Plus from the App Store. Authorize the VPN configuration profile on first launch, then import your subscription — full steps with screenshots are in the docs.
Go to DownloadAvailable as a deb package and AppImage-style build. Desktop distributions can install the full GUI client, while server setups can run the core alone.
Go to DownloadView all clients → Mihomo core (server / router) → Client comparison →
The feature index is on the left, with the matching detail panel on the right. Each item maps to a chapter in the advanced setup guide — here on the homepage we just cover what it solves and when to use it.
Rule-based routing decides which traffic goes through the proxy and which connects directly. The client matches each connection against conditions like domain, IP range, or process name, then hands it off to the matching policy group: local sites stay on a direct, low-latency path while everything else routes through your chosen node. Unlike flipping a global toggle by hand, rules stay configured once and keep working — browsers, terminal tools, and game clients can each follow their own path without interfering with one another. Rules can be layered from subscription-provided sets, referenced rule sets, and local custom entries, matched top to bottom, with earlier entries taking priority.
Plenty of programs don't respect system proxy settings — command-line tools, some games, and background services often route straight out, bypassing the usual proxy path. TUN mode creates a virtual network adapter at the OS level, intercepting all device traffic at the network layer and handing it to the core, solving the "proxy is set but doing nothing" problem at its root. Enabling it requires granting admin or system-extension permissions, and on Windows it involves installing a service; on desktop it's best paired with rule mode so traffic isn't routed indiscriminately. The advanced guide has a dedicated chapter on enabling steps and common conflicts for each platform.
With traditional real-IP resolution, every domain needs a DNS lookup before a connection can even open — and a poisoned lookup means connecting to the wrong address entirely. Fake-IP mode has the core return a virtual address from a reserved range immediately, skipping that first lookup delay, while keeping the domain name available for rule matching, which makes routing decisions more accurate. It pairs with fake-ip-filter: domains that need a real IP — LAN device discovery, certain verification services — go on the filter list to bypass Fake-IP entirely. After switching resolution modes, it's worth flushing your DNS cache once to avoid intermittent access issues from mixed old and new addresses.
A provider's subscription link is the main source of node info — the client imports every node from that one link and refreshes it automatically on your set interval, so node changes never need manual upkeep. Rule sets (rule-providers) turn routing rules into subscribable remote resources too: community-maintained category lists update hourly or daily, and your local config just needs one line referencing them, leaving additions and removals entirely to the upstream source. When a subscription update fails, the client keeps running on the last working config; troubleshooting usually comes down to three angles — link validity, the update connection itself, and User-Agent compatibility — covered in a dedicated post on our blog.
Editing the config a subscription pushes down directly just means it gets overwritten on the next refresh — that's the exact problem overrides solve. A local override file lives independently of the subscription and layers on automatically after every refresh: adding custom rules, swapping in different DNS settings, restructuring policy groups — all of it lives in the override layer, safe no matter how the subscription updates. Merging multiple subscriptions, meanwhile, pulls nodes from several providers into one config, all managed by the same policy groups and filterable by region or purpose. Together, these two features make "subscription supplies nodes, local config controls behavior" a stable long-term setup.
The core exposes a local RESTful control API that a web dashboard can use to read the connection list, live traffic, and logs, plus switch nodes and adjust policy groups on the fly — no client restart needed. That's especially useful for headless routers and server deployments: the core runs on a machine with no display, and every management action happens in a browser instead. The API only listens on localhost by default, so set an access secret before exposing it to your LAN; the dashboard itself is a static page, and several official and community-built ones can connect to it directly. The External Control chapter in the advanced guide covers ports, secrets, and setup for the common dashboards.
The Clash Verge line of clients comes from the open-source community: after the original Clash Verge project stopped receiving updates, the community picked up maintenance under the name Clash Verge Rev, with all code kept public on a code-hosting platform — commit history, issue discussions, and release notes are all open for anyone to check. Most problems users run into already have a matching discussion and resolution in the issue tracker.
Under the hood, the client runs on the mihomo core (part of the Clash Meta lineage) — currently the actively maintained core branch in the Clash ecosystem, with rule types, protocol support, and DNS capabilities continuing to evolve. The GUI client handles the interface and system integration, while the core handles the actual traffic processing, and the two ship independently: when the core fixes something, the client just needs to bundle the update — no need to wait for a major version.
Updates go out through public release channels, each one with its own changelog. The desktop client has a built-in update check, or you can always come back to this site's download page for the current version; mobile releases go through the app store or APK distribution. The version info on our download page stays in sync with upstream releases — the version number shown is the one currently available.
There's no paywall anywhere in the ecosystem: the client, the core, and the accompanying rule-set resources are all free. Collaboration follows the standard open-source workflow — if you want to verify how something behaves, you can read the source or clone the repo and build it yourself.
Four of the most common questions, answered in a sentence each — full answers and more questions live on the FAQ and glossary pages.
What's the relationship between Clash Verge and Clash?
Clash is the umbrella name for the core project; Clash Verge is a GUI client built on the mihomo core — think "engine and cockpit."See the glossary →
No internet after importing a subscription — what to check first?
Check three things in order: whether system proxy or TUN is turned on, whether the active policy group has a working node selected, and whether the subscription actually pulled in a node list.Step-by-step troubleshooting →
TUN mode or system proxy — which one should I use?
System proxy is enough for everyday browsing; turn on TUN when you have command-line tools, games, or other apps that ignore the system proxy. You don't need both running at once.Full breakdown in the advanced guide →
The client crashes right at startup — now what?
Start by checking your config file syntax, then check for a port conflict or a leftover core process — those four causes account for nearly every crash.Full troubleshooting checklist →
Setup notes, platform deep dives, and troubleshooting write-ups, newest first.
When the client won't open or quits immediately, the cause is almost always one of four things: a config syntax error, a port already in use, a leftover core process, or a missing runtime library. Here's how to find the logs and rule each one out, platform by platform.
Read more →Higher-than-expected battery drain on mobile is usually tied to background wake-ups and TUN mode. This post breaks down the common causes and gives concrete settings for background behavior, rule trimming, and battery-optimization whitelists across device makers.
Read more →When a subscription refresh errors out or the node list never changes, check three angles: link validity, the network path used during updates, and User-Agent compatibility — plus how to set a sensible auto-update interval in each client.
Read more →