Clash Core vs. Clash Meta vs. mihomo: Evolution, Features, and Differences

How the Names Fit Together: Original Clash, Premium, and the Meta Fork

Here’s the key takeaway: Clash Meta and mihomo are successive names for the same fork, not two unrelated cores. The original Clash project is the upstream source of this development line. When choosing a client, check the name and version of the core it actually runs—not just whether the app name includes Clash.

Clash Premium needs to be treated separately. Many older guides use “Clash” to refer to both the original open-source core and the Premium core. This can lead to misconceptions such as “the original always supports TUN” or “all old configs can be migrated as-is.” To assess feature support, distinguish these four names.

• Original Clash open-source core: Usually refers to the open-source version of the Dreamacro/clash project. It provides basic features such as local proxy listeners, proxy groups, rule matching, and DNS.
• Clash Premium: A separate, closed-source enhanced core released by the original project. It once offered additional features such as TUN, rule providers, and scripts. These features should not be attributed to the original open-source core.
• Clash Meta: A community-developed fork of Clash that expanded protocol, rule, and traffic-routing capabilities.
• mihomo: The name later adopted by the Clash Meta project. It appears in current documentation, binary filenames, and logs, though some clients and subscription services still use the Meta label.

Client vs. Core: App Version Doesn’t Tell You Core Features

The client handles subscription management, config switching, system proxy settings, and log display. The core parses configs, establishes connections, applies rules, and handles DNS. A client may bundle a core or let you switch cores, so an updated app doesn’t necessarily mean its underlying networking capabilities have been updated.

Three Ways to Identify the Core That’s Actually Running

1. Open the client’s About or Core page and note the client version and core version separately. Menu names vary by client; don’t mistake the app’s version number for the core version.
2. Check the startup logs for the core name, version, and config loading result. After switching cores, check the logs again to make sure the process was restarted and is using the new core.
3. If the local controller is enabled, you can request /version. The response varies by core version; check the version field and fork identifier.

For example, if the controller is configured as external-controller: 127.0.0.1:9090, you can run the command below locally. If the controller has an access key, send an authenticated request with the correct credentials. A 401 response means authentication failed; it doesn’t mean the core lacks version lookup support.

curl http://127.0.0.1:9090/version

9090 is the controller port, not a browser proxy port. The controller can change the running state, so keep it bound to localhost. Don’t expose it to the public internet just to connect a dashboard.

Feature Comparison: Protocols, Rule Providers, TUN, and DNS

This table compares broad feature areas, not every feature in every historical release. The original project and its Premium release line are no longer maintained; for mihomo, check the documentation for your specific version, especially for new protocol options, DNS settings, and platform-specific features.

Same Protocol Name? Check the Transport and TLS Settings Too

Protocol support doesn’t guarantee support for every combination. For example, VLESS is a proxy protocol, REALITY is a related TLS security configuration, and WebSocket and gRPC are transport methods. The core must support the specific fields required by the server. Seeing “VLESS supported” alone doesn’t confirm that the full connection setup is compatible.

Likewise, Hysteria and Hysteria2 configs aren’t interchangeable just by changing the displayed name. If a subscription contains type: hysteria2, an older core won’t become compatible if you change the type to hysteria. Choose a compatible core and subscription output instead of deleting fields one by one to silence errors.

Rule Compatibility: Reuse Basic Syntax, Check Extended Features

Most basic traffic-routing rules follow the same logic: rules are evaluated from top to bottom, and the first match determines the policy. Rules such as DOMAIN-SUFFIX, IP-CIDR, and MATCH are broadly compatible, but every referenced proxy group must exist, and its proxy names must match available resources.

This snippet illustrates rule order; it isn’t a complete subscription config. DIRECT is the built-in direct-connection policy. In practice, point rules that need a proxy to an existing proxy group rather than copying this example as an all-direct setup.

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,DIRECT

• Final fallback: MATCH usually goes last. If placed earlier, it prevents later rules from being matched.
• Rule provider declarations: When using RULE-SET, check the corresponding rule-providers name, format, and behavior type. Copying only the rule reference isn’t enough.
• DNS side effects: no-resolve prevents this IP rule from triggering a DNS lookup. It doesn’t mean DNS is unnecessary for the entire connection.
• Premium scripts: When migrating an old config that uses script, check whether the target core supports the same mechanism. If not, consider rewriting it with rules and proxy groups.

If the config loads but traffic isn’t routed as expected, first check whether the current mode is rule. Global mode doesn’t apply the usual rule list, and direct mode can’t be used to verify proxy rules.

TUN and DNS: Feature Support Doesn’t Guarantee Traffic Is Being Routed

System Proxy and TUN Handle Different Traffic Paths

The system proxy setting directs apps that respect it to a local HTTP or SOCKS listener, such as 127.0.0.1:7890. It doesn’t capture every app, and it doesn’t mean all UDP traffic reaches the core. TUN uses a virtual network interface and routing to capture more IP traffic, so it works differently and covers a different range of traffic.

mihomo supports TUN, but adding enable: true to a config doesn’t guarantee it will work. Check that the client has the required permissions, the operating system allows interface creation, routes are correct, and there’s no conflict with another VPN or transparent proxy. During troubleshooting, use only one traffic-capture method at a time to reduce routing loops and duplicate DNS interception.

Fake-IP Is a DNS Mode, Not a Proxy Protocol

Fake-IP assigns a mapped address to a domain so the core can recover the original domain when a connection starts and apply the right routing rule. A common config uses the 198.18.0.1/16 address pool. This doesn’t mean the destination website is actually hosted at that address, nor does it indicate the node’s region.

The snippet below shows only the relevant fields. 1053 is a custom local DNS listening port; it doesn’t automatically replace the standard system DNS port, 53. The client must route system DNS requests to the core through traffic capture, TUN DNS interception, or another explicitly configured method.

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

For DNS fields and traffic-capture order, see the DNS section of the full guide. For what Fake-IP does and doesn’t do, see the glossary.

Migration Checklist: Switching from an Old Clash Config to mihomo

Migration isn’t about replacing the word Clash with mihomo in a config file. You need to verify that the protocols, rules, and system traffic routing all work together. Follow these steps in order, confirming each one before adding the next layer of functionality.

1. Keep a copy of your current setup: Back up the subscription URL, current YAML, local overrides, and proxy group selections. Subscription URLs may contain access credentials, so don’t include them in public logs or screenshots.
2. Check the subscription output: If your provider offers separate Clash and Meta outputs, make sure the selected output uses protocols and fields the target core supports. A Base64-encoded node list doesn’t become a complete YAML config just by changing the file extension.
3. Validate the config syntax: Test it with the target core. A common command is mihomo -t -f config.yaml. On Windows, use mihomo.exe -t -f config.yaml. The actual executable path depends on where it’s installed.
4. Test the local proxy first: Temporarily disable TUN. Check that the local listener, proxy groups, and proxy connection work, then verify rule mode.
5. Enable traffic capture next: Enable TUN with the required permissions, then check the logs for interface, routing, and DNS status. Test both a browser and an app that doesn’t follow the system proxy setting.
6. Restore automatic updates last: After updating the subscription once, confirm that local overrides still work. Changes made directly to a remote config may be overwritten by a later update.

For example, if your config uses mixed-port: 7890, run the command below to check whether an HTTPS request goes through this local HTTP proxy listener. A successful request confirms only that this listener and destination are reachable; it doesn’t prove that all apps, UDP, or TUN are working.

curl -I -x http://127.0.0.1:7890 https://example.com

If the port is already in use, check whether an old core or another client is still running. If you see an unknown proxy type, check the core version and subscription format first. If syntax validation passes but the connection times out, check the server settings, network reachability, and DNS. Troubleshooting these as separate issues is usually more effective than repeatedly changing the config.

Choosing a Core: Match the Subscription and Platform

• Need newer protocols or extended rules? Choose a client that clearly integrates and maintains mihomo, and confirm that its bundled core meets your config’s requirements.
• Only need basic protocols and domain-based routing? You may not need complex config, but for a new setup, prioritize ongoing maintenance and operating system compatibility rather than sticking with an old core just because an older guide is familiar.
• Need TUN? In addition to core support, check the client’s permission handling, system architecture, and routing capabilities. On mobile, confirm which core the app actually uses and how it implements the system VPN interface.
• Migrating a Premium config? Review scripts, rule providers, and TUN fields first. Being able to import a config doesn’t guarantee identical behavior.

Keep three update paths separate: subscription updates change proxy resources and rule content; core updates change protocol and networking capabilities; client updates change the interface and integration. Refreshing a subscription won’t necessarily fix an unsupported field, and switching cores won’t fix a dead server address. Identify which layer the issue belongs to before choosing a fix.