Clash Core Compatibility Guide

Start by separating the client, core, and config

A Clash client’s name doesn’t tell you what it can actually do. The desktop app imports subscriptions, manages configs, and sets up the system proxy. The core parses proxies, opens ports, matches rules, and establishes connections. Different releases of the same client may bundle different core versions. To determine whether a subscription will work, check the core that’s actually running—not the name of the desktop shortcut.

Here, “original” refers to the early open-source Clash core; Premium was a separate, closed-source enhanced core. They are not the same thing. After the original open-source project and Premium’s original public release channels were discontinued in 2023, older builds may still run, but that doesn’t mean they received later protocol updates or OS compatibility fixes.

Check these three layers in order

1. Client: Can it save custom rules, update subscriptions, and request the permissions needed for TUN?
2. Core: Does it recognize the proxy type, transport options, and DNS fields?
3. Active config: After changes in the UI, subscription conversion, and config merging, does the final YAML passed to the core match your expectations?

For example, an editor may save mixed-port: 7890, but the client’s port override could still change it. When troubleshooting, check both the client settings and the active config—not just the original subscription file downloaded to your device.

Original Clash, Premium, and mihomo compared

This table compares the capabilities of each core family; it does not guarantee support in every historical release. mihomo in particular has version requirements for newer protocols, fields, and rule formats. Using mihomo does not mean an older binary supports every current config option.

The Premium name doesn’t mean it offers more features than mihomo today, nor does using it require a paid subscription. Core lineage, client distribution, and proxy service subscriptions are three separate things. Whether a subscription can connect to a server also depends on server parameters, authentication, network routing, and certificate settings.

Check protocol support down to the specific parameters

Recognizing a protocol name doesn’t guarantee a connection

If a node uses type: vless, type: hysteria2, or type: tuic, choose a mihomo version that explicitly supports that type. Changing the node’s type from one label to vmess or trojan does not convert the protocol; the server must provide an endpoint for the corresponding protocol.

Even when both cores recognize type: ss, they may support different encryption methods. You can’t determine compatibility with Shadowsocks 2022 methods from the broad claim “supports Shadowsocks” alone. Similarly, VLESS REALITY parameters, transport, and fingerprint settings must match the server and be supported by the core version in use.

• Unknown type during parsing: Check the core lineage, version, and subscription format first.
• Missing field or invalid parameter: Consult the config documentation for that version and check field names, nesting, and data types.
• Config loads but the handshake fails: Check the server address, port, authentication, SNI, and certificate-related parameters instead of changing rule order.
• Web pages work but UDP apps fail: Check that the node, server, and local traffic interception path all support UDP.

Subscription formats have compatibility limits too

“Clash subscription” is not a precise version specification. A provider may offer a stripped-down config for the original core or one that uses mihomo extensions. If the subscription goes through a converter, it may also remove nodes or fields it doesn’t recognize. If the number of nodes drops, compare the original response, converted output, and active client config to find where the content changed.

Config compatibility: from basic to extended fields

When migrating, keep listening ports, basic proxy groups, and common rules first, then add extended features one at a time. The minimal config below checks whether mihomo can load a config; it contains no remote proxy nodes. “Select outbound” only offers a direct connection, so it cannot verify whether a proxy server works.

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

proxy-groups:
  - name: Select outbound
    type: select
    proxies:
      - DIRECT

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

7890 is the local port shared by HTTP and SOCKS in this example; it is not a fixed default for all clients. allow-lan: false restricts access from your local network. If another program is already listening on this port, change the port or stop the conflicting process before importing the config. Don’t run two cores that use the same listening port.

Rule order and policy references still matter

Common rules are evaluated from top to bottom. Once a rule matches, later rules won’t determine the connection’s outbound route. Put MATCH last as the fallback. Every policy name referenced at the end of a rule must exist and match exactly. Switching cores won’t automatically fix a misspelled proxy group name.

no-resolve is commonly used with IP-based rules. It means the rule won’t trigger a DNS lookup to match; it doesn’t mean the request will never use DNS. When adding rule-providers, also check that behavior, format, and the rule file contents match. A plain domain list cannot be used as a classical rule set containing full rule statements.

Don’t copy Premium scripts over as-is

Premium’s script feature is not a general-purpose compatibility interface for mihomo. If an older config contains script, first confirm that the core in use supports the same mechanism, then consider rewriting it as a rule set, logical rule, or proxy group. A config being readable as YAML doesn’t guarantee that every unknown field will take effect; some fields may be ignored. Check connection logs to confirm what actually matches.

Check DNS and TUN separately

Fake-IP, DNS routing, and TUN often appear together in guides, but they handle different parts of the network stack. DNS handles domain lookups and address mapping; TUN intercepts traffic through a virtual network interface and routing. Enabling TUN doesn’t automatically ensure DNS queries are handled as expected, and a DNS test page showing a provider’s name alone can’t confirm core compatibility.

Check these four areas when migrating DNS settings

1. Listen address: For example, 127.0.0.1:1053 is available only on the local machine. If the system still queries a different address, the core’s DNS may not be used.
2. Enhanced mode: Check whether enhanced-mode uses fake-ip or redir-host; don’t just carry over a toggle state from the old UI.
3. DNS routing: Check what nameserver, fallback, and nameserver-policy actually do. Don’t assume fallback simply means a backup address used when the primary resolver times out.
4. Other DNS paths: Secure DNS in browsers, built-in DoH in apps, and router forwarding can all bypass the DNS path you intended to use.

TUN doesn’t mean all traffic goes through a proxy

mihomo’s tun.enable, auto-route, and dns-hijack have separate roles: enabling a virtual interface, setting up routes, and intercepting specified DNS traffic. Rules still determine the outbound route, so connections matching DIRECT go straight out. Insufficient permissions, route conflicts, or another VPN running at the same time can also leave some traffic unintercepted.

Don’t copy a stack value straight from an old guide just for compatibility. Available stacks and their behavior depend on the core version and operating system. Start with the client’s defaults for your platform, then adjust for a specific issue. To test, turn off TUN and verify the system proxy first; once the node works, enable TUN. This keeps the number of changing variables down.

How to verify the results before and after migration

Use a config copy you can roll back to. Record the old core name, version, listening ports, and subscription update time, then copy the config for testing. Command-line users can run the following checks against the actual binary. Desktop client users should inspect the core logs and confirm they’re testing the core the client really launched.

mihomo -v
mihomo -t -f ./config.yaml

The first command displays the version; the second checks whether the config can be parsed and loaded. Passing these checks only confirms that the static config meets those conditions. It doesn’t prove that a remote node can complete a handshake, DNS is routed correctly, or TUN routes are active. If the config references remote rules or proxy providers, also check that those resources are reachable.

If something fails, troubleshoot in this order: config loading → local listening → node connection → rule matching → DNS/TUN. Change one variable at a time. For a general checklist, see Troubleshooting. For your first config import, follow the setup guide to establish a basic connection.

How to choose a client

• New setup: Choose a maintained client that clearly identifies its mihomo core version, then check your operating system and processor architecture.
• Stable existing setup: Keep a working copy first, then check whether the new subscription uses protocols unsupported by your old core. Don’t overwrite your entire config without testing.
• Need TUN: In addition to core support, confirm the client can request permissions, manage the service, and clean up routes when it exits.
• Complex rules: Check rule providers, logical matching, and how overrides are saved. Make sure subscription updates won’t remove your local changes.

Base your choice on observable facts: the version of the core actually running, config check results, protocol errors in the logs, and the rules and outbound routes shown in connection records. The difference between the names Meta and mihomo is not the main obstacle. Compatibility problems more often come from mismatches between older binaries, extended fields, and client overrides.