Clash Core Comparison: Original Clash vs. Clash Meta and mihomo

Clash Core History: Original Clash, Premium, and the Meta Fork

When choosing a Clash client, check the interface name and core name separately. The client manages subscriptions, system proxy settings, configuration merging, and logs. The core establishes proxy connections, matches rules, and handles DNS. A client may update its bundled core or let you switch cores. The software’s name alone won’t tell you whether a VLESS node or TUN configuration will work.

With original Clash, distinguish between the open-source core and Clash Premium. Premium was a separate release line from the original project, with additional features such as TUN and rule sets; those features should not be attributed wholesale to the open-source core. The original project stopped being maintained in 2023. Older clients and binaries may still run, but they’re no longer a reliable reference for support in new configurations.

Clash Meta began as a fork of Clash and was later renamed mihomo. Meta and mihomo therefore refer mainly to the same technical lineage at different stages, not to two unrelated, incompatible products. Older guides mentioning the “Meta core” and subscriptions labeled “Clash Meta format” generally refer to this extended lineage; exact capabilities depend on the release actually in use.

Feature Comparison: Protocols, Rules, TUN, and DNS

This table compares feature boundaries, not a complete list of every historical release. Support also depends on server settings, how the client is packaged, and operating-system permissions. In particular, don’t assume that current mihomo features were available in every early Meta release.

Protocol support isn’t the same as being able to open a subscription

A YAML file being readable only confirms that its basic syntax is valid. If a subscription contains type: vless but is loaded by an older core without VLESS support, the node may fail to parse or the entire configuration may fail to load. Reality is a transport security setting used with certain protocols, not a node type alongside VLESS or Trojan. When migrating, check type, network, TLS, and the relevant transport options.

A subscription service labeling its output “Clash” doesn’t guarantee compatibility with original Clash. Some services use the name broadly for YAML output that already includes mihomo-specific fields. If the service offers separate Meta or mihomo output, choose the format for your target core. Conversion tools can only convert supported data structures; they can’t add protocol implementations that an older core lacks.

Configuration Compatibility: What You Can Keep and What to Check

Common structures such as proxies, proxy-groups, and rules can usually be reused. Basic rules such as DOMAIN-SUFFIX, IP-CIDR, and MATCH don’t need a rewrite just because the core was renamed. Focus on whether extended fields are supported and what configuration the client ultimately generates.

Migration checklist

• Local ports: Check port, socks-port, and mixed-port. For example, if you standardize on mixed-port: 7890, system proxy settings and apps configured manually must point to the port that’s actually listening. Don’t keep using 7897 from an old setup.
• Control API: external-controller is the management API, not the proxy endpoint for apps. If it’s set to 127.0.0.1:9090, don’t enter port 9090 as your browser proxy. For local-only management, keep the loopback address and set an access key.
• Rule references: The name referenced by RULE-SET must match a key in rule-providers. GEOSITE also requires the relevant data file. Diagnose data download failures separately from rule syntax errors.
• Rule targets: Every policy group referenced by a rule must exist. If you rename “Auto Select” to “Best Latency,” update references in rules and other groups as well.
• Script configuration: Don’t copy Premium’s script-based routing implementation as-is. JavaScript overrides provided by a client run while the configuration is being generated; they’re not the same as scripts run by the core while handling connections.
• Client-specific settings: Configuration merging, profile extensions, and startup options in older clients aren’t native mihomo YAML. Migrate the effective results of those settings, not every old file wholesale.

Test ports and rules with a standalone configuration first

The diagnostic template below is for local testing and contains no usable proxy nodes. It checks that the core starts, port 7890 can listen, and basic rules load. MATCH,DIRECT sends unmatched traffic directly; this is not a configured proxy setup.

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

proxies: []
proxy-groups: []

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

Test this template first, then add real nodes, policy groups, and rule sets in stages. That way, startup errors can be traced to the latest additions instead of troubleshooting several variables at once in a subscription with thousands of rules.

TUN Migration: Check Permissions, Routing, and DNS Separately

The system proxy serves apps that follow the system proxy settings; TUN routes traffic through a virtual network interface. After switching cores, an enabled TUN toggle doesn’t guarantee that the virtual interface, routes, and DNS hijacking are working. Windows typically requires service mode or administrator privileges; Linux requires network permissions, and macOS requires the appropriate authorization. The exact setup depends on the client.

Don’t copy default TUN values from an old guide. Whether stack, auto-route, and interface detection are appropriate depends on the platform, core version, and other network software. The mihomo configuration below shows commonly used fields. For initial testing, leave enable: false until the system proxy path has been verified.

tun:
  enable: false
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

• Check permissions first: If the logs show that creating a network interface or adding a route failed, check the service and permissions before switching nodes.
• Then check the outbound interface: When another VPN, virtual machine, or container network is active, automatic interface detection may choose the wrong route. Temporarily disable the other traffic-routing tool and compare the results.
• Finally, check DNS: any:53 applies to standard DNS traffic on port 53; it won’t automatically decrypt the browser’s built-in DNS over HTTPS. That traffic may instead appear as a regular HTTPS connection, with its route determined by your rules.

TUN can’t add UDP support that a node doesn’t have. If games or voice apps still have problems, check the node protocol, server-side UDP support, policy group routing, and local firewall separately instead of repeatedly switching TUN stacks.

DNS and Fake-IP: Matching Fields Don’t Guarantee the Same Resolution Path

Original Clash already supports Fake-IP, so it isn’t a mihomo-exclusive feature. The core first returns a virtual address, then uses the mapping to recover the domain and handle the connection. After migration, DNS behavior may differ even if enhanced-mode is unchanged in the YAML—for example, if DNS queries aren’t reaching the core or an app is still using cached results.

Keep DNS fields aligned with their purpose

• nameserver defines the regular upstream resolvers. When using an encrypted DNS upstream addressed by hostname, also consider how that hostname will be resolved in the first place.
• nameserver-policy selects resolvers based on domain conditions. It’s not a proxy routing rule and can’t directly replace rules.
• fake-ip-filter specifies which domains shouldn’t receive Fake-IP addresses. Add precise exceptions for domains with compatibility issues; avoid broad wildcards that switch the entire setup back to real-IP resolution.
• fallback and fallback-filter provide a separate resolver selection mechanism and aren’t required in every configuration. Their presence in an old configuration doesn’t mean you need to copy every region-based filter when migrating.

The example below shows a minimal combination of Fake-IP and domain-based DNS policies. example.com is a documentation example; replace it with a domain that genuinely needs separate DNS handling. 1053 is the local DNS listening port, not the system default of port 53. Starting a listener alone won’t change the system DNS settings.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
  nameserver-policy:
    '+.example.com':
      - 1.1.1.1
  fake-ip-filter:
    - '*.lan'

For testing, use the platform equivalent of nslookup example.com 127.0.0.1 -port=1053. Options and syntax vary by system. In an environment with dig, you can run the query shown below. Fake-IP responses should fall within the configured virtual IP range, but a real IP may also be returned because of a filter entry—one address alone doesn’t prove there’s a leak.

dig @127.0.0.1 -p 1053 example.com A

Also check whether the core logs show the query, and compare system DNS, the browser’s secure DNS, and the connection’s outbound route. Resolver ownership shown by an online test is only one data point: a resolver’s location can differ from the proxy exit location, which alone doesn’t prove that a request bypassed its intended route.

Migration Plan: Test Offline, Restore in Stages, and Keep a Rollback Path

You don’t need to change the client, subscription format, DNS setup, and rule sources all at once. Keep the same node and test destination, make the smallest possible switch first, then restore extended features. Only then can you compare results meaningfully.

1. Record the current setup. Save the original subscription, client overrides, effective configuration, and core version output. Note the local proxy port, such as 7890, and whether system proxy, TUN, and LAN access are enabled. Keep files containing node passwords or subscription credentials in a trusted location.
2. Confirm the target binary. Run the version command and record its actual output instead of relying on the installer name. A desktop client may bundle a different core from the standalone download.
3. Test the configuration. Start with syntax and reference checks. Once the test passes, start the core. If the error says a policy group is missing, fix the name reference first—don’t change DNS at the same time.
4. Verify the system proxy path. Turn off TUN and load a known-working node. Send a request through the explicit proxy to check the listening port, handshake, and exit, then test the system proxy toggle.
5. Restore rules and DNS. Add rule sets one at a time and check that the logs show the expected matching rule and target group. Then verify the DNS query path, and enable TUN last.
6. Keep a rollback option. If the new configuration causes problems, turn off TUN and system proxy in the new client first, then restore the old setup. Don’t let two clients compete for the same port or virtual network routes.

Command-line verification example

This example uses the binary name mihomo and a config.yaml file in the current directory. In Windows PowerShell, a local executable is usually written as .\mihomo.exe. When using a desktop client, test the configuration it actually loads, not just the downloaded subscription file.

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/

Passing -t doesn’t mean the remote node is reachable. The request above sets a 10-second connection timeout and a 20-second overall timeout to avoid waiting indefinitely on failure; these aren’t speed benchmarks. If you’re using the direct-connect diagnostic template above, this request only tests the local proxy endpoint—it doesn’t prove traffic is passing through a remote node.

Core Selection and Troubleshooting Boundaries

If you need VLESS, Hysteria2, TUIC, or newer rule features, check support in the relevant mihomo version instead of repeatedly trying to add fields to the original core. For a legacy setup, keep the configuration within the original core’s supported feature set to avoid nodes becoming unparseable after a subscription update.

When migrating from Clash Meta to mihomo, focus on version differences and how the client generates its configuration. Moving from original Clash or Premium to mihomo also requires checking differences in script, rule set, DNS, and TUN support. There’s no universal rule to “replace all fields”; the reliable approach is to confirm the version, inspect the effective configuration, and test connections layer by layer.

To choose a client, see the client platform and core comparison. For rule syntax and configuration structure, see the protocol guide. A configuration where every field has a clear purpose is easier to maintain than one layered with overrides from unknown sources.