Anyone new to the Clash ecosystem quickly runs into the same question: which one do I actually install? Clash, Clash Meta, mihomo, Clash Verge Rev, FlClash — the names look similar but point to different projects. This article lays out the lineage between kernels and clients on a timeline, explains what descends from what, and how to tell whether a project is still maintained.
The original Clash was a rule-based proxy tool written in Go. Its core ability was routing traffic to different outbound connections based on domain names, IP ranges, GeoIP, and similar conditions, while unifying management of protocols like Shadowsocks, VMess, and Trojan. Its design decoupled the "rule engine" from the "protocol implementation": rules live in the config file, the kernel handles matching and forwarding, and users never have to think about the underlying handshake details. Almost every Clash-family client since has reused this architecture, which makes it the right starting point for understanding the whole ecosystem.
After years of maintenance, the original repository was archived by its author — no new features, no fixes for newly discovered compatibility issues. For everyday users, the practical impact is this: keep running an old client built on this kernel, and once new protocols or new OS versions cause problems, there will be no official update to fix them. That's the direct reason so many community forks appeared — the underlying capability never disappeared, it just needed new maintainers.
Midway through the original project's life, its author also shipped a closed-source Premium kernel with advanced capabilities like TUN mode, fuller rule-subscription support, and script extensions, running alongside the fully open-source base version. That history shaped two directions among later community forks: some projects focused on catching the open-source base up to what Premium-era features offered (implementing their own TUN support, for example), while others built around integrating or re-implementing those advanced features.
That's also why the market today has multiple clients with "nearly identical features but different code origins" — each sits on a different branch of the open-source ecosystem, re-implementing the feature set that the Premium era left behind. As a user, there's no need to untangle the history; just check whether the version you're running supports TUN mode, rule subscriptions, and script-based policies — the handful of things that actually matter.
After the original kernel was archived, the most active and frequently updated continuation eventually grew into and was renamed mihomo. It fully covers the original rule matching and protocol support, while continuing to add new protocols (like Hysteria2 and TUIC) and keep up with OS-level changes (such as shifts in the TUN permission model on macOS and Windows). Nearly every actively updated Clash-family GUI client today runs on the mihomo kernel underneath — not the original, now-archived version.
This is worth internalizing: many client interfaces still use "Clash" as their product name, but the kernel actually running underneath has long since switched to mihomo. Whether a client keeps pace with protocol updates really comes down to how often its bundled kernel version gets updated — not the brand name printed on the interface.
| Stage | Key project | Status |
|---|---|---|
| Early | Original Clash kernel | Archived, no more updates |
| Transition | Clash Premium (closed source) | Historical release, no further iteration |
| Current main line | mihomo kernel | Actively maintained, powers mainstream clients |
Above the kernel sit the various GUI clients, which handle the interface, subscription management, and system proxy settings that users directly touch, while bundling and calling into a particular kernel version underneath. Mapping out this layer is what lets you judge whether a given client is actually "current."
The relationship between these clients isn't "who copied whom" — it's the same underlying kernel capability implemented as an interface across different platforms and tech stacks. Which one to pick depends mainly on your OS, interface preferences, and update cadence, not on questions of "which one is the real one."
Facing a pile of similarly named projects, it's more useful to apply a few practical checks than to trace the full history:
Whether a new release has shipped in the last few months is the most direct signal. A version that's still downloadable but long stalled is usually fine only as a stopgap.
A client's settings or about page usually shows the kernel version it's bundled with, which you can compare against the latest mihomo release.
If a newly emerged proxy protocol has no matching option anywhere in the client, that's a strong sign the kernel version is out of date.
Whenever the OS updates (especially macOS network-extension permissions or Windows TUN driver signing requirements), whether the client keeps pace is another sign of how actively it's maintained.
For everyday use, there's no need to become an open-source history expert — just pick a client version that's still actively updated on the download page, pair it with a working subscription link, and you'll get full rule-based routing, TUN mode, and the rest. The technical lineage is a question for maintainers; what everyday users actually care about is whether it's stable, easy to use, and keeps up with system updates.
Now that the kernel lineage makes sense, head to the download page to pick an actively maintained client version and get the right installer for your platform.