Clash Original vs Meta vs mihomo Core: Protocol Support & Which to Choose

When setting up a client, you often see a "core version" or "core type" option, usually one of Clash Premium, Clash Meta, or mihomo — and occasionally the discontinued original Clash. These names look like mere version differences, but underneath they are entirely different code branches with different feature sets, protocol coverage, and update cadence. Picking the wrong core most directly results in a rule syntax that fails to parse, a protocol node that won't connect, or TUN mode starting up without properly taking over system traffic. This article walks through four main threads to help you figure out which core your current client is running, and whether you need to switch manually.

Core lineage: three branches from one project

To understand the differences, start with the history. The original Clash was written in Go by Dreamacro and was long the de facto standard — a lean rule engine with low resource usage — but the author stopped public maintenance in 2023, and the archived repository no longer merges support for new protocols. This is what's usually called "original Clash" or Clash Premium (an early paid branch that offered enhancements like rule latency testing, but whose underlying protocol set was essentially the same as the open-source version).

After the original stopped receiving updates, the community forked it into the Clash.Meta branch, adding protocols and features the original had always lacked, such as a complete TUN mode implementation, Hysteria, TUIC, and WireGuard outbound support. That branch was later officially renamed mihomo, which is now the most actively and frequently maintained core. Most mainstream clients (Clash Verge Rev, FlClash, Clash Meta for Android, etc.) ship mihomo by default, though the client UI often still labels it "Meta core," which can make it seem like Meta and mihomo are two different things — in reality, mihomo is simply the continuation of Clash.Meta under a new name; they are different stages of the same branch.

Protocol support comparison: gaps concentrate on newer protocols

All three handle the "old three" protocols — Shadowsocks, VMess, and Trojan — without meaningful differences; they parse and connect fine everywhere. The real gaps show up in protocols and transport methods that emerged in recent years:

As you can see, virtually any protocol introduced after 2021 is unsupported by original Clash, which is the direct reason it has fallen out of use. Clash Meta, as a transitional branch, covers most of the newer protocols, but some implementations remain stuck on early versions and can lag behind when protocol specs get updated (for example, TUIC going from v4 to v5). mihomo, as the currently active branch, keeps up with new protocols fastest, usually merging support within one or two minor releases after a protocol spec ships.

Common reasons subscription nodes fail to parse

If your subscription includes Hysteria2 or TUIC nodes and they show up as "unknown protocol" after import — or get filtered out entirely — the client is most likely still running the original Clash core internally. There's no need to reinstall the client; check the settings for a "core switch" option, and switching to Meta or mihomo core and re-importing the subscription usually resolves it.

Rule syntax differences: new matching types added by the Meta lineage

On rule providers and rule syntax, mihomo/Meta add several matching types that the original core doesn't recognize. Putting these directly into an original-core config file can cause startup failure or have the rules silently ignored:

• RULE-SET: references an external rule-set file; early original-core versions don't support the incrementally updatable rule-set format.
• GEOSITE / GEOIP (paired with mmdb/dat databases): categorize by domain or IP geolocation in bulk; the original core has poor compatibility with the newer database formats.
• SCRIPT: allows simple scripting logic for routing decisions, supported only by Meta/mihomo.
• SUB-RULE: nested sub-rule-set references, added in later mihomo releases to keep large rule files manageable.
• Process-level matching via process-name / process-path: routes traffic based on the requesting app process, relying on TUN mode to obtain process information — a capability the original core lacks.

rules:
  - RULE-SET,private,DIRECT
  - RULE-SET,reject,REJECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

In the common rule snippet above, both RULE-SET and GEOSITE require the core to have matching parsing capability. Loading this kind of config into a client that only understands original syntax typically produces an "unsupported rule type" log entry, or the rules as a whole silently fail and fall back to the default policy group — which in practice looks like: you configured routing rules, but all traffic still takes the same path.

TUN mode implementation: completeness of takeover determines usability

TUN mode means the core creates a virtual network interface at the system level and forces all app traffic on the device into the proxy pipeline, instead of relying on each app to set its own proxy address. This is also where the gap between the three cores is most visible:

• Original Clash: TUN support was added late in the project's life and is fairly basic — handling of IPv6 and DNS hijacking is incomplete, and in practice some apps frequently bypass the proxy.
• Clash Meta: rewrote the TUN implementation with automatic routing table configuration, DNS hijacking, and process-level filtering, covering traffic types like UWP apps and system services that the original core couldn't handle.
• mihomo: keeps refining on top of Meta, with targeted optimizations for VpnService integration on Android and NetworkExtension adaptation on iOS, while fixing many TUN compatibility issues caused by system version upgrades.

For Android users this matters especially: whether a Clash for Android-style client can reliably take over global traffic and correctly handle DNS request routing hinges on whether it's built on the mihomo core. If certain apps — especially system-level apps with their own network isolation — keep bypassing the proxy, check the client's core version first, then look into that app's specific network settings.

Maintenance status and update cadence: what determines long-term viability

A static comparison of protocols and syntax only reflects the current snapshot — what really matters when choosing is maintenance activity. Proxy protocols keep evolving, and once a core stops updating, it won't be long before it falls behind server-side protocol versions.

In short, "Clash Meta" is now largely a legacy name — actual code development has entirely shifted to the mihomo repository. Clients that still label the branch "Clash Meta" are, under the hood, essentially running mihomo builds; the naming just hasn't been updated. Clients genuinely still running the original Clash core, never upgraded, are now fairly rare, and when you do encounter one, its rule syntax and protocol support will be noticeably behind.

Core recommendations for different scenarios

Combining the four dimensions above, here's guidance for a few typical scenarios:

1. Everyday use with newer subscription nodes: prioritize a client built on the mihomo core — better new-protocol compatibility and more stable TUN behavior, plus faster community fixes when issues arise.
2. Reliance on complex routing rules or large rule sets: confirm the client supports RULE-SET and SUB-RULE syntax; this essentially rules out the original core.
3. Purely static configs with rarely changing nodes: if the subscription only uses basic protocols like Shadowsocks/VMess and doesn't need full TUN takeover, a client still labeled "Meta core" is usually fine — no need to constantly switch cores.
4. Global proxy plus per-app rules on Android: make sure the client's TUN implementation is based on mihomo, or process-level routing and traffic takeover for certain system apps will be incomplete.

The most direct way to check which core your current client is running is to look at the "About" or "Core info" section in settings, which usually shows a version string like mihomo v1.18.x. If it only shows a version number with no source information, you can also add a new-syntax rule (such as RULE-SET) to the config file as an indirect test — if it fails, that tells you something too.

A quick checklist for diagnosing core issues

When you hit problems like "rules not taking effect," "protocol won't connect," or "some apps lose network access once TUN is enabled," work through the following steps — usually a few minutes is enough to tell whether a core mismatch is the cause:

1. Check the client log for keywords like unsupported, unknown rule type, or protocol not supported.
2. Check the current core version and source in settings to determine whether it's the original Clash or an outdated Meta branch.
3. If the client offers a core switch option, switch to the mihomo branch and reload the config file.
4. If rules or protocols still fail, check whether the syntax for the relevant fields in the config matches the documentation for the current core version, paying particular attention to rule-set format (YAML/plain text) and field naming changes.

Overall, the three cores aren't equal alternatives — they're points along a single line of technical evolution: original Clash is the starting point but has stopped moving forward, Clash Meta was the transitional stage, and mihomo is the current continuation and endpoint. Unless there's a clear compatibility reason to stick with old behavior (for example, a legacy config that strictly depends on original-core quirks), there's no need to hold onto an old core for everyday use — choosing a client built on mihomo saves most of the troubleshooting caused by protocol or syntax incompatibility.