mihomo (Clash Meta) Core vs Original Clash: Key Differences

How the two cores relate to each other

The original Clash was written in Go by Dreamacro and released under the GPL-3.0 license. In November 2023, the author archived and deleted the repository, and development stopped for good at v1.18.0. The open-source edition supports HTTP and SOCKS inbound, Shadowsocks / ShadowsocksR / VMess / Trojan / Snell outbound, and a basic rule matching setup. TUN mode and script-based rules were only ever available in the closed-source Premium build and were never part of the open-source release.

mihomo is a community fork that picked up development from the original codebase. It started out as Clash.Meta and was renamed mihomo in late 2023, maintained by the MetaCubeX organization. It's also GPL-3.0 licensed and continues to ship regular updates. In short: the original is a frozen baseline, and mihomo is the project that carries the torch forward.

In practical terms: every client listed on our downloads page — Clash Verge Rev, Clash Nyanpasu, FlClash, ClashX Meta, and others — ships with mihomo built in. Clash for Windows, on the other hand, bundles the closed-source Premium core based on the original Clash, and it stopped receiving updates along with the client itself. When choosing a client, which core it uses matters far more than how the UI looks.

Protocol support: a generation apart

The list of outbound protocols supported by the original open-source Clash hasn't changed since 2023: Shadowsocks, ShadowsocksR, VMess, Trojan, Snell, SOCKS5, and HTTP. mihomo adds support for nearly every protocol that has emerged in the last three years:

• VLESS, including XTLS Vision flow control and Reality transport camouflage;
• Hysteria and Hysteria2, QUIC-based protocols with built-in congestion control;
• TUIC, another QUIC-family implementation;
• WireGuard, with direct support for standard WireGuard servers;
• SSH, AnyTLS, and other newer outbound types.

The practical impact is straightforward: if a subscription contains a vless:// node with reality parameters, or a node starting with hysteria2://, the original core simply can't parse it, and those nodes vanish from the list entirely. Import the same subscription into a mihomo-based client, and every node loads correctly. Most subscription providers now generate configs in mihomo's format by default, which is the most common reason people switch cores in the first place.

Rule system: from static lists to rule providers

In the original Clash, rules are static entries hardcoded into the config file, using types like DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD, GEOIP, IP-CIDR, and MATCH. Updating something like an ad-blocking list means replacing the entire config file.

mihomo expands the rule system into three layers:

• RULE-SET rule providers: reference remote or local rule files through rule-providers, with three behavior types — domain, ipcidr, and classical — plus an interval field for automatic updates, so you no longer need to swap out config files by hand;
• GEOSITE site categories: with geodata-mode enabled, GEOSITE rules can match against a site-category database, offering far finer granularity than country-based GEOIP matching;
• Logical and sub-rules: AND, OR, and NOT let you combine multiple conditions into a single rule, while SUB-RULES route traffic that matches a condition into a second rule chain for further filtering.

A typical mihomo rule configuration looks like this:

rule-providers:
  adblock:
    type: http
    behavior: domain
    url: "https://example.org/rules/adblock.yaml"
    path: ./ruleset/adblock.yaml
    interval: 86400

rules:
  - RULE-SET,adblock,REJECT
  - GEOSITE,category-ads-all,REJECT
  - AND,((NETWORK,UDP),(DST-PORT,443)),REJECT
  - MATCH,PROXY

mihomo also ships with a built-in sniffer: for connections that only expose a destination IP, it inspects the TLS SNI or HTTP Host to recover the actual domain name, then re-runs it through the rule matching logic. This solves the long-standing problem of apps bypassing domain-based rules by connecting directly to an IP. The original core has no equivalent feature.

Performance and resource usage

Both cores are written in Go, and single-connection throughput is roughly on par — you won't notice a difference during everyday browsing. The gap shows up in the finer details that come from ongoing maintenance: mihomo offers tcp-concurrent for concurrent dialing, unified-delay for a consistent latency-testing baseline, and more refined memory management tuning, along with continued fixes for compatibility issues on newer Windows and macOS releases.

The trade-off is a slightly higher baseline memory footprint as features accumulate — especially when loading multiple rule providers with behavior set to classical, where usage climbs noticeably. Rule providers using domain or ipcidr behavior are internally indexed and use far less memory. Favoring those two types when choosing rule sets is an effective way to keep memory usage in check.

The original core hasn't received a single fix or update since 2023. If you run into compatibility issues on a newer OS, there's no official fix coming — switching to an actively maintained core is the only real solution. TUN mode is a good example: the original open-source codebase never had TUN support at all, while mihomo includes it out of the box with a choice of system, gvisor, or mixed stacks. This alone is often the deciding factor for people who switch.

What to change when migrating to mihomo

The config structure is largely compatible — port, mixed-port, proxies, proxy-groups, and rules all follow the same syntax on both sides, so most existing configs will run as-is. A few things do need manual updates:

• DNS enhanced mode: newer mihomo builds have removed redir-host and support only fake-ip, so enhanced-mode: redir-host in older configs needs to be changed to fake-ip;
• Node fields: the interface-name and routing-mark fields under proxies have been removed — leaving them in will trigger startup warnings or get rejected outright, so it's safe to just delete them;
• Geo databases: mihomo uses its own geoip data file by default, with geo-update-interval for automatic updates; using GEOSITE rules requires enabling geodata-mode separately;
• Client-specific fields: cfw-* fields found in Clash for Windows configs are client-specific and don't need to carry over when switching clients.

Subscription compatibility flows in one direction: nodes using newer protocols (VLESS Reality, Hysteria2) will only ever show up in mihomo-format subscriptions, while existing Clash subscriptions work on mihomo pretty much as-is. In other words, switching cores won't break your current subscriptions — it just unlocks support for more node types.

How to check which core you're running

There are three ways to verify this:

1. Client UI: check the Settings or About page for the core version. If it's stuck at v1.18.0 from 2023, that's the original core; if the version string includes Meta or mihomo and the date keeps advancing, you're running mihomo.
2. External controller: open http://127.0.0.1:9090/version in a browser — if the meta field in the returned JSON is true, it's mihomo, e.g. {"version":"v1.19.0","meta":true}.
3. Command line: run the core binary directly with the -v flag — if the output starts with Mihomo Meta, you're running mihomo.

Bottom line: for a new setup, just pick a client that bundles mihomo — every actively maintained client on our downloads page already does. Keeping the original core around on an old machine is fine as a reference, but new protocols, new rule syntax, and OS compatibility fixes are all happening on the mihomo side only.