Clash Original vs Meta vs mihomo: Core Differences in Protocols & Config Compatibility

One Lineage: From Clash to Clash Meta to mihomo

To untangle the three names, start with the timeline. The original Clash (often called "vanilla Clash" or "Clash Premium") was maintained by a solo developer for years and established the foundational architecture—rule-based routing, proxy groups, provider subscriptions—that nearly every later client's config syntax is modeled on. The original author stopped updates and deleted the code repository in 2023, freezing the original core in place with no further support for new protocols or fields.

After that, the most active community fork was Clash Meta (also written Clash.Meta), which continued development on top of the original codebase, filling gaps the original never addressed while keeping config syntax highly compatible—longtime users could switch over with almost no config changes. After running for a while under that name, the project was formally renamed mihomo. The name changed, but the repository, maintainer team, and technical direction carried straight through—think of it as "Clash Meta's continuation," not a fresh project starting from scratch.

So most Clash-family clients still receiving updates today (desktop apps, router firmware plugins, some Android clients) are essentially running mihomo under the hood, just wrapped in different UIs and brand names. Understanding this lineage makes the feature comparisons below much easier to map onto real choices.

Protocol Support Differences: What the Original Core Could Do Before It Stopped

Protocol support is the most obvious difference across the three generations. When the original core stopped updating, it supported mainly Shadowsocks, ShadowsocksR, VMess, Trojan, and Snell—which covered most subscription setups at the time, but never gained anything afterward. Clash Meta then added VLESS, Hysteria, Hysteria2, TUIC, WireGuard, and other newer protocols, and mihomo kept extending this list at a pace noticeably faster than the original core's pre-freeze update cycle.

Put another way: if your subscription includes a VLESS or Hysteria2 node, the original core simply can't parse it—the client will either error out or skip that node entirely. This is the real reason many people upgrade their client and suddenly find "all nodes broken": the subscription isn't broken, the core just can't keep up with the protocol.

TUN Mode and Core Architecture: The Key Upgrade in Meta/mihomo

TUN mode (virtual network adapter mode) determines whether the client can take over all system-level traffic, not just the browser or a handful of apps. The original core does include TUN support, but the implementation is fairly basic, with limited process recognition—it often struggles in scenarios that need per-app routing (say, only proxying one game while everything else connects directly).

Clash Meta rebuilt TUN mode from the ground up, introducing a much more complete process-matching mechanism that can filter traffic by process name, path, or even package name, paired with the process-name and process-path rule fields for fine-grained routing. mihomo continued optimizing performance and compatibility on top of that, especially TUN stability on Windows and macOS, cooperation with system firewalls, and IPv6 traffic handling—all noticeably more mature than the original.

Another often-overlooked architectural difference is how each core handles multi-core concurrency and memory usage. Under long-running workloads with many nodes, mihomo's memory growth curve stays flatter than the original's—which matters a lot for routers or NAS boxes that run 24/7. If your setup runs continuously in the background with occasional group switching, the newer core generally offers better stability guarantees.

Config File Field Compatibility: What Can Migrate Directly

The good news is that config syntax across all three generations shares a common origin, with no breaking changes to the core structure. Fields like port, socks-port, mode, proxies, proxy-groups, and rules are written identically across original, Meta, and mihomo—a config written for the original core will very likely load and run fine on mihomo as-is.

Differences show up mainly in newer fields and protocol-specific parameters. A few concrete examples:

• Sub-fields under the tun block—stack (choosing the gVisor or System network stack), auto-route, dns-hijack—have no equivalent in the original core; writing them into an original-core config gets them silently ignored or triggers an error.
• Node declarations like type: vless or type: hysteria2 under proxies use type values the original core doesn't recognize, so it skips the node or errors on the whole block.
• enhanced-mode: fake-ip under the dns block is supported by both generations, but mihomo refined the matching rules for fake-ip-filter, so some syntax behaves slightly differently on the original core.
• The behavior field in rule-providers supports more value types on the newer core; the original only handles the basic three—domain, ipcidr, classical.

Practical advice: migrating from the original core to mihomo, you can carry the config over almost unchanged and just add the tun block and new-protocol nodes. Going the other way—downgrading a mihomo config to run on the original core—you must strip out new-protocol nodes and advanced tun fields first, or the whole config will fail to load.

Which One to Pick: Scenario-Based Recommendations

Based on the protocol support, TUN capability, and config compatibility differences above, here are some practical picks:

1. Your subscription includes VLESS, Hysteria2, TUIC, or other new protocols: you must use the mihomo core—the original simply can't parse these nodes, no workaround exists.
2. You need per-app global routing (proxy for gaming, direct for everything else): pick mihomo for its full process-level TUN support; the original's process matching is limited and rules may silently fail to apply.
3. Running long-term on a router or NAS: mihomo is the safer choice, with steadier memory and concurrency behavior for extended uptime.
4. Only using basic Shadowsocks/VMess nodes with a config that hasn't changed in years: both generations will run it, but since the original is discontinued, migrating to the actively maintained mihomo is still recommended to avoid future protocol incompatibilities.
5. Got an old shared config file and aren't sure of its compatibility: search the text for vless, hysteria, tuic, or a tun: block—any of these means the config was written for a newer core.

Nearly all mainstream Clash-family clients today, regardless of their branding, run the mihomo core under the hood—which is also the core route this site's download page defaults to recommending. Choosing a core really comes down to protocol coverage and long-term maintenance, and the newer core wins on both fronts; the original now serves mainly as a historical reference point.