What Are Original Clash, Meta, and mihomo? Kernel Differences and Which One to Choose

First, separate the client, kernel, and configuration file

When discussing Clash versions, the terms “client” and “kernel” are the easiest to mix up. The desktop window, system-tray menu, and subscription button belong to the graphical client. The executable responsible for establishing proxy connections, matching rules, handling DNS, and capturing traffic is the kernel. Names such as Clash Verge Rev and Mihomo Party usually refer to clients, while Clash, Clash.Meta, and mihomo refer to the kernels called by those clients.

The configuration file is the third layer. Common YAML files contain listening ports, proxy nodes, proxy groups, rules, and DNS settings. The client downloads and edits the configuration, then passes it to the kernel. The kernel reads the fields and starts working. As a result, the same subscription can behave differently in two clients with similar interfaces: one may use original Clash, while the other uses mihomo, and their supported protocols and fields are not exactly the same.

The relationship between original Clash, Clash.Meta, and mihomo

Original Clash: the starting point for rule-based proxying

“Original Clash” generally refers to the Clash project maintained by Dreamacro. It established the configuration structure still widely used today, including proxies, proxy-groups, rules, proxy-providers, and rule-providers. In default examples, 7890 is commonly used for the HTTP proxy port and 9090 for the external control interface. Many later clients retained these conventions.

The original project stopped receiving public maintenance in November 2023, and its code repository was later archived. The final commonly seen release identifier was v1.18.0. End of maintenance does not mean existing installations stop working immediately: older protocols, basic domain rules, and standard system proxying may continue to work, but the kernel will not adapt to new protocols, rule fields, or changes in operating-system networking.

Clash Premium also existed historically. It added capabilities on top of original Clash, including enhanced rules and TUN-related features, but it is not an old name for today’s mihomo. When an older guide mentions the “Premium kernel,” treat it as a specific historical branch rather than equating it directly with current mihomo.

Clash.Meta: a community extension compatible with Clash configuration

Clash.Meta is a community-maintained kernel that continued expanding the Clash configuration system. It retained many original fields, allowing existing rules and proxy groups to be migrated with minimal changes, while adding more proxy protocols, rule types, DNS controls, and TUN capabilities. For users, “Meta configuration” usually means the configuration uses extension fields not defined by original Clash.

Here, compatibility is closer to “mihomo can read most original Clash configurations” than to full two-way compatibility. When using only basic rules such as DOMAIN-SUFFIX, IP-CIDR, GEOIP, and MATCH, the differences are small. Once a configuration uses VLESS, Hysteria2, TUIC, GEOSITE, or mihomo-specific inbound fields, the original kernel may report an error or ignore the configuration.

mihomo: the name adopted after Clash.Meta was renamed

mihomo is not an unrelated kernel that came after Clash.Meta; it is the name adopted when the Clash.Meta project was renamed. Older clients, subscription-conversion tools, and historical articles may still display Clash.Meta, while newer releases, logs, and configuration documentation generally use mihomo. When you see “Meta kernel” and “mihomo kernel,” first understand them as names for the same community project at different stages, not as two products requiring a choice between them.

Feature differences in protocols, rules, DNS, and TUN

Kernel selection is not just about whether a webpage opens. Protocol support determines whether a node can connect, rule capabilities determine whether traffic is routed accurately, and DNS and TUN affect application coverage and the path used for domain resolution. Here is a practical overview of the differences.

Comparison	Original Clash	mihomo
Maintenance status	The original project is archived; the commonly encountered final version is v1.18.0	Actively maintained by the community; clients can usually track stable releases
Basic protocols	Supports common types including Shadowsocks, VMess, Trojan, HTTP, and SOCKS5	Supports many basic types and adds configuration for VLESS, TUIC, Hysteria2, and more
Rule types	Covers basic matching by domain, IP, port, process name, rule set, and MATCH	Adds finer conditions including GEOSITE, IP-ASN, network type, and inbound type
DNS	Includes common mechanisms such as nameserver, fallback, and fake-ip	Extends DNS control with nameserver-policy, rule interaction, and finer-grained resolution options
TUN	Capabilities vary across older branches; historical guides often depend on Premium	Provides a maintained TUN implementation with DNS hijacking and automatic route configuration support
Compatibility with newer configurations	May fail to start when extension fields are present	Better suited to current subscriptions and actively updated rule templates

Protocol support: identical node names do not guarantee identical formats

Protocols such as Shadowsocks, VMess, and Trojan are widely supported by both original Clash and mihomo, but the exact encryption methods, transport parameters, and extension options still depend on the configuration fields. Newer node formats such as VLESS, Reality, Hysteria2, and TUIC should generally be handled by mihomo. If the node count drops sharply after importing a subscription, or the log shows unsupported proxy type, first check whether the kernel is too old.

Subscription conversion can change only the text structure. For example, it can organize nodes into a YAML proxies list, but it cannot make the original kernel suddenly understand Hysteria2. When a node type exceeds the kernel’s capabilities, switch to a kernel or client that supports the protocol instead of repeatedly editing the subscription URL.

Rule capabilities: basic rules are portable; extensions depend on the kernel

Original Clash can handle most domain- and IP-based routing. The following are common basic patterns: send matching domain suffixes to a proxy group, connect directly to private-network addresses, and pass everything else to the final policy.

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

mihomo builds on this with more precise matching conditions. For example, GEOSITE can reference domain-category data, IP-ASN can match autonomous system numbers, NETWORK can distinguish TCP from UDP, and IN-TYPE can route traffic by inbound type. These features suit complex routing, but they are not guaranteed to work when the configuration is returned to the original kernel.

rules:
  - GEOSITE,category-ads-all,REJECT
  - NETWORK,udp,UDP-Proxy
  - IP-ASN,13335,Proxy,no-resolve
  - MATCH,Final

Rules are matched from top to bottom, and matching stops after the first hit. Regardless of the kernel, place specific rules before broad ones and put MATCH at the end. Otherwise, even a kernel that supports advanced rules may never evaluate them because an earlier broad condition has already matched.

DNS: focus on the resolution path, not just the server address

Original Clash provides core settings such as nameserver, fallback, fallback-filter, and enhanced-mode. mihomo retains these fields and adds finer domain policies and rule integration. During migration, pay particular attention to fake-ip and redir-host modes, the listen address, the IPv6 switch, and DNS hijacking under TUN.

A common mixed-proxy listening port is 7890, while a DNS listener example might use 0.0.0.0:1053. Ports are not fixed standards; follow the configuration file and client interface. If another local program already uses 7890, 9090, or 1053, the kernel log will usually show address already in use. Change the conflicting port instead of blaming the subscription.

TUN: determining which additional apps can be captured

System proxying mainly covers apps that actively read proxy settings; some games, command-line tools, and UDP traffic may bypass it. TUN mode uses a virtual network interface to capture a broader range of system traffic, so it depends more heavily on the kernel’s network stack, routing configuration, and DNS coordination. mihomo is the more common choice for TUN today.

The activation path varies by client. Common locations include “Settings” → “Network Settings” → “TUN Mode”, or the “Service Mode” and “TUN” switches on the main screen. The first activation on Windows usually requires administrator privileges; macOS may require approval for a network extension; Linux needs suitable CAP_NET_ADMIN permissions or an appropriate service setup. After enabling it, also check LAN access, DNS resolution, and resume-from-sleep behavior instead of validating only one browser page.

What to check when migrating an old configuration to mihomo

Migrating from original Clash to mihomo is usually smoother than migrating in the opposite direction, but “it starts successfully” is only the first step. The subscription provider, client, and local overrides may all modify the configuration, so troubleshoot in a consistent order.

1. Confirm the actual kernel first. In the client, open “Settings” → “Kernel” or “Settings” → “About” and record the name, version, and architecture. In a command-line environment, run mihomo -v; older original Clash executables typically use clash -v.
2. Keep a copy of the original configuration. Back up the YAML file, rule-set URLs, local overrides, and custom proxy groups. Saving only the subscription link may not include rules added locally.
3. Run a syntax test first. mihomo can check the configuration with mihomo -t -f config.yaml. A successful test means the structure can be read; it does not mean every remote rule set and proxy node can connect.
4. Check proxy-group references. The policy name at the end of every rule must exist in proxy-groups. For example, if a rule specifies Proxy but the configuration contains only “Node Select”, the kernel will report that the policy cannot be found.
5. Check external resources. proxy-providers, rule-providers, GEOIP, and GEOSITE data must be downloadable and writable to the cache directory. If an update fails, open “Settings” → “Logs” and check the HTTP status code, timeout details, and file permissions.
6. Enable TUN last. First use the system proxy to verify the 7890 listener, node connections, and rule routing, then enable TUN. This separates node issues from system-routing issues.

How to keep a basic configuration broadly compatible

When sharing a configuration across multiple devices, keep the common portion limited to basic fields and place mihomo extensions in a separate override. The skeleton below uses mixed port 7890, the local control interface 127.0.0.1:9090, and rule mode, making it a useful starting point for troubleshooting the structure.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

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

rules:
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

This example contains no real proxy nodes, so the Proxy group temporarily includes only DIRECT. In actual use, add nodes through a subscription or local configuration. Do not change a control interface in an online configuration directly to 0.0.0.0:9090; if LAN control is genuinely needed, set an access key and restrict the firewall scope at the same time.

Which kernel should you choose when installing a client in 2026?

For a new installation, prefer a maintained client that explicitly uses mihomo. The reason is not the newer name, but its ability to keep up with current node protocols, rule data, DNS behavior, and operating-system networking changes. mihomo is especially suitable when a subscription includes VLESS, Reality, Hysteria2, or TUIC, or when you plan to use TUN, GEOSITE, or IP-ASN.

When mihomo is the straightforward choice

• You are installing a Clash-based client for the first time and want ongoing kernel fixes and feature updates.
• Your subscription includes VLESS, Reality, Hysteria2, or TUIC nodes.
• You need TUN to capture games, command-line tools, UDP traffic, or apps that do not read system proxy settings.
• Your rules use extension conditions such as GEOSITE, IP-ASN, NETWORK, or IN-TYPE.
• You need different DNS upstreams by domain or more granular fake-ip exclusion rules.

When keeping original Clash may still make sense

• An existing configuration in an isolated environment is stable and uses only basic protocols and rules.
• An older client and automation script depend on original Clash command-line parameters, so migration requires compatibility testing first.
• You need to reproduce a historical issue briefly and must preserve the kernel and configuration behavior from that time.

These cases call for “keep it temporarily and plan the migration,” not for making original Clash the default choice on a new device. At minimum, record the client version, kernel version, configuration source, and occupied ports in the old environment so it can be restored after a reinstall.

Six things to check when choosing a client

1. Kernel name and version: Clearly identifies mihomo and lets you view the current version under “Settings” → “Kernel”.
2. Configuration management: Separates the original subscription, local overrides, and runtime configuration so subscription updates do not overwrite manual changes.
3. Log access: Provides at least info, warning, and error levels, with visibility into node, DNS, rule-set, and port errors.
4. TUN management: Shows service status, required permissions, and failure reasons rather than offering only a switch.
5. Platform architecture: Distinguishes x64 from ARM64 on Windows, Apple Silicon from Intel on macOS, and verifies amd64, arm64, and the installation method on Linux.
6. Update boundaries: Makes client, kernel, GEO data, and subscription updates visible separately, making it easier to identify which layer changed.

Common misconceptions and troubleshooting conclusions

“The configuration imports” does not mean “every field is active”

Valid YAML syntax only means the indentation and structure can be parsed. Some clients also remove unknown fields during import or replace subscription content with local overrides. To determine whether a feature is active, inspect the runtime configuration and kernel logs. For example, if adding GEOSITE produces no rule-hit records, confirm that the rule data loaded, the rule order is correct, and the active kernel supports that type.

“Meta” and “mihomo” are not two parallel upgrade tracks

In the current context, mihomo is the project name adopted after Clash.Meta was renamed. There is no need to search for a supposed performance comparison between a “Meta edition” and a “mihomo edition.” Check the release date, version number, processor architecture, and whether the client is still calling a kernel file that has not been updated for years.

A newer version still requires configuration testing

A maintained kernel fixes bugs, but it may also change default behavior, deprecate fields, or enforce stricter configuration validation. Export the configuration before upgrading, then test subscription updates, proxy groups, DNS, system proxying, and TUN in order. On corporate networks, campus networks, and setups with local DNS, pay special attention to whether internal domains and LAN subnets still bypass the proxy.

The final choice in one sentence

Use mihomo first for new devices and new configurations. If an older original-Clash environment still supports essential workloads, keep it temporarily, record its version, and migrate it step by step. Clash.Meta and mihomo are mainly names from before and after the rename; the client name is only the shell, while the running kernel determines protocol, rule, DNS, and TUN capabilities.