Clash Original vs. Meta vs. mihomo: Feature Differences and Which Core to Choose

Core Lineage: How Clash Evolved from the Original to mihomo

What people commonly call "Clash" actually refers to three distinct codebases, and understanding how they relate to each other is the first step to picking the right one. The earliest Clash was written in Go by its original author and distributed as a command-line core paired with third-party GUIs, and it served for a long time as the default backend across most client apps. This version is usually called the "original" or "Clash Premium/Core," and it established the rule-based routing, proxy groups, and subscription link model that has since become the industry standard interaction pattern.

Around 2023, the original author's repositories were removed entirely from the code hosting platform, and the original core stopped receiving public source updates or new releases. Any original binary available for download now is essentially a historical build saved by the community before the shutdown, or an archive from a third-party mirror repository — no new protocol support or bug fixes are landing on that codebase anymore.

While the original was still active, developers had already forked its code to extend it, and that fork was named Clash Meta at the time, focused on filling in the newer protocols and TUN mode details that the original never caught up on. After the original stopped development, most GUI clients switched their default core to the Meta fork, which is why "Meta core" still comes up constantly in tutorials and forum posts. The Meta fork later went through a formal rename and continues to be maintained under the name mihomo, with an unbroken code history and release cadence — it wasn't a fresh restart. In other words, the mihomo you see today is functionally the upgraded continuation of Meta. The two aren't parallel projects; they're the old and new names for the same lineage.

Feature and Protocol Support Across the Three Cores

The three codebases differ in protocol coverage, runtime modes, and configuration syntax. The table below lists the differences that matter most in practice.

As you can see, the real divide isn't about "which one is faster" or "which has a nicer UI" — it's a generational gap in the protocol list and runtime capabilities. When the original stopped development, newer encrypted protocols hadn't become mainstream yet, so naturally they were never coded into that version. The value the Meta fork, and later mihomo, added was exactly this: filling in those newer protocols and finer-grained traffic control, and continuing to track changes in the broader proxy software ecosystem.

Maintenance Status and Update Frequency: Can You Rely on It?

Choosing a core isn't just about the feature list — it's also about whether anyone is still actively maintaining that codebase. The maintenance status of the three is very clear-cut.

• Original: The repository is no longer updated, and any executable still floating around is a historical archive. There won't be new protocol support or fixes for known issues. If a subscription provider switches to a new protocol the original doesn't recognize, connections will simply fail, with no upgrade path available.
• Meta (legacy name): As a transitional name, it's no longer an active release channel. Related tags and documentation have been folded into the mihomo project in newer releases, and searching specifically for the "latest Clash Meta release" will usually redirect you to mihomo.
• mihomo: This is the codebase that's actually being actively released right now, with version numbers iterating on a regular cadence. New protocols, new platform support, and bug fixes all land here. The vast majority of actively maintained GUI clients now point their underlying core to mihomo, even if the client's UI still uses the legacy term "Meta core."

Recommendations by Scenario

Based on protocol compatibility and maintenance status, here are a few actionable guidelines.

1. Your subscription only uses basic protocols and you don't need TUN mode

   If every upstream node is Shadowsocks, VMess, or Trojan, with no newer protocols involved, and you have no plans to use system-level traffic takeover, the original archive can technically still connect. But be aware you'd be relying on a historical version that will never receive further fixes — over time there's a real risk of protocol obsolescence or client compatibility drift, so this isn't recommended as a long-term solution.

2. Your subscription includes newer protocols like VLESS, Hysteria2, or TUIC

   The original simply doesn't recognize these protocols, and connections will fail outright. You must use a client built on the mihomo core — there's no workaround here.

3. You need TUN mode for global traffic takeover or per-process routing

   TUN mode is maintained as a stable, long-term feature on mihomo, with more complete configuration fields and behavior. The original's implementation stalled at an early stage, and it's not recommended for fine-grained routing setups.

4. Not sure which to pick, and want to avoid pitfalls

   Just use whatever mainstream GUI client currently ships with mihomo as the default core. It covers the broadest range of protocols, has a stable release cadence, and issues have a real chance of getting fixed — no need to second-guess whether the core has been discontinued.

Notes on Migrating from Original Configs to mihomo

If your existing config file was written years ago against the original core's rules, it can largely be reused as-is on mihomo, but a few fields are worth double-checking so rule group behavior doesn't diverge from what you expect.

• The group types under proxy-groups have more policy options on mihomo. Fields that the original never had will simply be ignored rather than causing errors — but they also won't take effect, so it's worth reviewing each entry.
• The behavior fields under rule-providers are more granular on the new core, but existing simple rule sets will still load normally.
• Entries referencing newer protocol nodes typically won't appear in an original config file at all; you can add them as needed after migrating, without affecting your other existing nodes.

A simple way to sanity-check the migration is to load the old config with the new core first and watch the startup log for any warnings about unrecognized fields, then compare field by field against the official documentation to make sure no key policy was missed.

mihomo -d ./config -f ./config.yaml

When started from the command line, the log will print the core version, the number of rules loaded, and any entries that failed to parse — this is the most direct way to verify the core version and config compatibility, and it's more reliable than just going by the name shown in a client's UI.

Conclusion: What to Choose Right Now

To boil all of this down into one actionable takeaway: the original core is no longer maintained and is only suitable if you know exactly what you're doing and your subscription's protocol range is extremely limited; the "Meta" name has now been folded into mihomo, so there's no point searching for it separately anymore; and when installing a new client or switching cores, prioritize confirming whether the underlying core is mihomo — it's the choice with the broadest protocol coverage and the most active maintenance, and it's already the mainstream default across GUI clients on every platform.