Clash Core Versions Explained: Original Clash, Premium, Meta, and mihomo

First, distinguish the client, core, and subscription configuration

When choosing a Clash setup, it’s easy to confuse the client version shown in the app with the core version that actually handles connections. The client manages subscriptions, tray menus, system proxy settings, and configuration editing. The core reads YAML, resolves DNS, matches rules, and establishes proxy connections. They can be updated independently, and their names don’t always match.

A subscription is the source of the configuration. It may provide nodes alone, or include proxy groups, rules, DNS, and TUN settings as well. The same subscription can behave differently in two clients because their cores support different features, or because a client adds overrides after import. The .yaml file extension alone doesn’t tell you which core branch the configuration supports.

• Client version: Check this for interface features, OS compatibility, and release notes.
• Core version: Check this for protocol support, configuration fields, TUN implementation, and rule capabilities.
• Configuration format: Check which features the subscription actually uses; the label “Clash subscription” alone doesn’t guarantee compatibility.

A timeline of the core branches—not four successive upgrades

Original Clash: an open-source rule-based proxy core

“Original Clash” usually refers to the open-source core from the Dreamacro/Clash project. It established the familiar configuration structure, including proxies, proxy-groups, and rules. Rules are evaluated in order, and the first match selects the corresponding outbound. This approach carried over to later branches.

Following project changes around November 2023, the original core was no longer maintained through its former official channels. Original Clash installers, mirror repositories, and third-party rebuilds still available today should not be mistaken for a resumption of releases by the original author. The core remains useful for understanding legacy configurations, but it shouldn’t be the default reference for evaluating modern protocol support.

Clash Premium: a discontinued enhanced core

Premium was a closed-source enhanced version released by the original project, not a paid tier of a graphical client. It added features such as TUN, rule providers, and scripts beyond the original core. “Premium” refers to the core branch; it says nothing about whether a subscription service charges a fee.

Premium has also stopped receiving updates through its original channels. The script features and Premium-specific options found in older guides should not be treated as standard mihomo syntax. When migrating, check the target core’s documentation and replace settings one by one—renaming the executable isn’t enough.

Clash Meta: a community branch from the original core

Clash Meta is a community branch developed from the original core. It existed alongside the original and Premium branches from early on; it didn’t appear only after the original project stopped updating. Meta expanded protocol and configuration support over time and developed its own maintenance path. The “Meta core” option in older clients and Meta-format subscriptions generally refer to this branch.

mihomo: the name now used for the Meta project

Clash Meta was later renamed mihomo, and the project is generally maintained under the MetaCubeX/mihomo name. It isn’t an official continuation of original Clash or the next closed-source generation of Premium. This distinction matters when deciding whether a Meta configuration will work with mihomo: the basic structure is often reusable, but support for individual fields depends on the version in use.

A name change doesn’t give old binaries new features. Some clients still label the menu option “Meta” while bundling mihomo; older installers may contain an early Meta build. Check the runtime logs or core version output to confirm what’s actually running.

Feature differences: compare what your configuration needs

Protocol support isn’t just a matter of comparing names. For example, if a node uses type: hysteria2, an older core may fail during loading with an “unsupported proxy type” error. Even if it recognizes the protocol, authentication parameters, transport options, or TLS settings may still differ from the server’s requirements. First confirm that the configuration loads, then investigate connection issues.

Enabling TUN doesn’t automatically send all traffic through a proxy. TUN changes how traffic reaches the core; after that, rules can still route it to DIRECT, a proxy group, or a reject action. System proxy and TUN are two different ways to capture traffic, not “normal” and “boosted” speed settings.

Which cores are commonly bundled with popular clients

Use this table to identify common combinations, not as a substitute for the installer’s release notes. Different versions of a client with the same name may bundle different cores, and distributors can change how they package them.

Windows, macOS, and Linux

For a new desktop setup, start with a client that clearly documents its use of mihomo and provides an installer for your system architecture. On macOS, distinguish Apple Silicon from Intel. On Linux, check whether you need x86_64, ARM64, or another architecture. A mismatch can prevent the app from launching and has nothing to do with whether your subscription is valid.

Android and iOS

On Android, VPN permission determines whether an app can capture device traffic, but having that permission doesn’t mean the core supports every field in your subscription. On iOS, don’t look for a replaceable core with the same name as desktop Clash. Different network tools use their own configuration formats and implementations. Confirm that the app can import your subscription format; support for the same proxy protocol doesn’t guarantee that the entire YAML file will work.

Identify the core: check its version, then test the configuration

Step 1: Find the file that’s actually running

Start with the client’s core information and startup logs. For a command-line setup, run the version command on the file the service actually launches. Don’t test a new file in your downloads folder while the background service continues to run an older binary from another path.

# Linux / macOS: run this from the directory containing the core binary
./mihomo -v

# Windows PowerShell: run this from the directory containing the core binary
.\mihomo.exe -v

Record the core name, version, build information, and file path shown in the output. These details are more useful when reporting an issue than saying “it’s updated to the latest version.” Clients and cores use separate version schemes, so you can’t determine which is newer by comparing their version numbers.

Step 2: Validate the YAML with the target core

# Linux / macOS
./mihomo -t -f ./config.yaml

# Windows PowerShell
.\mihomo.exe -t -f .\config.yaml

Use -t to test the configuration and -f to specify the configuration file. If it references rule files or other resources using relative paths, check the working directory too; for service deployments, use -d to specify the configuration directory. A successful test means the configuration passed the relevant loading checks. It doesn’t guarantee that every remote node, rule download URL, or DNS upstream is reachable.

Step 3: Use a minimal configuration to isolate other variables

The example below is for checking configuration structure and local listening only. It opens a mixed proxy port, 7890, on your machine; it has no remote nodes and doesn’t enable TUN. If the client is already using that port, stop the existing instance or choose an unused port in the test file.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: Manual selection
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,Manual selection

If this configuration starts but the full subscription doesn’t, focus on subscription fields, external resources, proxy group references, and client overrides. Don’t change DNS, enable TUN, and replace every rule all at once. Change one category at a time so you can compare the logs.

Migrating from Premium or older Meta builds to mihomo

1. Preserve the old setup: Back up the original subscription, local configuration, overrides, and core version details. Backups may contain node passwords and subscription tokens, so don’t upload them publicly.
2. Check proxy types: Review every type and its parameters. Prefer a mihomo-format subscription explicitly provided by your subscription service; if only the older “Clash format” is available, test the configuration first.
3. Check rules and scripts: Basic rules are usually easier to migrate. Premium script logic needs separate review; don’t assume it will behave the same in mihomo.
4. Test a regular proxy first: Leave TUN off. Confirm that the local port is listening, proxy groups work, and representative websites load before checking DNS and virtual network adapter routing.
5. Restore overrides one by one: Re-enable rule providers, DNS, custom routing, and TUN in sequence. Retest and check the startup logs after each change.

If a regular proxy works but fails with TUN enabled, check administrator permissions, routes, DNS interception, and conflicts with other VPNs. Don’t immediately blame “mihomo subscription incompatibility.” If startup logs already show unknown fields, unsupported protocols, or missing proxy groups, fix the configuration first; toggling the system proxy won’t resolve loading errors.

Choosing a core: keep the features you actually need

• New setup, newer protocols: Choose a client that clearly bundles mihomo and is actively maintained, then check the minimum core version required by your protocol.
• Need TUN: Check how the client handles permissions, OS support, and core configuration—not just whether the download page mentions “TUN.”
• Reproducing a legacy setup: Keep the matching old core and a copy of its configuration. Don’t treat historical behavior as the current standard.
• Limited device resources: Pay attention to actual rule count, DNS cache, and connection count; a branch name alone won’t tell you how much memory it uses.
• Less maintenance: Choose a client with clear release notes, visible core version information, and straightforward backup and rollback options. There’s no need to chase every test build.

Use this order: confirm your OS and architecture, identify the core bundled with the client, validate the subscription format, and then enable extras such as TUN. For help comparing clients, see the client selection guide. To check DNS and virtual network adapter settings, read the DNS configuration guide and TUN configuration guide. Keep the client version, core version, and configuration source recorded separately to make future upgrades and troubleshooting easier.