How Does mihomo Differ From the Classic Clash Core? A Look at Meta Fork Features

From Clash to Clash Meta to mihomo: a brief history of the core

The original Clash core was started by Dreamacro and written in Go. It established the basic config.yaml structure, the proxy-group abstraction, and the rule-matching engine — the starting point for every fork that followed. As protocols evolved (Hysteria2, TUIC, WireGuard, and others arrived one after another) and users demanded finer-grained control, the community forked the original codebase into Clash Meta, continuously merging new protocols, new rule types, and performance improvements. Updates to the original repository slowed down after 2022, while Clash Meta, under active maintenance, gradually overtook it in feature coverage and eventually renamed itself mihomo, continuing development as an independent project.

Today, "the mihomo core" is effectively synonymous with the earlier "Clash Meta core" — they're just different naming stages of the same development lineage. Protocol prefixes and config fields are largely compatible between them; only the package, version numbers, and some default behaviors have shifted across iterations. Understanding this lineage helps when trying to figure out which capability set a client's stated "core version" actually corresponds to.

Outbound protocol support: what mihomo added

Protocol support is the most immediately visible difference between the two cores. The original Clash core focuses on earlier, well-established protocols like Shadowsocks, ShadowsocksR, VMess, Trojan, and Snell, with fairly fixed config fields and no major expansion for a long time. mihomo builds on that foundation by adding recently introduced outbound types, commonly including:

• Hysteria / Hysteria2: a QUIC-based congestion-control protocol that outperforms traditional TCP-based protocols on weak or high-packet-loss links.
• TUIC: also built on QUIC, focused on low-latency scenarios, suited to interaction-latency-sensitive use cases.
• WireGuard: connected directly as an outbound type, no longer requiring a separate system-level WireGuard client.
• Flow-control extensions for VLESS / VMess, along with the ShadowTLS front layer for further obfuscating traffic characteristics.
• Support for newer version fields of protocols such as Snell v4.

This means that if your subscription nodes use any of these newer protocols, only the mihomo core can correctly parse them and establish a connection; when the original core encounters an unknown protocol type, it usually just skips that node or throws an error, leading to a proxy group where the "node count doesn't add up."

Rule sets and GEO data: differences in the update mechanism

Rule-based routing relies on GEOIP/GEOSITE databases and rule sets (rule-providers) to determine domain or IP ownership. The original core's GEO data format is relatively fixed, and update frequency depends on the core's own release cadence; mihomo supports more flexible rule-set sources and formats:

1. Support for rule-set referencing remote rule sets, with a configurable behavior (domain / ipcidr / classical) and update interval — rule content is decoupled from the core version, so you don't need to wait for a new core release to get the latest routing rules.
2. Support for MRS, a mihomo-specific binary rule format that loads noticeably faster than plain-text rules, especially once rule entries reach the tens of thousands, where startup and matching performance differences become obvious.
3. Customizable GEO database sources, allowing you to point at community-maintained GeoIP2/GeoSite data repositories instead of relying on the core's built-in, fixed version.

For everyday users, the practical result is that clients built on the mihomo core usually show richer behavior options and shorter update cycles in their "rule providers" settings, while clients on the original core tend to have rule updates tied to the release of the entire client.

TUN mode and the network stack: mihomo's under-the-hood improvements

TUN mode lets Clash take over system-wide traffic instead of being limited to apps that support proxy settings, like browsers. The original core's TUN support is comparatively basic and relies on manually configuring the system routing table; mihomo has made a number of improvements at this layer:

• Built-in automatic route management — routing entries are written automatically after the virtual network adapter is created and cleaned up on exit, reducing the odds of manual-configuration errors.
• Support for switching between the gVisor userspace stack and the native system stack — the former offers better compatibility, the latter better performance on some platforms, so you can choose based on your needs.
• Improved coordination between DNS hijacking and the Fake-IP pool and TUN mode, reducing connection failures caused by inconsistent DNS resolution paths.
• Optimized handling of virtual network adapter permissions on platforms like Android and macOS, lowering the chance of connections being interrupted at the system level.

This is also why almost every client that needs "full transparent proxying" or "taking over all system traffic" defaults to the mihomo core — TUN mode stability directly affects day-to-day usability.

RESTful API and configuration capability enhancements

Both cores provide an HTTP-based external control interface (typically listening on an address like 127.0.0.1:9090) for client UIs to query proxy status, switch nodes, and view logs. mihomo extends this API further:

• Additional fine-grained endpoints — for example, querying latency by group, or triggering an update for a single rule provider without reloading the entire configuration.
• Support for advanced matching methods such as Script rules and Lua-based logic, letting you write simple scripted logic in a rule file instead of only listing static rules.
• Enhanced provider override capabilities, letting you adjust certain fields (such as forcing UDP or changing the speed-test URL) through a local override without modifying the subscription itself.

These capabilities mainly target advanced users and client developers — regular users don't need to call the API directly, but client-side settings like "customizable speed-test method" or "a proxy group supports a script-based selector" are usually a direct result of these API extensions.

Which core do mainstream clients ship with?

When choosing a client, the core version sets the ceiling on what it can do. The table below lists common clients and the core they use, for a quick reference:

Note that a given client project can also migrate cores across versions — for example, moving from relying on the original core to bundling mihomo. Checking the client's release notes or the "core version" field on the settings page before downloading is the most reliable way to confirm actual capability, more accurate than judging by the client's name alone.

Which one should you choose?

If your subscription nodes use newer protocols like Hysteria2, TUIC, or WireGuard, or you need a stable full-system TUN mode and more flexible rule-set updates, choosing a client built on the mihomo core is basically the only sensible option. If you're only using classic protocols like Shadowsocks or VMess, and you're already comfortable with a particular client's interface and workflow, a client on the original core can still meet basic routing and switching needs — there's no need to force a migration.

Both cores are released under the GPL-3.0 license, and their configuration syntax is highly compatible — most config.yaml files can be migrated between them directly. It's the parts involving newer protocols or newer rule syntax that the original core simply won't recognize, which is worth confirming before switching clients.