Clash Core Comparison: Original Clash, Clash.Meta, and mihomo

How the Names Relate: Original Clash, Premium, and the Meta Fork

To determine whether a Clash config can migrate, first distinguish the GUI client from the proxy core. The client manages subscriptions, tray menus, permission prompts, and config generation. The core listens on ports, resolves DNS, matches rules, and establishes outbound connections. A client with the same name may bundle different core versions. Being able to import YAML in the interface does not mean the core can process every field in it.

“Three generations of Clash cores: original Clash, Clash.Meta, and mihomo” is a useful search phrase, but not a strictly accurate project lineage. Clash.Meta is a fork developed from Clash; mihomo is the later project name used by that fork, not an entirely unrelated third implementation. Premium, meanwhile, is an enhanced version in the original Clash ecosystem and is not interchangeable with Meta.

1. Original Clash: The open-source core represented by Dreamacro/clash established the familiar YAML config structure, rule modes, proxy groups, and control interface.
2. Clash Premium: A closed-source enhanced core provided by the original author. Historically, it added capabilities such as TUN, rule providers, and scripts. Do not infer Premium's features from the open-source feature list alone.
3. Clash.Meta: A fork maintained by MetaCubeX that extends protocol, DNS, rule, and traffic interception capabilities.
4. mihomo: The name adopted by the continuing Meta fork. Older subscription templates, client options, and tutorials may still say Meta, so check the actual core version when assessing compatibility.

The original Clash and Premium release channels underwent a major change in late 2023. The Meta fork continued development and adopted the mihomo name in 2024. An older build may still launch, but that does not give it support for newer protocols or config fields.

Feature Comparison: Protocols, Rules, and Config Compatibility

The comparison below outlines general capabilities, not a feature-by-feature guarantee for every historical release. mihomo in particular has added protocols and config fields over time. If a subscription includes a type, check that your local core supports both that type and its associated parameters.

The same protocol name does not guarantee identical parameters

For example, a VMess node may use WebSocket, TLS, a service name, or request headers. VLESS may also use REALITY and specific flow-control parameters. REALITY is a security handshake capability for certain connections, not a standalone proxy protocol to enter arbitrarily as type. Changing only the node type while keeping incompatible transport parameters may get past parsing but fail during the handshake.

• Parse errors: First check the protocol type, field names, YAML indentation, and field data types.
• Handshake failures: Check the server address, port, credentials, TLS service name, transport, and server settings.
• Connection timeouts: Also check network reachability, UDP support, upstream blocking, and the local firewall. Don't assume the core name is the cause.

Config Compatibility: What You Can Keep and What to Rewrite

When migrating an original Clash config to mihomo, core structures such as proxies, proxy-groups, and rules are generally compatible. But a field being present does not mean its defaults or behavior are identical. Check protocol parameters, rule data, DNS, TUN, and client overrides separately.

Basic Rules: Check Policy Names and Rule Order First

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

rules:
  - DOMAIN-SUFFIX,example.com,Outbound
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,Outbound

This config snippet is for checking structure and does not include remote proxy nodes. The “Outbound” group currently contains only DIRECT, so traffic matched by it will connect directly. For a real config migration, add verified node names to the policy group. Names referenced by rules must exactly match a policy group or node name.

Rules are generally evaluated from top to bottom, with MATCH at the end. In the example, no-resolve means not to trigger a DNS lookup specifically for this IP rule. It does not disable all DNS or invalidate domain rules. If the connection has no usable destination IP yet, this rule may not match.

Rule Providers: Data Format Matters More Than the File Extension

When migrating rule-providers, check type, behavior, format, path, and the update URL. behavior: domain, ipcidr, and classical each require different content. A classical ruleset containing complete rules won't work as a plain domain list just because both files have a YAML extension.

Likewise, don't feed a format supported by mihomo's rule providers to an older core. For example, binary rule sets require a compatible implementation; changing the file extension does not convert them. Even if a remote rule set downloads successfully, check the parse logs and confirm that its rules actually match.

DNS and TUN: Similar Fields, Different Traffic Coverage

A system proxy generally affects only apps that honor the system proxy settings. TUN uses a virtual network interface and routing rules to intercept eligible IP traffic, making it useful for apps that ignore system proxy settings. It does not guarantee that all traffic will pass through a remote proxy. After interception, traffic still goes through rule matching and may be routed to DIRECT, rejected, or sent through a proxy.

Verify DNS Before Enabling the Virtual Interface

During migration, start with TUN disabled. Verify nodes and routing through the local proxy port, then add DNS interception and route handling. This helps distinguish a failed proxy connection from system DNS traffic that never reached the core. The following mihomo snippet should be merged into your existing config; don't define top-level dns or tun sections twice.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

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

• 127.0.0.1:1053 is the local DNS listening address. Enabling the listener alone does not make every app use it.
• 198.18.0.1/16 is an example fake-IP address pool. It provides synthetic addresses for mapping; it is not a remote proxy server address.
• Set enable: false to test the non-TUN path first. After permissions and routes are ready, change it to true.
• dns-hijack handles DNS traffic that meets the interception criteria. Don't assume it captures every DoH or DoT connection initiated by an app as if it were a regular port 53 query.

OS Differences: Check Permissions and Routes Together

Windows typically requires client service mode or elevated permissions. macOS may use a privileged helper or the network interception mechanism of a specific app. On Linux, check access to the TUN device and network management permissions. Android clients often intercept traffic through the system VPN interface, so their UI settings may not map one-to-one to desktop YAML.

If another VPN, virtual machine network, or enterprise security tool is running, default routes and DNS settings may overwrite each other. If disabling TUN restores connectivity, that points to the traffic interception path; it does not prove a protocol is incompatible. Record the default route, DNS addresses, route changes, and log timestamps, then troubleshoot one variable at a time.

Migration Checks: Validate Configs, Test Ports, and Roll Back

A reliable migration follows a reproducible sequence. Don't upgrade the core, replace the subscription, change DNS, and enable TUN all at once; if something breaks, you won't know which change caused it. Keep a copy of the old config and test with a separate config in the new client.

1. Record the baseline: Save the working nodes, policy selections, DNS mode, and listening ports. Note whether the system proxy and TUN are enabled.
2. Check the target core: Confirm whether it's mihomo or an older Meta binary, and check the actual version. A subscription template's title isn't enough.
3. Validate the config: Test it before starting listeners. A successful test means the config loads; it doesn't confirm that node handshakes or rule updates work.
4. Test one connection: Pin a single node and compare a direct connection with an explicitly proxied one to the same destination. Don't start with an automatic testing group.
5. Restore additional features: Re-enable rule providers, DNS, TUN, and startup launch one at a time, checking logs and connection records after each step.

mihomo -v
mihomo -t -f config.yaml

If the client's mixed port is 7890, use the commands below to distinguish an explicit proxy connection from a direct connection. Use the port in your active config; 7890 is a common example, not a universal default.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://clashgrand.com/
curl --noproxy "*" --connect-timeout 10 --max-time 20 -I https://clashgrand.com/

These commands are not speed tests, and status codes alone don't reveal the outbound route. Check the client's connection records to see which rule matched, which policy was used, and which node handled the connection. If the policy group still selects DIRECT, connecting through the local proxy port may still reach the destination directly.

Common Issues and What to Check First

To roll back, first disable the new client's system proxy and TUN, then exit the new process before restoring the old client and config. Don't let two cores compete for listening ports or system routes. For the control interface, bind to the loopback address whenever possible. If remote management is essential, configure authentication and restrict access separately.

Choosing a Core: Let Config Requirements Decide

• Basic nodes and common routing rules only: Migration is usually straightforward. Focus on policy names, DNS behavior, and client overrides.
• Using VLESS, REALITY, Hysteria2, or TUIC: Choose a mihomo version that explicitly supports the required parameters, then match them against the server config.
• Relying on Premium scripts: Rework and test the behavior first. Swapping the binary alone is not a complete migration.
• Need TUN: Check client permissions, OS support, and route conflicts as well as core features. A matching feature name alone isn't enough.

For a new setup, choose a maintained client that clearly shows its core information, then select a config format based on the protocols in your subscription. For an existing setup, establish a reproducible test and rollback path first. Core selection isn't about having the newest name; it's about whether nodes can complete handshakes, rules match, DNS resolves, and traffic interception works as intended.