Clash Core vs. Clash Meta vs. mihomo: Differences, History & How to Choose

First, distinguish the client from the core

A Clash client provides a graphical interface for importing configurations, switching nodes, and enabling the system proxy. The core parses YAML configuration, matches rules, and handles connections. They may be developed by different projects, so seeing Clash in a window title doesn't tell you whether it runs the original Clash core, Clash Meta, or mihomo. Check the client's Core or About page instead of relying on the app name.

These names aren't simply three versions in a linear sequence. The original Clash was an earlier project; Clash Meta grew out of its ecosystem and added features; mihomo is the name Clash Meta later adopted for the project. Guides, subscription instructions, or client interfaces may still say Meta, while the downloaded core file and version details identify it as mihomo. If you see both names, check the project and version before looking for a supposed Meta-to-mihomo config converter.

How to assess version history and maintenance

Public development of the original Clash has stopped. It established a widely used YAML configuration structure, including proxies, proxy-groups, and rules, so many guides still use “Clash config” as a catch-all term for these files. But similar structures don't mean newer fields will work with an older core. A client that hasn't been updated for years may still use the core bundled when it was released. Updating a subscription doesn't update the core.

Clash Meta added features while keeping familiar workflows, and the project later continued under the name mihomo. To check its current maintenance status, look at the core version and update history provided by your client. Some clients update the core with the app installer; others let you switch or update it separately in settings. Don't confuse the client version with the core version. For example, “client 2.0” identifies the interface software release; it doesn't tell you whether a particular mihomo rule is supported.

Check three places on your device

1. Open the client's Settings or About page and look for “Core,” “Kernel,” or a version number. Menu labels vary by client, so follow what the page actually says.
2. Check the beginning of the runtime log. The core name, configuration errors, and listening ports often appear during startup; the log is a better indicator of what's running than the installer filename.
3. If the client lets you switch cores, note the current selection first, then make sure the target core is compatible with your configuration. After switching, reload the config and check the log for unknown fields or rule parsing errors.

Protocol support: check node fields and core versions

The most direct way to choose a core is to check the node types in your subscription. Configurations for the original Clash commonly use protocols such as Shadowsocks, VMess, Trojan, SOCKS5, and HTTP. mihomo supports more protocols and extensions, including VLESS, Hysteria2, and TUIC. But “mihomo supports this protocol” doesn't mean every build supports every parameter. Check the documentation for the installed core version.

Once you have a subscription, check the type for each node under proxies in the YAML. If a node says type: vless but your client runs an older original Clash core, an import error or missing node usually points to a protocol mismatch—not a disabled system proxy. If the subscription is a long string of Base64 text or a single-node share link, first check whether the client supports that import format. Core support for a protocol doesn't mean the graphical client can parse every kind of share link.

Troubleshoot import failures in this order

• Config won't load: Check YAML indentation, field spelling, and the line number reported by the client. YAML uses spaces for indentation; list items at the same level should line up.
• Node type isn't recognized: Check type against the core that's running; changing the node's display name won't help. Protocol parameters must match the information provided by the node server.
• Config loads, but connections fail: First check the node address, port, and network connectivity, then verify authentication details. Switching cores alone may not fix the problem.

If your subscription service offers separate “Clash,” “Clash Meta,” and “mihomo” configuration options, choose the one that matches your current core. Save your existing config before switching. Conversion tools may rewrite policy groups or rule-set references, so check the actual routing behavior after import.

Rules, DNS, and TUN: similar configs can behave differently

Basic rules are read in much the same way: DOMAIN-SUFFIX,example.com,DIRECT sends matching domains directly, while MATCH,DIRECT handles connections that didn't match any earlier rule. Rules are usually evaluated in order, and the first match determines where traffic goes. If your config also uses rule-set references or syntax such as GEOSITE, check that the target core recognizes the rule type and has access to its data source. A shared .yaml extension doesn't guarantee compatibility.

This simplified example is only meant to show how basic rules relate to listening ports. mixed-port: 7890 sets a local mixed HTTP/SOCKS proxy port; external-controller uses the local address and port 9090. Every rule in the example points to DIRECT, and there are no proxy nodes, so this isn't a ready-to-use proxy subscription.

mixed-port: 7890
mode: rule
external-controller: 127.0.0.1:9090
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

Check DNS and TUN separately. DNS settings determine how domain names are resolved; TUN mode uses a virtual network interface to capture eligible device traffic. Enabling TUN may require permission to create a network interface, but TUN won't fix a dead node or add missing rule sets. If a website loads but a particular app bypasses the proxy, first check whether its connections appear in the core log. Then check the system proxy and TUN status, routing settings, and which rules match.

Choose based on your client and configuration

Your existing configuration works

Note the client name, core name and version, and configuration source. If your subscription uses only node types supported by the current core and rule-based routing works as expected, you can keep using the setup. Before switching clients, export or back up the YAML, then import it into the new client and check the policy group selections. Matching group names don't guarantee the new client will keep your previously selected node.

Your new subscription uses extended protocols or rules

Look for a client that clearly identifies mihomo as its core and supports the required fields in its current version. After importing, check three things: all nodes appear in the list, policy groups reference those nodes, and connection logs show the expected rule matches. Seeing a node name in the list doesn't prove the protocol handshake or routing works. When comparing clients, treat interface suitability for your device and core compatibility with your config as separate requirements.

The client says Clash but doesn't identify its core

Check the About page and startup log first. If you still can't tell, consult the client's release notes or project documentation. A TUN toggle doesn't prove the client uses mihomo, and Meta in a filename doesn't prove the core switched successfully. Once you've identified the core, use its documentation to check the subscription's protocols, rule-providers, DNS fields, and TUN settings.

Choose based on your configuration and use case: with basic rules and older subscriptions, consider migration effort; for VLESS, Hysteria2, or TUIC nodes, check the specific core version; for device-wide traffic capture, verify the client's TUN setup and permission steps for your operating system. After choosing, test a frequently used website and one that depends on a specific rule, then check the connection log to confirm the actual route.