Clash Kernel Versions Explained: How Original Clash, Clash Meta, and mihomo Relate

Three Names, One Lineage: The Clash Kernel Timeline

When you first get into the Clash ecosystem, what trips people up isn't config syntax — it's the naming. Tutorials say Clash, download pages say Clash Meta, and newer client builds show mihomo in the UI. These aren't three competing projects; they're the same kernel at different stages of its life. Once the timeline is clear, everything else falls into place.

The short version: original Clash is the shared ancestor, Clash Meta picked up the baton, and mihomo is Meta's current name. Nearly every client installed today runs on mihomo.

Original Clash: The Rule-Based Proxy Pioneer, Now Discontinued

Original Clash was written in Go by Dreamacro and released in 2018. It established the working model still used today: a single YAML config defines nodes, proxy groups, and routing rules, and inbound traffic gets routed to direct, proxy, or reject based on those rules. Mixed-port listening, the external controller API, and domain/IP-based routing were all set in stone by the original.

The original split into two tracks: an open-source core, and closed-source Clash Premium. Premium had exclusive TUN mode and Script support, and it's what early clients like Clash for Windows and ClashX bundled.

In November 2023, the author archived the repo and cleared the releases page — original Clash was officially discontinued. In practical terms: no new protocols will be added, existing bugs won't be fixed, and clients built on it have gradually stopped updating too. Installing a client with the original kernel today will still work in most cases, but its protocol support is frozen at 2023 and won't move forward.

Clash Meta: The Fork That Took Over

Before the original was discontinued, the MetaCubeX team had already forked it into Clash Meta and kept developing it; once the original stopped, Meta naturally became the de facto mainline. Compared to the original, its key additions fall into four areas:

• Protocol support: added VLESS (including XTLS Vision and Reality), Hysteria and Hysteria2, TUIC, WireGuard, ShadowTLS, and AnyTLS — essentially covering every major protocol that emerged after the original.
• TUN mode: built in and free for everyone, no longer locked behind closed-source Premium, and capable of taking over all system traffic.
• Rules: rule-providers and proxy-providers opened up to all users, with domain sniffing (sniffer) and GEOSITE rule sets supported.
• Experience: unified-delay for consistent latency testing, tcp-concurrent for concurrent connection racing, and find-process-mode for per-process routing.

Config-wise, Meta is essentially a superset of the original: configs written for the original will mostly run as-is; but configs using Meta-only fields will error out immediately on the original core.

mihomo: The Current Name for Clash Meta

In 2024, Clash Meta was renamed mihomo, with the repo moving to MetaCubeX/mihomo while version numbers kept incrementing along the same line. Only the name changed — same maintainers, same config syntax, same release cadence, and the docs at wiki.metacubex.one cover both the old and new name.

In day-to-day use you'll still see the names mixed: older builds log "Clash Meta," newer ones log "Mihomo"; some client UIs say "Meta kernel," others say "mihomo kernel" — they're referring to the same program either way. If you see version strings like mihomo v1.18 or v1.19, that confirms you're on the current release line.

Client-to-Kernel Reference Table

The client is just the shell; the kernel is the process actually handling your traffic. Here's what common clients ship under the hood:

Whether a client is worth installing comes down to its kernel: mihomo-based clients keep pace with protocol updates, while clients stuck on the original kernel are frozen at the point it was discontinued. For a detailed side-by-side, see our client comparison page.

Checking Which Kernel Version You're Running

Using Clash Verge Rev as an example, there are three ways to check:

1. Settings page: the "Clash Kernel" section under Settings shows the current kernel type and version, and lets you switch between the stable and Alpha channels.
2. Logs page: the kernel writes its name and version to the first line of the log on startup — set the log level to Info to see it.
3. External controller: while the kernel is running, query the version endpoint directly.

$ curl http://127.0.0.1:9097/version
{"premium":true,"version":"Mihomo Meta v1.18.7"}

9097 is Clash Verge Rev's default external controller port; use whatever port you've set if you've changed it. If the returned version field starts with Mihomo, you're on the mihomo line.

Checking Config Compatibility Before Switching Kernels

If you've got an old config and are planning to move from the original kernel to mihomo, check these three things:

• Original fields are almost entirely compatible with mihomo: port, mixed-port, proxies, proxy-groups, and rules all work as-is.
• Don't put mihomo-only fields into a config meant for the original kernel: things like unified-delay, tcp-concurrent, sniffer, the tun block, and geodata-mode will make the original kernel exit immediately on encountering an unknown field.
• Rule set syntax should follow mihomo's docs: RULE-SET and GEOSITE depend on rule-providers and geodata, neither of which the original open-source core supports.

The short version: original Clash is history, Clash Meta is a former name, and mihomo is the present tense. Pick a client running the mihomo kernel — config syntax, protocol support, and documentation examples all revolve around it now.