Clash Core Comparison: Original Clash, Clash Meta, and mihomo Config Compatibility

Know the difference between the core, client, and subscription format

To determine whether a Clash config will work, first identify the core actually running—not just the app icon on your desktop. The core parses YAML, establishes proxy connections, applies rules, and handles DNS. The client handles config imports, system proxy toggles, service management, and the interface. Even clients with the same name can run different programs depending on the release, selected core, or custom core path.

A subscription is a source of configuration. It may return a complete config or just a list of proxies. A subscription labeled “Clash” doesn’t mean every proxy it contains is supported by the original Clash core. If you see entries such as vless, hysteria2, or reality-opts, check the core and its exact version.

• Identify the core: Check the startup log or core information screen, or run the core’s version command.
• Check the active config: Inspect the config after the client has merged and applied overrides—not just the original subscription.
• Pinpoint the failure: Distinguish config parsing errors from rule loading errors and proxy connection failures; each requires a different fix.

A naming timeline: original Clash, Premium, Meta, and mihomo

Original Clash and Clash Premium have different capabilities

“Original Clash” usually refers to Dreamacro’s open-source Clash core. Clash Premium was a closed-source enhanced core released by the original author, adding features such as TUN, rule providers, and scripts. Don’t assume every Clash client includes Premium’s capabilities by default, or treat the original open-source core and Premium as if they share the same config options.

After the original project stopped being maintained publicly in 2023, some older clients continued to bundle these cores. They may still run existing configs, but subscription updates won’t add support for newer protocols. Whether an older build launches and whether it can handle a current subscription are two separate questions.

Clash Meta was renamed mihomo

Clash Meta began as an extended fork in the Clash ecosystem and was later renamed mihomo. They’re part of the same project lineage, not two unrelated cores that require a complete config rewrite. A client that still displays “Meta” may also be using a newer mihomo build.

That said, a project’s continuity doesn’t guarantee full compatibility across every version. Earlier Meta builds may lack fields and protocols added in later mihomo releases, and some older features may have changed or been removed. When migrating, record the full version output and refer to the documentation and startup checks for that specific build.

Config compatibility: what carries over and what to check

Basic fields are generally more likely to carry over, but compatibility has three layers: whether a field parses, whether its values are supported, and whether it behaves the same at runtime. For example, a core may recognize the dns section without understanding every newer option under it. Some unknown fields may be ignored, and a successful config check doesn’t prove that a feature is working.

Policy group names are config dependencies

The policy name at the end of each rule must match an existing proxy, policy group, or built-in action. If you rename the “Proxy” policy group to “Select Node,” update every rule, rule provider reference, and other policy group that uses it. This kind of error has nothing to do with core generations, but it’s often mistaken for a protocol compatibility issue during migration.

Rewrite Premium scripts as routing rules

If an old config uses mode: script and script:, don’t just swap out the core binary. First list the domain, IP, and policy checks the script performs, then rewrite them as rules or rule providers supported by the target core. Verify each dynamic check separately; changing the mode to rule alone won’t complete the migration.

Protocol support: proxy types matter more than subscription labels

Original Clash and Premium commonly support Shadowsocks, VMess, Trojan, HTTP, and SOCKS5 proxies. That means support for the protocol types—not every encryption method, transport combination, or extended field introduced later. mihomo supports a wider range of protocols, but its settings must still match the server configuration.

If you see an error such as “unsupported proxy type,” check the core and proxy type first—not DNS. If the config loads but connections fail, check the server address, port, authentication, TLS, and underlying network. Hysteria2 and TUIC rely on UDP; switching the client to global mode won’t fix a network that blocks outbound UDP.

After migration, recheck rule providers, DNS, and TUN

Match rule provider behavior to its payload

Common rule-providers behavior values include domain, ipcidr, and classical. A domain list can’t be loaded as a complete rule list, and changing a file extension won’t turn a full rule set into a domain payload. mihomo’s MRS format isn’t suitable for direct use with legacy Premium. Check format, the actual file contents, and the target version before migrating.

Rules are matched in the order they appear in the config. Putting domain rules before IP rules, or vice versa, can affect DNS resolution and the final route. The final MATCH rule is a fallback; don’t place it ahead of rules that still need to be evaluated. A rule provider downloading successfully doesn’t mean its RULE-SET reference is in the right place.

Fake-IP reserved addresses aren’t proxy server addresses

198.18.0.0/16 is a commonly used Fake-IP range. When an app receives an address from this range, the same core usually needs to handle the connection so it can map the address back to the domain. Returning fake IPs from DNS without a corresponding traffic interception path can cause connections to fail. After migration, check DNS settings, the system proxy, TUN, and the app’s own proxy settings instead of treating fake IPs as invalid servers.

TUN requires OS permissions and compatible routing

tun.enable: true only declares that TUN should be enabled. Actual operation also depends on service permissions, a virtual network adapter, routing, DNS interception, and the network stack implementation. On Windows, the client may need a service or administrator privileges; on Linux, it typically needs the relevant network permissions. A client’s “service mode” and the TUN switch in the config are separate settings.

• Close the old client and stop its background service first, so two programs don’t try to manage routes at once.
• Verify the connection with the system proxy first, then enable TUN separately to narrow down the cause of any issue.
• Keep a copy of the original config and test access to regular domains, LAN devices, and IPv6 separately.
• Check the logs to see which network stack is actually active; don’t assume traffic is being intercepted just because a toggle is on.

Migration steps: verify the basic port before restoring advanced features

This config checks local listening and basic rule parsing. It includes no remote proxies and isn’t a replacement for a full subscription. It sets the mixed port to 7890, disables LAN access, and sends all connections direct. The port is an example; if another program is using it, choose a different port or stop that program first.

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

rules:
  - MATCH,DIRECT

1. Save the current setup. Back up the original subscription, overrides, and active config. Record the client and core versions; don’t rely on the import link alone.
2. Confirm the new core. To check the mihomo version, run mihomo -v. Use the actual program path and filename for your installation.
3. Check the syntax. Run mihomo -t -f config.yaml. If the config uses relative resource paths, make sure the working directory and data directory match the client’s actual environment.
4. Restore proxies and policy groups. Start with one known-good proxy and verify authentication and TLS, then restore groups such as automatic selection and failover.
5. Restore rule providers and DNS. Check resource loading, policy names, and rule matches before adding Fake-IP or custom DNS rules.
6. Enable TUN last. Verify permissions, the default route, and LAN access, then confirm that networking returns to normal after you exit the client.

Check the basic port with curl -x http://127.0.0.1:7890 -I https://clash-dl.com/. This tests whether the HTTP proxy listener can handle a request; it doesn’t verify SOCKS5, UDP, TUN, or every proxy. If the command fails, check the logs to determine whether the listener is down, the destination is unreachable, or there’s a problem with the outbound connection.

Choosing a client and troubleshooting compatibility

When choosing a client, first check your operating system and processor architecture, then look into the core it uses and whether it’s maintained. Clients such as Clash Verge Rev and FlClash use the mihomo ecosystem, but the exact support depends on the installed release and core build. Older releases of Clash for Windows or Clash for Android don’t support mihomo’s extended protocols just because their names include Clash.

Also check the client’s core information, subscription override support, and service management features. Even if a replacement binary starts successfully, an older interface may not display new fields or may overwrite manual changes when saving. For platform and client compatibility, see the client comparison; for basic config fields, see the protocol reference.

The final decision comes down to four things working together: the core version, config fields, server protocols, and the operating system’s ability to intercept traffic. Basic rules can usually be carried over; Premium scripts need separate work; new protocols require checking for implementation support; and TUN and DNS must be tested on the target device. Once you’ve checked these, decide whether to keep the existing config, change the subscription format, or switch clients.