Clash, Clash.Meta, and mihomo: Kernel Differences, Compatibility, and Client Selection

To decide whether a Clash client fits your environment, look beyond its name and screenshots. The kernel handles connection interception, rule matching, DNS processing, and proxy protocol parsing. Desktop clients usually provide configuration controls, tray menus, system proxy switches, and log viewers; the kernel version determines which configuration fields are recognized, how TUN operates, and whether newer protocols can establish connections.

“Original Clash,” “Clash.Meta,” and “mihomo” are often discussed together, but they are not three products under continuous, synchronized development with equivalent features. The original Clash provides the foundation for the configuration model and rule system; Clash.Meta was the former name of the later extension branch; and mihomo is the current name adopted by that branch. Many clients, configuration directories, and subscription-conversion templates still use “Meta,” so the name shown in the interface may not match the kernel actually running.

Project lineage: the original Clash, Meta, and mihomo are not three parallel product lines

The original Clash established the common configuration model

The original Clash generally refers to the Go-based rule-driven proxy kernel and configuration system maintained by Dreamacro. It established core concepts such as proxy nodes, proxy groups, rules, DNS, inbound ports, and the external controller. Many clients and subscription services retained these fields, so configuration files are still commonly called Clash configurations even when another compatible kernel is running.

The original open-source project is now archived and no longer receives ongoing feature development. Historically, Premium builds with different feature boundaries also existed, and some older guides mix the open-source version, Premium version, and graphical clients together. When following an old tutorial, first determine which build it describes. In particular, do not assume behavior from the old Premium build is available in every original Clash kernel.

Clash.Meta was the former name of the extension branch

Clash.Meta retained Clash’s main configuration structure while expanding support for proxy protocols, rules, DNS, TUN, traffic sniffing, and runtime controls. One goal was to make common Clash configurations easy to migrate while allowing additional fields. Because its compatibility base was broad, many desktop and mobile clients once put “Meta” directly in their product names, kernel selectors, or configuration directories.

mihomo is the current name of the renamed Meta branch

mihomo did not emerge as a separate parallel kernel alongside Clash.Meta. More precisely, the Clash.Meta project was renamed mihomo, with its codebase and maintenance lineage continuing under the new name. For newer releases, bug fixes, and new configuration features, consult the current mihomo documentation. If an older interface says “Meta kernel,” still check the version output: it may actually package mihomo while the client has not updated its display text.

Feature boundaries: differences center on traffic interception, protocols, and rule processing

Basic HTTP, SOCKS, mixed ports, proxy groups, and domain rules are not enough to distinguish kernels. Most standard subscriptions can generate these elements. What really affects the choice is how system traffic enters the kernel, which component resolves DNS requests, whether the subscription includes newer proxy protocols, and whether the rule set depends on mihomo extension syntax.

TUN and system traffic interception

The system proxy only affects applications that actively read proxy settings. Browsers and some desktop software usually support the system proxy, but command-line tools, games, virtual machines, some store apps, and software with its own network stack may bypass it. TUN mode receives a broader range of IP traffic through a virtual network interface, making it suitable for environments that need unified interception. It also involves administrator permissions, routing tables, DNS hijacking, network adapter conflicts, and firewall rules.

The original open-source kernel, historical Premium builds, and modern mihomo cannot be treated as having the same TUN capabilities. Current mihomo provides a more complete TUN configuration with options for different protocol stacks and automatic routing. Whether it works still depends on the operating system, service mode, and permissions. Choosing a mihomo-based client only means the kernel supports the relevant capabilities; it does not mean the client has automatically configured drivers, services, and routes.

Proxy protocols and transport parameters

Early Clash configurations mainly covered then-common protocols such as Shadowsocks, VMess, Trojan, and SOCKS. Later mihomo development added or expanded support for various protocols and transport parameters. If a subscription contains a newer protocol, encryption method, or extension transport field, an older original kernel may fail during loading or ignore unknown fields, ultimately leaving the node unusable.

Do not compare kernels only by whether the node list appears. A graphical interface may parse the subscription and display nodes first, while the kernel receives the configuration only when it actually starts a connection. A node appearing in the list but failing latency tests is often caused by the frontend accepting a field that the kernel version does not support. During diagnosis, check the kernel log for parsing errors, handshake failures, and unknown-field messages.

Rule sets, sub-rules, and matching capabilities

Classic Clash rules usually consist of a rule type, matching data, and a target policy, such as a domain suffix, IP range, process name, or final match. mihomo builds on this foundation with richer rule and rule-set capabilities, allowing remote rule sets, boolean combinations, and sub-rules to be organized as needed. Large configurations can use these features to shorten the main file and split data according to different update schedules.

Extension capabilities also impose migration constraints. Once a configuration uses a rule type supported only by mihomo, do not assume it can fall back directly to the original kernel. Even with valid YAML syntax, an older kernel may refuse to start because of an unknown rule. When several clients must be supported, use the least capable kernel among the target devices as the baseline, or generate separate configurations for each kernel.

DNS, sniffing, and domain recovery

Rule decisions in the Clash family often depend on domain names, but a connection entering TUN may expose only the destination IP. DNS mapping, Fake IP, and traffic sniffing supplement the missing domain information so domain rules can still match. mihomo exposes more tunable fields for these processes, including listeners, resolver groups, Fake IP ranges, filters, fallbacks, and sniffing scope.

More options are not always better. Corporate intranet domains, local-network devices, game anti-cheat systems, encrypted DNS in browsers, and the operating system’s own resolver cache can all change the actual path. Kernel selection only determines which tools are available; the final configuration must fit the network environment. During troubleshooting, check system DNS, kernel DNS logs, rule matches, and the actual egress separately instead of changing TUN, Fake IP, and fallback servers all at once.

Configuration compatibility: base fields usually carry forward, but extensions do not work in reverse

When migrating an original Clash configuration to mihomo, the basic structure can usually be retained. Ports, run modes, log levels, proxy lists, proxy groups, and common rules continue to use familiar nesting. The following example deliberately stays with the basics:

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

proxies:
  - name: example-node
    type: socks5
    server: 127.0.0.1
    port: 1080

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

rules:
  - DOMAIN-SUFFIX,example.org,PROXY
  - MATCH,DIRECT

This type of configuration avoids branch-specific advanced features, so migration is relatively straightforward. Real subscriptions may also include remote rule providers, health checks, interface bindings, traffic sniffing, new protocol parameters, and client override settings. Looking at only the first few lines cannot establish whether the entire configuration is compatible.

Migrating from the original Clash to mihomo

Migration is usually straightforward in this direction. Start mihomo with the existing configuration, review parsing and runtime logs, and then enable new features one at a time. Do not switch to TUN, replace the DNS mode, and rewrite the rule sets during the first launch. A safer order is to confirm that a node can connect, verify proxy-group switching, check rule matches, and handle TUN and DNS last.

If the configuration comes from a subscription, the client may append overrides after downloading it, such as changing the port, adding local rules, replacing proxy groups, or enabling LAN access. The exported YAML may not exactly match the runtime configuration. When behavior differs, use the client’s runtime-configuration viewer or query the external controller to confirm what the kernel actually loaded.

Rolling back from mihomo to the original Clash

Reverse migration requires removing extension fields one by one and confirming that every node protocol remains supported by the older kernel. Removing a single top-level field is not enough: incompatible content may be hidden in proxy nodes, rules, DNS, TUN, rule providers, and proxy-group parameters. A remote subscription will write those fields again at the next update, so a temporary manual fix cannot replace adjusting the subscription template.

If a server provides only a protocol unsupported by the older kernel, configuration conversion cannot automatically turn it into another protocol. Subscription converters can reorganize fields, filter nodes, and combine rules, but they cannot change the handshake method actually provided by the server. In that case, continue using a mihomo kernel that supports the protocol or obtain compatible nodes from the configuration source.

Client selection: check system integration before the kernel version

Most users do not run a kernel separately; they install a graphical client. Evaluate “how easy the frontend is to use” and “whether the kernel supports the configuration” as two separate questions. A polished client with a kernel that has not been updated for a long time may fail to load newer subscriptions. A client with a current kernel but no system-service management may be unsuitable for keeping TUN enabled long term.

Windows desktop

On Windows, check the mihomo kernel version, service mode, TUN permission handling, system-proxy restoration, and log access. If you only use a browser and standard office software, system-proxy mode is usually easier to maintain. For games, command-line tools, store apps, or software that ignores system proxy settings, evaluate TUN instead. Before enabling it, record the existing DNS settings, other virtual adapters, and security-software status so you can roll back if the network goes offline.

Some Windows clients let you switch between multiple kernels. After switching, do not merely restart the interface; confirm in the runtime log that the kernel name and version have changed. If an old configuration contains Premium-only fields, check whether the client converts them automatically. The system proxy port must match the kernel’s listening port; otherwise the interface may show that proxying is enabled while applications connect to an empty port.

macOS desktop

On macOS, check whether the client supports the current processor architecture, system extensions or network permissions, and whether it restores proxy settings on exit. Some older-named clients may now package mihomo through updates, so the product name is not a reliable indicator of the kernel. On Apple Silicon devices, prefer a build for the matching architecture to avoid mistaking compatibility-layer issues for proxy-kernel failures.

When using the system proxy, verify that the client correctly sets the HTTP, HTTPS, and SOCKS entries. With TUN, check the virtual interface, default route, and LAN access. Managed corporate devices may restrict network extensions or administrator authorization; that is a system-policy boundary that changing the configuration file alone cannot solve.

Linux desktop and servers

On a Linux desktop, you can use a graphical mihomo client or run the kernel directly. Servers are better suited to command-line configuration with a systemd service, making it easier to fix the working directory, limit permissions, restart automatically, and inspect logs through journal. Note that setting HTTP_PROXY and HTTPS_PROXY in a shell affects only programs that read those environment variables; it is not the same as global traffic interception.

TUN deployment also involves network namespaces, routing rules, forwarding settings, and container networking. Whether requests from a Docker container pass through mihomo on the host depends on the network mode and routing design. On a server, do not copy a desktop client’s generated configuration directly; it may contain relative paths, controller addresses, or local rule files intended only for the interface.

Android and iOS

Mobile operating systems usually intercept traffic through the system VPN interface, so frontend control over the kernel lifecycle and background operation matters more than on desktop. Confirm the kernel actually integrated into the app, supported proxy protocols, per-app routing capabilities, and system-version requirements. A mobile client’s “VPN” label indicates a local traffic entry point, not necessarily a connection to a traditional corporate VPN; rules and proxy groups still determine whether traffic is direct or forwarded.

On iOS, a desktop kernel file cannot simply be placed inside an app and run. The kernel features available to an app depend on its packaged build and implementation under system review requirements. Android also has manufacturer-specific background restrictions, battery optimization, and VPN persistence policies. If a node works on desktop but frequently disconnects on mobile, check the operating system’s background limits as well as the subscription.

Choose based on the use case

For new deployments, a maintained mihomo build is usually the more sensible choice. The reason is not simply a newer name: the configuration ecosystem, protocols, and operating-system network stacks continue to evolve. A stable legacy environment does not need to be replaced immediately without backups and testing, but record the current kernel, client version, configuration source, and startup parameters so the setup can be reproduced if something fails.

When several devices are managed from one subscription, standardize the major kernel version and keep a small set of platform-specific overrides for desktop and mobile. Keep nodes, proxy groups, and rules in the shared portion; use platform overrides for TUN, listen addresses, interface bindings, and LAN access. This prevents platform-specific fields required by one device from being added to every configuration.

Migration workflow: verify progressively with the fewest variables

1. Record the current state. Save the client version, kernel name, kernel version, configuration source, system proxy port, and whether TUN is enabled. Screenshots can help with orientation, but text logs and configuration files are better for comparison.
2. Back up local overrides. A subscription URL usually provides only the remote base configuration; local rules, proxy-group changes, and DNS exceptions may be stored in the client database. Before upgrading, use the client’s export function to preserve them.
3. Test the basic proxy first. Disable TUN and complex DNS overrides, then verify one node through the system proxy or an explicit SOCKS connection. After confirming a successful handshake, check proxy groups and rules.
4. Check rule matches. Visit destinations that should be direct and destinations that should use the proxy, and confirm the destination domain, rule type, and final policy in the logs. Whether a webpage opens does not show whether it used the expected egress.
5. Enable DNS settings. Confirm that the kernel’s listening port is not already in use, then check that domain resolution is handled by the expected server. With Fake IP, separately test LAN devices, intranet domains, and incompatible applications.
6. Enable TUN last. Check administrator permissions, the virtual interface, automatic routing, and DNS hijacking. If the network goes offline, disable TUN and restore the system proxy first, then read the logs. Do not repeatedly switch between multiple network tools.
7. Complete a restart test. Restart the system or service and confirm that the client restores its configuration, the subscription does not overwrite critical settings, and the system proxy and routes are recreated as expected.

Common misdiagnoses and how to investigate them

The interface says Meta, so it must be an old kernel: Not necessarily. Meta may only be historical client naming. Read the startup log or kernel version endpoint to identify the actual binary.

The subscription imported successfully, so the configuration is fully compatible: Not necessarily. Frontend import, kernel parsing, node handshake, and rule execution are separate stages. Inspect the logs layer by layer.

Switching to mihomo means TUN must be enabled: Not necessarily. mihomo also supports HTTP, SOCKS, and mixed ports. If the system proxy meets the need, continue using the simpler interception method.

Configuration conversion resolves every protocol difference: Not necessarily. A converter can rearrange configuration, but it cannot change the server protocol or give an older kernel a missing implementation.

Proxy groups with the same name behave identically on every device: Not always. Health-check intervals, latency-test URLs, network permissions, and kernel versions can all change automatic selection. Compare the group type, candidate nodes, and test parameters.

Conclusion: use mihomo as the baseline for new deployments and migrate legacy setups for compatibility

The original Clash provides a widely reused configuration and rule model, but its project is archived. Clash.Meta was the former name of the extension branch, while mihomo is the current name adopted by that branch. Treating Meta and mihomo as two competing old and new kernels leads to incorrect version assumptions. Instead, confirm the actual kernel through the project lineage, the client’s packaged version, and runtime logs.

Basic system proxying, simple rules, and traditional node protocols place relatively few demands on the kernel. New protocols, complex rule sets, fine-grained DNS, traffic sniffing, and TUN interception rely more heavily on current mihomo capabilities. For new installations, prefer a maintained client that clearly integrates mihomo. For an existing legacy setup, record its state, test the migration with a minimal configuration, and then restore DNS, rule sets, and TUN step by step.

The final standard is neither the client name nor whether the subscription file imports. The kernel must parse the configuration completely, establish stable node connections, match rules as expected, and restore network state after a system restart. Validating these four points turns a kernel upgrade from an all-at-once replacement into an observable, reversible engineering process.