Clash Core Comparison: Original Clash, Meta, and mihomo

The short version: Meta and mihomo share the same development lineage

Before migrating, check which core the client actually runs, then verify the subscription format. Clash.Meta was later renamed mihomo; they are not two unrelated config ecosystems. Most basic Clash YAML configs are a reasonable starting point. But a config that uses mihomo-specific fields is not guaranteed to work with an older Clash core.

The core parses config, matches rules, and establishes proxy connections. The client handles the interface, subscription management, and system permissions. Different releases of the same client may bundle different cores, so having “Clash” installed does not tell you which protocols it supports.

Names, maintenance status, and config compatibility

How to check which core is running

1. Open the client’s About, Core, or startup log screen. Menu names vary by client; there is no single path that works on every phone.
2. Note the core name, full version number, device OS, and client version—not just the version shown in the app store.
3. On desktop, if you can run the core directly, use mihomo -v to check its version. This reports the specified executable, not the version bundled with a mobile app.

A note in an old config saying “Meta only” usually means it depends on enhanced features; it doesn’t mean you need to find an old installer named Meta. What matters is whether the target mihomo version supports the fields in use, not whether the names match.

Protocol differences: importing a node doesn’t mean it can connect

A protocol defines how the client communicates with a proxy server. Common protocols in original Clash configs include Shadowsocks, VMess, Trojan, SOCKS5, and HTTP proxies. mihomo builds on this foundation with support for VLESS, Hysteria2, TUIC, WireGuard, and more, though exact support depends on the core version and platform.

New protocols also require checking transport settings

• VLESS and Reality: VLESS is a protocol; Reality is a related TLS security mechanism. Seeing type: vless isn’t enough. Check the transport required by the server, servername, the Reality public key, and other parameters.
• Hysteria2 and TUIC: Both use UDP-based transport. If UDP is blocked on your network, switching to a core that supports these protocols won’t fix the underlying connectivity issue.
• Shadowsocks: Check the cipher encryption method as well as the protocol name. Don’t assume an older core supports a newer method just because both are SS nodes.

For “unsupported proxy type” errors, check the config’s type and the core version first. For handshake failures or timeouts, also check the server address, port, device time, authentication parameters, and network conditions. Not every connection failure is a core compatibility issue, and disabling certificate verification is not a substitute for troubleshooting.

Rule differences: similar basics, but check extensions individually

Rules are evaluated from top to bottom; the matching rule is handled by its assigned policy. DOMAIN matches a specific domain, DOMAIN-SUFFIX matches a domain and its subdomains, IP-CIDR matches an address range, and MATCH acts as the final catch-all. These fundamentals are broadly consistent across branches.

Rule providers are more than just links to rule lists

rule-providers declares an external rule set, which is then referenced by RULE-SET. Both historical Premium and mihomo support this feature, but that doesn’t mean every original open-source build can read these providers. When migrating, check the provider type, file format, and content type.

• behavior: domain indicates a set of domain rules; ipcidr indicates a set of address ranges; and classical contains entries with rule types.
• Traditional YAML rule sets commonly use a payload list. Plain-text and mihomo MRS binary formats require support in the target core; changing the file extension alone won’t work.
• Process-based rules depend on process information provided by the operating system. On Android, app routing may also be implemented by the client through VpnService’s app list; this is not the same as desktop process rules.

When migrating from Premium, check script separately. Legacy script config is not a general compatibility interface for mihomo. A safer approach is to identify what each script’s conditions do, rewrite them using rules, logical rules, or sub-rules supported by the target version, and test each one.

TUN and mobile VPN: distinguish core features from system-level routing

TUN routes network traffic through a virtual network interface. This can send traffic from apps that ignore system proxy settings to the proxy core. Historically, TUN was a key feature of enhanced lines such as Clash Premium and Meta; that doesn’t mean every original open-source Clash build includes the same implementation.

Android clients typically use VpnService—the VPN interface provided by the OS—to get permission to route traffic. Whether the system prompts for VPN access, which apps use the tunnel, and whether the service keeps running in the background depend on both the client and OS restrictions. Switching cores won’t grant these permissions automatically.

Understanding a mihomo TUN config snippet

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

This illustrates fields for a common desktop setup; it is not a complete config to copy verbatim on a phone. auto-route configures related routes automatically, auto-detect-interface detects the outbound interface, and stack selects the network stack implementation. Permissions, routing behavior, and available options depend on the target OS and core version.

Config migration: get a basic config working before restoring DNS and overrides

YAML uses indentation to express structure. A file that parses is only structurally readable; some unknown fields may be ignored, so parsing does not prove the expected features are working. Validate a migration using startup logs, connection records, and actual rule matches.

Step 1: Prepare a config you can roll back to

1. Keep the original subscription URL, a copy of the current config, and the client’s override content. Subscription URLs are sensitive; hide credentials before sharing screenshots or logs.
2. Add a separate config in the new client instead of overwriting the file used by the old client.
3. Make sure the subscription service returns YAML that Clash or mihomo can read—not another client’s format or text containing only share links.

Step 2: Isolate issues with a minimal config

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

proxies: []

proxy-groups:
  - name: MANUAL
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,MANUAL

This example checks config loading, ports, and rule flow only; all traffic ultimately goes direct, with no proxy exit. mixed-port: 7890 means the same listening port accepts both HTTP and SOCKS proxy connections. Whether other apps on your phone use this port still depends on VPN routing or each app’s proxy settings.

Once the config loads, add real nodes and policy groups using the client’s merge or override feature, or in a local test copy. Policy group names must exactly match those referenced by rules. For example, if a rule uses PROXY but the config only defines MANUAL, rename one to match; the core won’t infer the intended name.

Step 3: Restore DNS without changing too much at once

• Keep the subscription’s original dns settings at first. Confirm the basic connection works before deciding what to override.
• If you use enhanced-mode: fake-ip, note that it returns virtual addresses for the core to map. The 198.18.0.1/16 range is not a real public IP address belonging to a remote server.
• Fields such as nameserver and proxy-server-nameserver serve different purposes. If resolving a proxy server’s domain depends on a proxy connection that has not yet been established, you may create a dependency loop.
• After changing Fake-IP mode, clear the client’s DNS cache and restart test apps if needed, so old cache entries don’t mask the actual result.

Migration checks: troubleshoot by error layer

On desktop, if you can run the core directly, use mihomo -t -f config.yaml to check the specified file. Passing this check does not mean the server is reachable or that the client is using that file. On mobile, also verify the active config and make sure overrides still apply after subscription updates.

Run at least three tests: open a site that should go direct, open a destination that should use the proxy, and reconnect after locking the screen. Check rule matches, exit selection, and background connectivity separately. For newer protocols or enhanced rules, choose a client with a clearly stated core version and a reliable changelog. Even with a basic config, keep a backup and migrate gradually instead of replacing all network settings at once.