Clash, Clash Meta, and mihomo: Core Features, Protocol Support, and Configuration Syntax Compared

First, distinguish the client, core, and subscription config

A client’s name alone doesn’t tell you whether it supports a particular protocol. The GUI client manages subscriptions, switches configs, controls the system proxy, and displays logs. The core parses YAML, establishes proxy connections, applies routing rules, and handles DNS. Similar-looking clients don’t necessarily run the same core.

A subscription is a source of configuration. It may return a complete config containing proxies, proxy-groups, and rules, or just proxy entries for proxy-providers to load. A successful download only confirms that data was retrieved; it doesn’t mean the current core can parse every node type and rule in it.

• Choose a client: Check the operating system, installation method, permission requirements, and options for overriding the config.
• Choose a core: Check support for the proxy protocols, rule syntax, DNS features, and TUN functionality you need.
• Choose a subscription format: Confirm whether the provider returns a complete Clash config or an extended config intended for a specific core.

Timeline: Original Clash, Premium, Meta, and mihomo

Original Clash and Clash Premium

What’s commonly called the original Clash is the open-source Dreamacro/clash project. Clash Premium was a closed-source enhanced core in the same historical ecosystem, with features such as TUN, rule providers, and scripts. Premium features shouldn’t be attributed to the open-source original. And despite its name, Premium wasn’t a paid version of a particular GUI client.

In November 2023, regular public development of the original Clash project and Premium ended. Older binaries may still run, but don’t expect ongoing protocol updates, platform support, or bug fixes. Keeping an old setup for comparison testing is a different decision from relying on it for everyday connectivity.

Clash Meta and mihomo

Clash Meta began as an open-source fork of Clash, adding protocol and rule support to the original configuration model. The project was renamed mihomo in late 2023. Meta, Clash.Meta, and today’s mihomo in older guides generally refer to stages in the same project lineage, not three unrelated cores.

The rename doesn’t mean every historical release has identical features. A subscription marked “for Meta” suggests it targets this configuration ecosystem, but you still need to check whether the actual core version supports newer protocol fields. The version shown on a client download page may not be the core version.

1. Look for the core name and version in the client’s About section, core manager, or startup logs.
2. If you’re using a standalone binary, run mihomo -v and note the output.
3. Compare that information with the subscription’s requirements and the feature documentation—not just the client package name.

Feature comparison: protocols, rules, and TUN

Use this table to assess migration options, not as a complete feature list for every release. For protocols in particular, check the specific transport, encryption method, and authentication fields required by your version. Even the same protocol can fail to connect if its parameters don’t match.

Protocol support doesn’t mean every node can be imported

For example, a VLESS node may also require uuid, network, TLS parameters, and a REALITY public key. Changing the node’s type to vless won’t supply those missing parameters. Hysteria2 and the older Hysteria protocol aren’t interchangeable just because their names are similar.

If you encounter an unknown proxy type, first confirm that the subscription was generated for mihomo, then check the core version. Don’t work around errors by removing authentication fields or disabling certificate verification. Config parsing, a successful handshake with the remote server, and successful application requests are three separate stages to verify.

Migrating an older YAML config: what to keep and what to check

The structure of most basic configs can stay the same: local listener ports, proxy entries, proxy groups, and ordered rules are still relevant. Migration isn’t about renaming the whole file; focus on removing core-specific fields and confirming the runtime config the client actually passes to the core.

Common config fields and migration steps

Rule order is easier to overlook than field names

Rules are usually checked from top to bottom, and the matching rule determines the policy. If you put MATCH first, later rules won’t get a chance to match. Every RULE-SET reference must have a corresponding entry in rule-providers. The policy a rule points to must also be a valid proxy, proxy group, or built-in policy.

proxy-providers supply proxy nodes; rule-providers supply matching rules. They aren’t interchangeable. If migration produces a “provider not found” error, check the references first instead of swapping the two types of subscription URL at random.

Minimal config and migration checks

Test the core with a config you can easily roll back before adding your real subscription. Here’s a basic mihomo config structure: it listens on the local 7890 mixed port, uses rule mode, and has TUN disabled. The proxy group contains only DIRECT, so this example verifies the config structure and rule loading but doesn’t establish a remote proxy connection.

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

proxies: []

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

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

tun:
  enable: false

Save the file as config.yaml, then check it in a separate terminal. The commands below assume mihomo is in your PATH. On Windows, use .\mihomo.exe in place of the command name for a local executable.

mihomo -v
mkdir clash-test
mihomo -t -d ./clash-test -f ./config.yaml

-t checks whether the current core can load the config; it doesn’t prove that a remote node is reachable. Use a test directory separate from your everyday client’s data directory to avoid conflicts between cached data and resource files. If the config references external rules or geodata, make sure those files are available or can be downloaded.

1. Back up the original config and note the old core version, ports, and enabled overrides.
2. Import the real subscription into the target client, keep TUN disabled, and test a regular proxy connection first.
3. Check startup logs for unknown types, missing files, invalid references, and port conflicts.
4. Use the target client’s connection logs to confirm which rule matched and which route was taken, then restore DNS, rule sets, and TUN one at a time.

To test the local HTTP proxy listener, run curl -x http://127.0.0.1:7890 https://example.com/. This command explicitly specifies the proxy port; it doesn’t confirm that the system proxy setting is active. With the example config above, the request ultimately goes direct.

TUN and DNS: don’t copy old toggles blindly

The system proxy usually affects only apps that read the system proxy settings. TUN uses a virtual network interface and routing to capture traffic, which is useful when you need to handle traffic from more apps. But enabling it doesn’t guarantee that all traffic goes through the proxy. The core still uses rules to decide whether traffic goes direct, through a proxy, or is blocked; route exclusions and other VPNs also affect the result.

Check permissions and routing first

• Windows: Check whether the client requires service mode or administrator privileges. The exact setting depends on the client version.
• Linux: Check the TUN device, process capabilities or root privileges, and existing routing table.
• macOS: Check the client’s helper service and system permissions. Avoid running multiple VPNs that compete to manage routes.

mihomo TUN settings often involve auto-route, auto-detect-interface, stack, and dns-hijack. Configure these for your platform; a setup that works on one system isn’t a universal default. Record the original values and change one group of settings at a time to tell permission issues apart from DNS issues.

Successful DNS resolution doesn’t mean traffic is routed correctly

fake-ip mode maps domains to synthetic IP addresses to help identify them later, while redir-host focuses on returning real DNS results. They affect domain identification and app compatibility differently. During migration, check enhanced-mode, fake-ip-filter, upstream resolvers, and LAN domain handling together.

DNS interception commonly targets port 53 for regular DNS traffic. An app’s built-in DoH usually uses HTTPS over port 443, so don’t assume rules targeting port 53 will catch it. If results differ between a browser and other apps, check the browser’s secure DNS settings, caches, and core connection logs rather than repeatedly switching nodes.

Choosing a core: recommendations and checklist

For a new config that needs VLESS, REALITY, Hysteria2, TUIC, or extended rule support, choose a mihomo version that explicitly supports those features and confirm the client is actually using that core. If you’re only migrating an older SS, VMess, or Trojan config, its basic structure can usually stay, but verify DNS, script-based routing, and TUN separately.

The original Clash and Premium are best suited to understanding legacy configs and reproducing older behavior. Migrating to mihomo gives you the protocol and rule support it provides, along with an actively evolving core implementation. It won’t automatically fix an expired subscription, incorrect credentials, or an unreachable server.

• Version: Record the actual core name and version, not just the client version.
• Config: Pass syntax checks and confirm that node, proxy group, and rule provider references are complete.
• Ports: Make sure the local listener matches the app settings and isn’t competing with an old client for port 7890 or another port.
• Routing: Check at least one direct request and one proxied request; confirm the logs show the expected policy.
• TUN: Verify permissions, routes, and DNS before leaving it enabled. Confirm that networking recovers after you exit the client.
• Updates: Update the subscription manually once, confirm your custom overrides are still in place, then enable automatic updates.

For field definitions, see the protocol reference. If imports fail, ports conflict, or the system proxy behaves unexpectedly, troubleshoot by symptom in the Help Center. After choosing a core, verify a regular proxy connection first; add TUN and complex rules afterward to make issues easier to isolate.