mihomo Core vs. Classic Clash Core: New Protocols, TUN Mode, and Config Compatibility

How the Core Split Happened: Why mihomo Exists

The classic Clash core was originally developed by Dreamacro and served for years as the de facto standard implementation in the Clash ecosystem, covering mainstream protocols like Shadowsocks, Vmess, and Trojan, with its rule engine and config format becoming the baseline that many later clients built on. Around 2023, the original author's account and related code repositories were taken down, and updates to the classic core stopped as a result.

The community picked up development under the Clash Meta fork, which was later renamed mihomo. This wasn't a simple rebrand — new protocols and features have continued to be merged on top of the original codebase, gradually forming an implementation whose feature set clearly exceeds the classic version. Today, the underlying core of mainstream Clash-style clients — including Clash Verge, the successors to Clash for Windows, and most mobile clients — has largely switched to mihomo, with the classic core surviving only in some older, unmaintained clients.

Understanding this history has one practical implication: if you're using a client that's still labeled "Clash core" but hasn't been updated in a long time, it's very likely running the classic core, and its protocol support will clearly lag behind what mainstream node providers currently offer.

Protocol Support Comparison

Protocol support is the most immediately obvious difference between the two. The classic core's supported protocols are essentially frozen at whatever state they were in before maintenance stopped, while mihomo has kept adding to that list, and its current coverage is noticeably broader.

VLESS and Hysteria2 are the two protocols whose usage among node providers has grown fastest over the past couple of years. VLESS is commonly paired with XTLS or Reality transport to resist traffic fingerprinting; Hysteria2 is built on QUIC and tends to deliver more stable throughput than traditional TCP-based protocols on lossy, high-latency, or otherwise unreliable links. If your subscription includes nodes using either of these protocols, the classic core will simply fail to parse them or mark the nodes as unavailable — you'll need a client running the mihomo core to connect at all.

TUN Mode: From External Plugin to Built-In Capability

TUN mode (also called virtual network adapter mode) means the core creates a virtual network interface at the system level, intercepting all or a defined range of system traffic and routing it through the proxy rules, rather than relying on application-level system proxy settings. The advantage is broader coverage: apps that don't respect system proxy settings, certain game clients, and network requests made by system-level services can all be brought under routing control.

The classic Clash core never included TUN capability on its own; early workarounds required extra helper programs or system-level drivers to achieve a similar effect, with a higher configuration burden and poor cross-platform consistency — Windows, macOS, and Linux each needed different setups.

mihomo has TUN mode built in as a native core feature, configured directly under the tun field in the core config file, with no need for extra drivers or plugins (some platforms still require the system to grant permission to create a virtual network adapter, which is just a normal system-level authorization step). A typical mihomo TUN config snippet looks like this:

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

The stack field can be set to different network stack implementations such as system or gvisor, each with its own trade-offs between compatibility and performance; enabling auto-route lets the core automatically take over the system routing table, avoiding the need to configure routing rules by hand. This is a capability the classic core simply doesn't have, and it's one of the direct reasons many users move from the classic core to mihomo.

Rule Engine and Rule Set Enhancements

Rule-based routing is the core mechanism of Clash-style clients: matching conditions like domain names, IP ranges, or process names determine which proxy node a connection goes through, or whether it connects directly. The classic core's rule types are concentrated on basic categories like DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD, IP-CIDR, and GEOIP, and its Rule Provider mechanism is relatively simple.

mihomo builds on this with several enhancements:

• Expanded rule set formats: alongside the original YAML list format, mihomo adds support for MRS (mihomo's own binary rule set format), which is smaller and loads faster — well suited to large rule sets.
• Logical rules: support for combinators like AND, OR, and NOT, letting multiple matching conditions be combined into a single rule, which reduces rule count and improves maintainability.
• Process-matching rules: rule types such as PROCESS-NAME and PROCESS-PATH, which route connections based on the process name or path that initiated them, had limited support in the classic core but are much more complete under mihomo — particularly useful for per-app routing on desktop.
• Subnet rules and script rules: further refine matching dimensions, making it easier to handle complex routing strategies.

For users who already rely on rule sets (rather than writing every rule directly into the main config file), this change is usually invisible — the rule set URL itself isn't affected by which core you run. But once a rule set author starts using mihomo-specific rule types or the MRS format, the classic core will fail to parse that rule set or the rules will stop working.

Config Compatibility and Migration Notes

mihomo was designed to maintain a high degree of backward compatibility with the classic Clash config format — the top-level structure (proxies, proxy-groups, rules, and other top-level fields) is largely the same, meaning most classic config files will load and run fine under a mihomo client. That said, there are a few things worth checking when moving from the classic core to mihomo:

1. New protocol nodes only work if the client supports them: when a config file contains nodes using protocols the classic core doesn't support, such as VLESS or Hysteria2, the classic core will skip them or throw an error outright. Switching to mihomo is what makes those nodes appear correctly in the proxy group list.
2. Some field names differ slightly: a handful of fields have more precise names or new optional parameters under mihomo — for example, TUN-related settings are entirely new fields introduced by mihomo that don't exist in classic configs, so they need to be added based on mihomo's documentation rather than "copied over" from an old config.
3. Provider fetching behavior differs slightly: mihomo has refined the health-check and update logic for Proxy Providers and Rule Providers, with more robust retry behavior on fetch failures, but the core fields (url, interval, path) remain unchanged and don't need editing.
4. GEOIP database format: mihomo defaults to its own mihomo geoip database, which isn't fully identical in format to the GeoLite2-series database used by the classic core. On first switch, the client will normally download the matching database file automatically; if network conditions cause that download to fail, GEOIP-based rules will temporarily stop working, and direct/proxy decisions will fall back to other rule types.

For the vast majority of regular users, the migration path is actually simple: just switch to a client build that supports the mihomo core, and import your existing config file or subscription link as-is — no manual field edits required. The format details only matter if you're writing complex rules by hand or using mihomo-specific syntax like logical rules.

How to Decide: Should You Switch to the mihomo Core

Based on the comparison above, here are a few practical guidelines:

• If your subscription includes nodes using newer protocols like VLESS, Hysteria2, or TUIC, you must use the mihomo core — the classic core cannot parse these nodes at all.
• If you need TUN mode for system-wide transparent proxying, especially to cover games or system-level services that don't respect system proxy settings, the mihomo core is the only option with native support.
• If you only use basic protocols like Shadowsocks, Vmess, or Trojan and don't need TUN mode, a classic config will work under either core — but since the classic core no longer receives updates, it's still worth switching to the actively maintained mihomo for security fixes and stability improvements over the long run.
• If a rule set author has already moved to mihomo-specific syntax or the MRS format, continuing to use the classic core will cause that rule set to fail to load — switching cores is the only fix in that case.

Most mainstream Clash-style clients now ship with the mihomo core integrated by default and provide a core version management option in settings, letting you switch between mihomo versions without downloading core files separately. New users can simply install a currently maintained client and generally won't run into any core-selection issues at all; users still running old clients built on the classic core should evaluate their protocol and feature needs and plan to migrate to a mihomo-based alternative sooner rather than later.