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

The short version: Meta and mihomo are successive names for the same project

When choosing a core for a new config, check which core the client actually runs—not just the client’s name. The original Clash, Clash Premium, and mihomo have different feature sets. Clash Meta was later renamed mihomo; it is not a separate fourth core you need to install. Older guides that mention “Meta config” usually refer to this project’s configuration system, but you should still verify fields against the specific version.

When migrating an older config to mihomo, basic proxies, proxy groups, and common domain rules can usually be reused. Check newer protocols, Premium scripts, DNS, TUN, and rule-set formats separately. Migrating in the other direction is more limited: a config that mihomo can parse is not necessarily compatible with the original Clash.

How the projects relate: original Clash, Premium, Meta, and mihomo

Original Clash and Clash Premium

“Original Clash” usually refers to the open-source Dreamacro/clash core. Clash Premium was a closed-source enhanced branch provided by the original project, with a different feature set. Historically, TUN, rule providers, and script rules were key features distinguishing Premium from the open-source core. The original project stopped being maintained in 2023. Older binaries may still run, but they are no longer a good foundation if you need ongoing support for new protocols.

Clash Meta and mihomo

Clash Meta evolved within the Clash ecosystem, adding protocol and routing capabilities, and was later renamed mihomo. A Meta label in a folder name, subscription instructions, or an older interface does not necessarily mean the core is outdated. Check the version reported by the actual binary and its corresponding release notes.

• Original Clash: The historical starting point for basic YAML configs, HTTP/SOCKS inbound proxies, and rule-based routing.
• Clash Premium: One source of advanced rules, TUN, and scripting support in older configs.
• Clash Meta / mihomo: Successive names for the same project, with support for more protocols and config extensions.

A client that lets you switch cores does not mean you can swap executable files at will. The client may manage core startup arguments, control APIs, service permissions, and installation paths. Use the client’s built-in core updater whenever possible, and check which core types it explicitly supports.

Feature comparison: protocols, rule sets, and TUN

Even if the protocol name matches, verify transport and encryption fields

A node labeled VMess may still be missing required connection settings. Check the UUID, TLS, server name, WebSocket path, and request headers. For VLESS, also confirm the server’s transport, security layer, and related parameters. Changing only type does not convert one protocol into another.

Hysteria2 and TUIC rely on UDP connectivity. If the core can parse a node but connections keep timing out on your network, check UDP access, the server port, and certificate settings rather than blaming the config format. Protocol support is necessary, but it does not guarantee that the route is reachable.

Config compatibility: keep the basic structure, then handle extensions

A typical config includes proxies, proxy-groups, and rules, and may also include proxy-providers and rule-providers. Their names may look similar, but they serve different purposes: proxy providers load nodes from external sources, while rule providers load routing rules. Do not use a subscription URL for the wrong provider type.

Check rule order and policy names together

The snippet below shows a common mihomo config structure. The manual selection group points to DIRECT, so it will not route traffic through a proxy. In a real setup, keep the direct option and add valid existing nodes or a correct reference to a node provider.

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

proxy-groups:
  - name: Manual Selection
    type: select
    proxies:
      - DIRECT

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

• mixed-port: 7890 is an example of a shared listening port for HTTP and SOCKS proxies; it is not the default for every client.
• allow-lan: false is a good starting point for local testing. To allow LAN access, check the listen address and firewall rules.
• Rules are matched in order. Putting MATCH first prevents later rules from working as intended.
• The “Manual Selection” policy in a rule must exactly match the proxy group name, including spaces and capitalization.
• no-resolve means this IP rule will not trigger a DNS lookup; it does not disable DNS for the entire core.

Migrate Premium scripts and newer rule-set formats separately

Do not assume the script section in an older config is compatible with mihomo. Identify the domain, IP, or process checks the script performs, then rewrite them as rules supported by the target core. Logic that cannot be expressed equivalently will need to be redesigned. After migrating, validate both the syntax and the actual match results for representative requests.

For rule providers, check that behavior matches the file contents. domain, ipcidr, and classical expect different rule content. YAML, plain text, and mihomo’s MRS format cannot be converted simply by changing the file extension. Extended formats such as MRS also depend on rule behavior and core version, so older cores may not be able to read them.

DNS and TUN: common sources of “starts up but doesn’t work” problems

DNS config: distinguish the DNS entry point from upstream resolvers

The DNS listen address, upstream servers, Fake-IP mode, and domain exception list solve different problems. Seeing enhanced-mode: fake-ip only tells you that Fake-IP is enabled; it does not prove that system requests are reaching the core. The system may use another DNS path, and apps may have their own encrypted DNS enabled.

• Before migrating, save the existing nameserver, fallback, fake-ip-filter, and related policies.
• If only local device names or intranet domains fail, first check the LAN DNS path and Fake-IP exceptions. Do not replace all upstream servers at once.
• If the logs show that an upstream hostname cannot be resolved, check the bootstrap DNS settings used to resolve the DNS server’s own hostname.
• After changing the config, restart the relevant apps if needed. System DNS caches and app caches are not always cleared when the core reloads.

TUN captures traffic; it does not fix proxy settings

TUN uses a virtual network interface to capture traffic and usually requires administrator access or equivalent network permissions. Check Windows service mode, Linux routes and permissions, and the network extension or virtual interface used by the macOS client. If the system proxy already works, test TUN afterward to narrow down the cause.

tun.auto-route, tun.auto-detect-interface, and tun.dns-hijack control routing, outbound interface detection, and DNS interception, respectively. They are not interchangeable “enhancement switches.” The example any:53 matches DNS traffic on port 53; it does not mean all encrypted DNS inside apps will be intercepted. When running another VPN at the same time, also check route priorities and virtual adapter conflicts.

Migrate an older config to mihomo: six validation steps

1. Save the original config. Back up the subscription source, local overrides, rule sets, and current config file. A file exported by a graphical client may already include merged overrides, so keep the editable source files too.
2. Record the core details. Check the core version in the client’s core information or logs. For a standalone installation, run mihomo -v and record the output and OS architecture.
3. Check the syntax first. For a standalone installation, run mihomo -t -f config.yaml. Check relative-path resources from the same working environment used in production to avoid mistaking a path error for a format incompatibility.
4. Test the local proxy port first. Confirm that the config is listening on port 7890, then run the command below. If the port is different, update the command to match.
5. Verify rule matches. In the client’s connection log, check the destination domain, matched rule, proxy group, and final route. A successful request confirms only that this particular connection worked; it does not prove that all routing rules are correct.
6. Restore extended features one at a time. Add rule providers, DNS overrides, TUN, and startup behavior in sequence. Check the logs at each step and confirm that each feature still works after reloading the config.

mihomo -v
mihomo -t -f config.yaml
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

The 10-second connection timeout and 20-second overall timeout above are diagnostic settings, not speed measurements. In Windows PowerShell, use curl.exe to explicitly run the system curl program. Before testing, check whether an existing client is already using port 7890 to avoid a port conflict from starting a second core.

Common migration issues: narrow down the cause from the error

Subscription imports, but none of the nodes work

First check whether the subscription contains a complete Clash config, proxy provider content, or a collection of share links for another client. “Import successful” in a graphical client may only mean that the URL was saved. Check the download result, node parsing logs, and protocol support next. Never paste a subscription URL containing credentials into a public converter or support post.

Config validation passes, but the rules have no effect

Check that the operating mode is set to rule and that the running config is the file you just edited. The client may regenerate the config after a subscription update or insert higher-priority rules through an override. To make changes persist, use the client’s supported override or merge mechanism instead of editing only the generated file.

Startup reports that a port is already in use

Check whether two clients are running at once or an old core is still active as a background service. Proxy inbound ports and control API ports serve different purposes: for example, 7890 may be the local proxy port and 9090 the control API port, but always check the active config. After changing the proxy port, update the system proxy, terminal environment variables, and any manual proxy settings in apps too.

Should you keep using an older core or switch to mihomo?

If you need Hysteria2, TUIC, VLESS, or newer rule and DNS capabilities, choose a mihomo client that explicitly supports them and check the included core version. If your current setup depends on Premium scripts or specific legacy behavior, validate the migration with a separate config before replacing the production setup. See the client selection guide for installers and the setup guide for basic configuration steps.

The real test is whether the config parses, nodes connect, rules match as expected, and system proxy or TUN captures the right traffic. A name containing “Meta” or “mihomo” is no substitute for checking all four.