Clash, Clash Meta, and mihomo Explained: Choosing the Right Kernel

Start with the names: clients, kernels, and project history

Before comparing the original Clash, Clash.Meta, and mihomo, separate the concepts of a client and a kernel. The kernel reads YAML configuration, establishes proxy connections, matches rules, handles DNS, and exposes control interfaces to the graphical interface. A desktop client manages subscriptions, switches configurations, toggles the system proxy, displays logs, and handles updates. The application name users see does not necessarily match the kernel it actually runs, and the same graphical client may switch kernels between versions.

The original Clash usually refers to the classic open-source Clash kernel and configuration ecosystem maintained by Dreamacro. It established the core structures for proxy nodes, proxy groups, rules, and external controllers, and many subscription converters and graphical clients still use this format as their foundation. Historically, Premium builds with different feature sets also existed, so seeing “Clash” alone is not enough to determine which fields are supported.

Clash.Meta began as an extended kernel designed to remain compatible with the Clash configuration model while adding more proxy protocols, DNS options, rule capabilities, and transparent-proxy features. The project later adopted mihomo as its official name. Clash.Meta and mihomo are best understood as earlier and current names along the same project lineage, not as two entirely separate kernels that require a one-or-the-other choice. Meta configurations in older guides and Meta Core in legacy clients often refer to what is now the mihomo family.

After the original Clash project became inactive, its ecosystem did not disappear with the name. Subscription formats, rule syntax, and control interfaces are still widely used, while actively maintained clients have increasingly moved to mihomo. For a new installation or long-term deployment, focus less on finding the earliest name and more on maintenance status, platform support, required protocols, and configuration-field compatibility.

Feature coverage: the common foundation and mihomo extensions

Both kernel families share support for YAML configuration, proxy nodes, proxy groups, domain and IP rules, DIRECT and REJECT actions, mixed HTTP/SOCKS ports, and external control interfaces. With configurations containing only common node types, simple proxy groups, and basic rules, users may notice little difference. Differences usually appear when a subscription includes newer protocols, complex DNS settings, TUN mode, or remote rule providers.

Proxy protocols and transport parameters

The original Clash supports the mainstream protocols covered during its active maintenance period, but newer protocols, encryption methods, and transport extensions do not gain support automatically. Building on traditional configuration compatibility, mihomo continues to add protocol implementations and parameter options. If subscription nodes are labeled “unsupported type,” or logs report that proxy fields cannot be parsed, check the kernel first instead of repeatedly importing the same subscription.

Protocol count is not the only measure. Even with the same node type, kernels may differ in their support for TLS fingerprints, UDP, multiplexing, transport layers, and certificate-related parameters. Choose based on the fields actually generated by the subscription, not merely on whether the node name appears in the list. A node appearing in the interface does not mean all its connection parameters were recognized.

DNS and rule systems

Classic Clash configurations already support common structures such as domain rules, IP rules, GEOIP, and rule providers. mihomo builds on this with richer DNS handling, rule-set capabilities, and matching options, making it suitable for configurations that distinguish DNS resolution in mainland China from outside China, handle Fake IP exceptions, load large rule sets, or finely control traffic. Fields can change between kernel versions, so consult the current kernel documentation and startup logs.

More rule features also make configuration errors easier to hide in a long file. For example, a rule-set name may be declared while its referenced path is unreachable; a DNS nameserver may be reachable but routed back through the proxy by the current rules, creating a loop; or a broad earlier match may prevent a later specific rule from ever being reached. Upgrading the kernel does not replace rule review—match results in the logs remain the primary evidence.

TUN and transparent proxying

The system proxy mainly affects applications that actively read the operating system’s proxy settings. TUN mode uses a virtual network interface to capture a broader range of IP traffic, making it useful for applications that ignore the system proxy, require UDP, or need their traffic handled centrally. TUN capabilities varied across original Clash builds, while mihomo continues to maintain its TUN stack, routing, DNS hijacking, and platform-specific options. Modern desktop clients and gateway deployments therefore generally favor mihomo.

TUN does not automatically make a connection faster after installation. It adds variables involving permissions, routing tables, virtual network adapters, firewalls, and the DNS path. If you mainly browse the web and your applications follow the system proxy, the system proxy is often easier to maintain. Enable TUN when you need to capture games, command-line programs, sandboxed applications, or software that cannot configure a proxy itself.

Configuration compatibility: basic configurations often load, but extensions are not backward-compatible by default

One goal of mihomo is to carry forward the Clash configuration ecosystem, so traditional structures for ports, nodes, proxy groups, and rules can usually be read directly. The relationship is closer to “a newer kernel reading an older format” than to complete equivalence in every direction. Once a configuration uses mihomo-only protocols, rule types, DNS fields, or TUN parameters, passing it to the original kernel may cause startup failures, ignored unknown fields, missing nodes, or changed behavior.

Here is a basic structural example. It demonstrates the references between nodes, proxy groups, and rules; it is not ready for production as-is. The server address and authentication details must come from the actual subscription.

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: example-node
    type: socks5
    server: 192.0.2.10
    port: 1080
    username: demo
    password: demo

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

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

When migrating this type of configuration, do not focus first on visual differences beyond indentation. Check the reference chain: node names in proxy groups must exactly match the node definitions, the policy name at the end of each rule must exist, and remote provider names must correspond to the proxy groups or rules that reference them. YAML is sensitive to indentation. Mixing tabs and spaces, omitting the space after a colon, or misaligning indentation between sibling fields can all cause loading failures.

A subscription URL does not define a fixed kernel format

A subscription service may return different content based on the client’s request headers, URL parameters, or conversion template. The same subscription URL may produce a basic Clash format in one client and a configuration containing mihomo extensions in another. If the node count changes after switching clients, do not assume the subscription has failed. Export the configurations first and compare node types, proxy providers, proxy groups, and rule-set fields.

Some clients save only the subscription entry and overwrite local edits during updates. If you need to add rules, check whether the client supports overrides, extension scripts, or configuration merging. Direct edits to a cached file usually last only until the next subscription update. The kernel interprets the final configuration, while the client controls how the subscription is downloaded, converted, and merged; troubleshoot these as separate stages.

Control interfaces are often similar, but the management UI still needs to match

Many Clash management panels use the external controller to read proxies, connections, rules, and logs. mihomo preserves many commonly used interfaces, so older panels may continue to work, but new features may not be displayed completely in an older UI. If the kernel runs normally but the interface lacks a particular setting, the client or panel may not have implemented that control yet; it does not necessarily mean the kernel configuration is invalid.

Choosing by use case: desktops, servers, and legacy configurations

A fresh desktop installation

For a fresh installation on Windows, macOS, or Linux, prioritize a client that is actively maintained and explicitly uses the mihomo kernel. This makes it easier to receive support for newer protocols, current operating-system changes, and ongoing fixes. When choosing an installer, also verify the operating-system version and CPU architecture; x64 and ARM64 cannot be distinguished reliably by file size alone.

If you only need to import a subscription, choose a proxy group, and enable the system proxy, there is no need to change advanced settings immediately just to get “more features.” Start with the default ports and DNS settings generated by the client. Confirm that browsing, rule switching, and recovery after disconnecting work normally, then enable TUN if needed. Fewer variables during initial setup make troubleshooting more direct.

Server, router, and container deployments

Servers and transparent gateways often lack a full graphical interface, so the kernel’s architecture build, startup arguments, configuration path, and service-management method matter more. mihomo suits deployments that need rule sets, transparent proxying, remote control, and ongoing updates, but you must also handle runtime permissions, forwarding rules, the DNS entry point, and log rotation. Enabling TUN in a container also requires the appropriate device and network permissions.

Avoid copying a desktop configuration directly into a gateway deployment. A desktop listener may bind only to the local machine; on a LAN, explicitly define the allowed interface and access controls. Do not expose the external controller without authentication and network restrictions. With large rule sets, also monitor startup time, memory usage, and behavior when remote rule updates fail.

An original Clash configuration that is still stable

If an original Clash configuration is simple, runs in a fixed environment, and currently connects reliably, there is no need to rewrite it immediately just because the name has changed. A safer approach is to prepare mihomo in an isolated directory, copy the configuration for syntax checks and parallel testing, and switch services only after confirming that nodes, proxy groups, DNS results, and rule matches are consistent.

The main limitation of staying on an older kernel is the lack of ongoing adaptation to new protocols and system changes. If a subscription provider switches node types, the old kernel may suddenly fail to parse them. After an operating-system upgrade, an older client may also encounter compatibility issues with permissions, the tray, virtual adapters, or signing. You can retain a working configuration, but prepare a migration path at the same time.

When legacy fields or an older client are required

Some automation scripts, control panels, or embedded devices are built around a fixed Clash API and file layout. First identify the dependency: configuration syntax, control interface, binary name, or startup arguments. With suitable parameters and path arrangements, mihomo can remain compatible with many workflows, but do not assume every surrounding tool needs no changes. Run it on a test port first to avoid conflicts with existing controllers and listeners.

Migrating from the original Clash to mihomo: a step-by-step checklist

1. Record the current setup. Save the original configuration, subscription URL, client version, kernel version, listening ports, and currently enabled proxy mode. If something goes wrong, you can roll back accurately and compare the results.
2. Choose a matching build. Verify the operating system and CPU architecture. Desktop users should confirm the kernel type bundled with the client; command-line deployments should download the mihomo executable for the target platform.
3. Validate the configuration first. Do not replace a running service as the first step. Use the new kernel to check the YAML and resolve unsupported proxy types, duplicate ports, missing proxy groups, and unreadable providers.
4. Review the startup logs. Pay particular attention to configuration parsing, rule-set downloads, DNS listeners, the external controller, the TUN device, and port conflicts. Reaching “started” in the logs does not mean every remote resource loaded successfully.
5. Verify proxy groups. Check manual selection, automatic latency testing, failover, and other proxy groups one by one to confirm they contain the expected nodes. After subscription conversion, changed node names may invalidate older references.
6. Verify DNS. Test mainland-China domains, proxied destination domains, and direct IP connections separately. If a browser works while the command line fails, or domains fail while IP connections work, inspect the DNS listener and hijacking path first.
7. Enable TUN last. After confirming that system proxy mode works normally, test traffic capture through the virtual adapter. If the entire network goes offline, check administrator privileges, the default route, DNS hijacking, other VPN software, and firewall rules.

Common migration mistakes

• The client was upgraded, but the underlying kernel is still on an old version; the client version and kernel version were treated as the same thing.
• Treating Meta and mihomo as two unrelated formats and converting the subscription twice, causing proxy groups or rules to be processed a second time.
• Copying mihomo-only fields back into the original Clash and discovering that the types or parameters are unsupported only when the configuration is loaded.
• Testing only whether the homepage opens, without checking rule matches, UDP, DNS, LAN access, or network recovery after disconnecting.
• Encountering problems with the system proxy and TUN enabled together, without testing the two traffic-capture paths separately.

If the new kernel starts with no network access at all, first switch back to a basic rule-mode configuration and temporarily disable TUN. Confirm that the mixed port is listening, the node handshake succeeds, and the proxy group selection is correct before restoring enhanced DNS and rule sets one at a time. Layered activation is easier to troubleshoot than importing every advanced option at once.

Conclusion: prioritize mihomo for new deployments and migrate legacy configurations as needed

The original Clash established the configuration and rule foundations still widely used today. Clash.Meta was the earlier name for the extension path, while mihomo is the current project name on that path. These are not simply a matter of higher or lower version numbers; they reflect different stages of maintenance, feature coverage, and ecosystem continuity.

For a new desktop installation or requirements involving modern protocols, complex DNS, rule sets, or TUN, choose a client that clearly uses mihomo and is actively maintained. If an existing original Clash configuration is stable, keep it for now and complete the migration in a test environment. The reliable criteria are not the names, but whether the current kernel can fully parse the subscription, apply rules correctly, support the operating system, and provide a sustainable update path.

After installation, check the kernel information before importing the subscription; verify the system proxy before enabling TUN for your use case; read the startup logs before changing advanced fields. Following this order keeps the naming differences between the original Clash, Meta, and mihomo from becoming a troubleshooting obstacle.