Clash Open-Source Ecosystem Explained: Core, Meta/mihomo & Client Relationships

1. What Happened to the Original Clash

The original Clash was written in Go by developer Dreamacro and released publicly around 2018 under the GPL-3.0 license. It's a pure command-line core with no GUI of its own: it reads a config.yaml file on startup, opens local HTTP and SOCKS proxy ports, and dispatches each connection to a direct route or a proxy outbound based on the rules defined in that config.

For its time, protocol support was quite comprehensive: Shadowsocks, VMess, Trojan, Snell, plus standard HTTP and SOCKS5 outbounds. Its rule engine matched by domain suffix, keyword, IP range, GEOIP, and more. The "rules evaluated top-down, first match wins" model, combined with the "proxy group" outbound selector, became the common pattern the entire ecosystem still follows today.

Alongside the open-source build, the author also shipped a closed-source Premium core as a precompiled binary, adding extras like a TUN virtual adapter and script-based rules for users who needed them.

In November 2023, the author wiped and deleted the clash repository on GitHub, and the project page has been unreachable ever since. Around the same time, several well-known downstream clients — including Clash for Windows — announced they were discontinuing updates or pulling their releases. The original core's version number froze on the spot, and its protocol support stopped evolving. That's the starting point for understanding the shape of the ecosystem today.

2. From Clash Meta to mihomo

Before the original project was taken down, a community fork called Clash.Meta already existed, maintained by the MetaCubeX organization with the goal of adding new protocols and features on top of the original codebase. After the original repo disappeared, this fork naturally became the de facto mainline. In early 2024, the project was renamed mihomo and moved to MetaCubeX/mihomo, continuing the existing version sequence under the same GPL-3.0 license.

Compared to the original, mihomo's key additions can be grouped as follows:

• Outbound protocols: added VLESS, Hysteria, Hysteria2, TUIC, WireGuard, and more, covering most mainstream protocols that emerged after the original core was frozen.
• Rule engine: introduced rule-providers and a binary rule-set format for distributing and loading large domain or IP lists efficiently.
• DNS module: added per-domain resolution policies and domain sniffing, helping mitigate DNS pollution and mis-routing.
• TUN mode: rewrote and strengthened the virtual adapter stack, offering both gVisor and system implementations for more reliable full-device traffic capture.
• Control API: external-controller stays compatible with the original, so existing dashboards and clients can migrate without friction.

Today, almost every actively maintained Clash-family client defaults to or recommends mihomo as its core; the original core only survives on a handful of legacy devices and old configs.

3. How Core and Client Divide the Work

The Clash ecosystem's architecture can be summed up as "core + shell." The core is a background process handling proxy protocols, rule matching, and DNS resolution. The client is the GUI shell — it handles the interface, downloads and refreshes subscriptions, toggles the system proxy and autostart, and sends commands or reads status through the core's RESTful control API. That API listens on 127.0.0.1:9090 by default:

# config.yaml (excerpt): the core's external control interface
external-controller: 127.0.0.1:9090
secret: ""

Since config file formats are largely compatible across cores, the same config.yaml usually works across different clients without changes. Dashboard tools like metacubexd and zashboard also talk to the same control API, so they can attach to any mihomo instance regardless of which client is running it.

A subscription link is, at its core, just a piece of yaml text generated in Clash config format — the client fetches it on a schedule and merges it into the local config. Once you understand the three layers of "core, shell, subscription," any new client that shows up in the ecosystem becomes easy to place: check which core it bundles, then check how it wraps subscriptions and the system proxy.

4. Client Status by Platform

The table below lists common clients by platform, their bundled core, and current maintenance status (based on each project's public release page):

A few extra notes: Clash Verge Rev is the community-maintained successor to the discontinued Clash Verge, built on Tauri and carrying over the same look and feel as the legacy app. FlClash is written in Flutter and shares one interface codebase across desktop and mobile. OpenClash is a LuCI app for OpenWrt, with a switchable core in its settings. Stash, commonly used on iOS, is closed-source paid software that's compatible with the Clash config format but has no direct lineage to the open-source cores — it's included here purely for reference.

5. Picking the Right Setup

Putting the whole lineage together, three rules of thumb apply:

1. Stick to actively maintained combos. Proxy software needs continuous updates to keep pace with protocol changes and OS updates — a discontinued build only works until it doesn't, and any bugs it has will never get fixed.
2. Default to the mihomo core. New protocols and rule-set formats only land in mihomo going forward; unless an old config depends on some specific behavior of the original core, there's no real reason to go back to an archived core.
3. Pick a client that fits your platform. On desktop, choose between Clash Verge Rev and FlClash based on interface preference; on Android, go with ClashMetaForAndroid or FlClash; on OpenWrt routers, use OpenClash.

Our downloads page lists where to get each client, system requirements, and install steps in detail; for setting things up for the first time, follow our quick start guide step by step.

6. Terminology Cheat Sheet