Clash Core Differences: Original Clash, Meta, and mihomo | Version History & Compatibility

First, distinguish the core, the client, and the config file

The core handles proxy connections, DNS, and rule matching; the client provides an interface for managing these features. A client may switch cores in an update or let users choose one manually. So a software name containing Clash does not tell you which protocols it supports.

The config file is the input read by the core. Sharing the .yaml extension only means the file uses YAML syntax; it does not mean different cores can all recognize its proxy types, rule types, and extended fields.

• Client version: Helps identify UI, system proxy, subscription management, and installation issues.
• Core name and version: Determine whether VLESS, Hysteria2, TUN, and specific config fields are available.
• Config generation target: Check whether a subscription converter outputs a config for original Clash or one intended for Meta/mihomo.

How the cores evolved: original Clash, Premium, Meta, and mihomo

Original Clash and Clash Premium are separate branches with different capabilities

The original Clash usually refers to Clash in the Dreamacro project. Compatibility discussions should also distinguish the open-source core from the Premium core. Premium offered additional features such as TUN, rule providers, and scripting; those features should not be treated as capabilities shared by the open-source core.

The original project stopped receiving public maintenance in November 2023. Existing older builds did not stop working overnight, but they should not be expected to gain new protocols, fields, or compatibility fixes.

Clash Meta is an extended fork; mihomo is its later name

Clash Meta expanded Clash with support for more protocols, DNS, routing, and connection handling. The project was later renamed mihomo. These are successive stages of the same project, not two programs that must run together, and you do not need to install Meta before using mihomo.

“Meta core” in older guides, Meta comments in config files, and mihomo in newer clients often refer to this project lineage. Versions still matter, though: an early Meta build is not automatically equivalent to a newer mihomo build.

Protocol support: parsing a node matters more than importing it in the UI

The type field in the config specifies the proxy protocol. A client may save a subscription successfully, only for the core to report an unsupported proxy type at startup. Changing the proxy mode or listening port will not fix a protocol parsing issue.

REALITY is not a standalone proxy type

In typical mihomo configs, REALITY is a security handshake setting for VLESS nodes—not a proxy type to enter as type: reality. Check that type: vless, tls, servername, and reality-opts match the server. VLESS support does not guarantee support for every transport combination or newer parameter.

Subscription conversion cannot add new protocols to an old core

A converter can reorder YAML, create proxy groups, and map URI parameters to fields, but it cannot add Hysteria2 support to the original core. If nodes disappear from the converted list, first check whether the conversion target filters unsupported protocols instead of assuming the subscription is broken.

Subscription URLs often contain access tokens. When troubleshooting, share only a redacted single-node config, the error message, and the core version. Never post a full subscription link in a public forum.

Rules and fields: similar basics, but extensions don’t work in reverse

mixed-port, mode, proxies, proxy-groups, and rules are common config entry points. Basic rules such as DOMAIN, DOMAIN-SUFFIX, IP-CIDR, and MATCH are also widely shared across cores, but that doesn’t mean you can copy an entire config freely between them.

• Rule providers: rule-providers and RULE-SET are used in Premium and mihomo, but that does not mean they are supported by the original open-source build.
• Extended rules: Check the specific rule names and version requirements for mihomo features such as logical combinations, process paths, and inbound-related rules.
• Rule file formats: Plain text, YAML, and mihomo's MRS format are not interchangeable just by changing a file extension.
• Scripts: Premium's script config is not a general-purpose compatibility interface for mihomo. Migration usually requires rewriting it as rules or using another supported mechanism.
• DNS extensions: fake-ip, DNS policies, and sniffing are separate layers of configuration. Field names and defaults in older examples should not be assumed to match current conventions.

The test config below deliberately includes only basic fields. It listens on localhost port 7890, uses rule mode, and sends traffic to DIRECT. It checks that the core can load and accept local proxy connections; it does not include a remote proxy node.

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

proxies: []

proxy-groups:
  - name: Proxy Selection
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,Proxy Selection
  - MATCH,DIRECT

Once the basic config starts successfully, add nodes, DNS, rule providers, and TUN one at a time. Importing hundreds of lines of extended config at once can introduce errors from fields, file paths, and external resources, making troubleshooting much harder.

TUN and DNS: core support is only one prerequisite

TUN receives traffic routed through a virtual network interface, making it useful for apps that ignore system proxy settings. It is not a fourth proxy mode: with TUN enabled, rule, global, or direct still determines how traffic is handled.

The original open-source Clash and Premium differ significantly here. mihomo also supports TUN, but it requires cooperation from OS permissions, routing settings, and client integration. Desktop systems usually require administrator privileges or service mode; Android clients typically connect through the system VPN permission.

mihomo TUN config example

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

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

This is a config snippet, not a standalone config for every platform. 1053 is the core's example DNS listening port, while any:53 is the target for redirecting standard DNS traffic; they do not need to use the same port. The example upstream DNS server must be reachable on your network; otherwise, use an available resolver.

• stack: mixed is one of mihomo's optional network stack settings. Do not copy it directly into every older core.
• auto-route configures related routes automatically; it does not guarantee bypassing other VPNs, router policies, or firewall restrictions.
• auto-detect-interface automatically detects the outbound interface. On systems with multiple network adapters, check which interface is actually selected.
• An app's own HTTPS DNS requests may not be captured by any:53. Check the app's secure DNS settings and connection records separately.

If enabling TUN cuts off all network access, disable it first and check whether you can connect using only the local 7890 port. If basic proxying works but TUN does not, investigate permissions, routing, and DNS before replacing the subscription.

Matching clients to cores and checking core versions

A client name is only an initial clue; check the core actually running in the installed build. Some clients let you switch cores, use beta channels, or specify a custom binary path. The app version and core version may also advance independently.

If you have command-line access, query the binary directly

# Linux or macOS: run in the directory containing the actual core
./mihomo -v
./mihomo -t -f ./config.yaml

# Windows PowerShell: run in the directory containing the actual core
.\mihomo.exe -v
.\mihomo.exe -t -f .\config.yaml

Use -v to display version information and -t to test a config. The client may rename the binary, so use its actual filename. When testing rule providers or certificates that use relative paths, use the same working directory as the client; if needed, use -d to specify the config directory.

A passing test only means that this check found no issue preventing the config from loading. It does not confirm that remote nodes are reachable or TLS parameters are correct. If there is no command-line access, look for the core name and version in the client's About or Core page, or in startup logs. Menu locations vary by client.

Migration checklist: load first, connect next, then verify rules

1. Back up your current setup. Save the current config, subscription source, proxy group selections, and DNS and TUN settings. Keep a client environment you can roll back to.
2. Choose the right subscription target. For nodes using VLESS, REALITY, Hysteria2, and similar protocols, prefer a Meta/mihomo config explicitly provided by the service. Don't rely on the word “Clash” alone.
3. Test the final config. Clients may merge subscriptions, override files, and apply UI settings. Check the config actually passed to the core, not just the original downloaded YAML.
4. Verify basic connectivity. Temporarily disable TUN and test with a clearly specified local port. The system proxy, app proxy, and core listening port must match.
5. Verify rule matches. Check the domain, matched rule, and outbound policy in connection records so a wrongly selected proxy group isn't mistaken for a core compatibility issue.
6. Re-enable extensions one at a time. Turn on DNS policies, rule providers, sniffing, and TUN in sequence. Repeat the same connection test after each change.

For example, if the local mixed port is 7890, use the command below to specify the HTTP proxy explicitly and avoid results being affected by the system proxy setting. curl must be installed.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com

The example sets a 10-second connection timeout to limit how long it waits; it does not indicate measured latency. An HTTP response shows that the request went through the local proxy entry point. Check core connection records to confirm whether it used a remote node. With the basic config above, the request ultimately goes through DIRECT.

Before installing, see the client comparison guide. To check fields, consult the config reference. Always assess compatibility in this order: “actual core → config fields → runtime results,” not by guessing from the client name.