mihomo Core vs. the Original Clash Core: New Protocols and Rule Capabilities Explained

What the core is, and how it relates to the client interface

In the Clash ecosystem, the "client" and the "core" are two separate pieces. The core is a headless executable responsible for parsing the config file, establishing proxy connections, applying routing rules, handling DNS queries, and exposing status and control endpoints through a local HTTP API (usually listening on 127.0.0.1:9090). The client (Clash Plus, Clash Verge Rev, FlClash, and others) is the graphical shell wrapped around the core, handling subscription management, node display, and toggle switches — all actual proxy work is forwarded to the core underneath.

This layered structure sets up a key fact: swapping a client's skin is easy, but replacing its core is not. What users usually notice as "how good the interface feels" is a client-level difference, while "which protocols are supported" and "which rules can even be written" depend entirely on the core version. That's why it's worth pulling the core out for separate analysis when discussing the Clash ecosystem.

Where the original Clash core stands: development stopped, repo archived

The original Clash core once maintained by the community (the repo was usually named Clash or Clash Premium) has stopped receiving updates — the repository is archived, no longer accepts new issues or PRs, and will not see new releases. The reason is similar to the background behind the Clash for Windows GUI client being taken down: it involves the original author's account and related repositories being removed.

By the time it stopped receiving updates, the original core's capabilities were roughly at this level:

• Protocol support: mainstream protocols like Shadowsocks, ShadowsocksR, VMess, Trojan, and Snell, but not Hysteria, TUIC, or other protocols that emerged later.
• Rule types: basic rules such as DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD, IP-CIDR, GEOIP, and MATCH, with no rule-providers mechanism for remote rule sets and no process-level rules.
• DNS capability: basic DNS forwarding and anti-pollution protection, without fine-grained Fake-IP management or sniffer capability.
• TUN mode: unsupported or very limited in early versions, with poor cross-platform consistency.

For ordinary users, the original core can still run existing old config files and still connect to common nodes — it won't suddenly stop working. But it will not gain new features, and any bugs encountered will not get an official fix, which is a real risk for long-term use as functionality falls behind.

What mihomo (Clash Meta) is, and how it relates to the original core

mihomo's predecessor was the community fork project Clash Meta. After the original core's development stalled, a different group of contributors continued building on the original codebase, continuously merging in new protocols, new rule types, and performance improvements, and it was later formally renamed mihomo. Nearly every desktop and mobile client that is still actively updated today — including Clash Plus, Clash Verge Rev, FlClash, and the follow-on forks of Clash Meta for Android — runs on the mihomo core underneath, not the original core.

One point worth clarifying: mihomo is not a brand-new project built from scratch. Its config file syntax remains highly compatible with the original core, and the vast majority of original config fields (port, mode, proxies, proxy-groups, rules, and so on) can be kept as-is. What mihomo does on top of that is "extend," not "replace." That's why, when migrating an old config file to a client running the mihomo core, most scenarios don't require a rewrite — you just add the new fields to unlock the new capabilities.

Protocol support differences: which protocols the original core can't run

Protocol support is the most visible difference between the two. mihomo adds support for several transport protocols that emerged later, on top of the original protocol set, each with its own strengths in latency and censorship resistance:

If a Hysteria2 or TUIC node shows up in a subscription's node list, the original core will simply fail to parse it or skip it, showing up as "a few nodes missing from the list" or a config error in the client. The root cause of this kind of issue is usually not a config mistake — it's an outdated core version, which is resolved by switching to a client built on mihomo.

Rule capability differences: rule-providers and finer-grained matching

The rule system is one of the areas where mihomo improves the most over the original core. The original core's rules field could only list fixed rules one by one, and once the rule count grew large, the config file became extremely bloated and hard to maintain. mihomo introduced the rule-providers mechanism, which lets rule sets be extracted into separate remote files, referenced from the main config like this:

rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://example.com/rules/reject.txt"
    path: ./rules/reject.txt
    interval: 86400

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

Rule set files auto-refresh on the cycle set by interval. When rule maintainers update the categorized rules, the client syncs silently in the background — no need to manually swap out the whole config file. This is the technical foundation that lets today's mainstream "one-click subscription" config solutions keep their rules accurate over the long term.

Beyond that, mihomo also adds rule types that the original core never had:

• PROCESS-NAME / PROCESS-PATH: route traffic by the name or path of the process that opened the connection, making it possible to send only a specific app through the proxy while everything else connects directly.
• IP-CIDR6: matches IPv6 address ranges, closing the gap left by the original core's lack of IPv6 support.
• SCRIPT (partial implementation): lets simple scripting logic decide routing conditions, useful for complex scenarios.
• SUB-RULE: nested references to sub-rule sets, making it easier to break a large rule table into reusable modules.

For most home users, process-level rules matter because they allow precise control over "which app goes through the proxy," avoiding the misclassification issues that come from rules that can only work at the domain/IP level.

DNS and Fake-IP capability differences

DNS handling is another module where the difference is very noticeable in day-to-day use. The original core's DNS module was fairly basic, mainly addressing the problem of "DNS pollution resolving to the wrong IP." mihomo builds on this with a more complete Fake-IP mechanism and sniffer capability:

• Fake-IP mode: assigns each domain an address within a virtual IP range. The app gets the fake IP first, and the core restores the original domain during the actual connection stage to make the routing decision. This cuts down the round-trip latency of "resolve first, then decide routing" that comes with traditional DNS mode, which is especially helpful for domain-based routing rules.
• Sniffer: for connections that match IP-CIDR or GEOIP rules but lack the corresponding domain information, mihomo can sniff the target domain out of the TLS SNI or HTTP Host field and then apply domain-based rules, closing the gap in scenarios where Fake-IP and rules don't line up.
• Split DNS: lets you configure different upstream DNS servers for different network contexts (in mainland China / outside China) and use fallback-filter to judge whether the result is trustworthy — the original core has noticeably fewer configuration options here.

API capability and client integration differences

The HTTP API exposed by the core determines which real-time interactions the client can offer. The original core's API covers basic capabilities like node lists, connection status, and log streaming. mihomo extends this with more queryable and controllable endpoints, including:

• Latency test results per proxy group, with support for testing multiple policy groups concurrently.
• Detailed per-connection traffic statistics, breaking out upload/download byte counts and real-time rates.
• Rule hit tracing, letting you see exactly which rule a given connection matched and which proxy it used.
• A config hot-reload endpoint, so switching subscriptions or editing rules takes effect without restarting the core.

This also explains why today's clients can show "real-time refresh of which rule each connection hit" on the connection detail page — that kind of interface entirely depends on whether the underlying API provides the corresponding data, and the original core's API doesn't cover enough ground to support it.

Do old config files need a rewrite to move to mihomo

Because mihomo maintains solid backward compatibility with the original core at the field level, most old config files can be imported and run as-is. The typical migration steps are about "adding," not "rewriting":

1. Import and test directly

   Add the subscription link or local config file as-is to a client built on mihomo, and check first whether it connects and routes correctly — most base fields need no changes at all.

2. Check for protocol parsing errors

   If the log shows a node failing to parse, it's usually a field mismatch caused by a protocol type that's too new or too old for that build. Skip that node first and check whether everything else works fine.

3. Add the new fields

   Add mihomo-specific fields such as rule-providers, sniffer, and tun as needed, to make full use of the new core's capabilities instead of stopping at the bare minimum of "it runs."

4. Review policy group testing logic

   mihomo's url-test and fallback policy groups have refined timeout handling and health checks — it's worth checking whether the interval and tolerance parameters still behave the way you expect.

The only case that genuinely needs a rewrite rather than a direct migration is when a config file relies on a private field that the original core never supported and that was custom-added by a third-party modified fork. This is fairly rare, and when it comes up, check field by field against the official mihomo documentation.

How to choose: practical advice at the core level

Summed up in one line: the original core is archived and frozen at its pre-stop feature level, with no new protocols or rule capabilities coming; mihomo is the actively maintained core whose protocol and rule capabilities keep expanding, while staying compatible with original configs. So from a core-selection standpoint, there's no reason to give up new features just to "stick with the original" — choosing a client built on mihomo underneath is simply the less troublesome path.

To make a quick judgment, check the following to see what core your current client is running:

• Look at the client's "About" or "Version Info" page — it usually lists the core name and version number, and a label of mihomo or Meta indicates the newer core.
• Try adding a Hysteria2 or TUIC node — if it's recognized correctly and shows a latency reading, the core supports the new protocols.
• Check whether there's a setting for rule-providers or automatic rule set updates — this is a direct indicator of whether the rule system belongs to the mihomo family.

For most users, core differences don't need manual intervention — just make sure the client you pick relies on the continuously updated mihomo underneath, and future protocol and rule improvements will land automatically with client updates, with no need to track the core's own upgrade cadence separately.