What’s New in the mihomo Kernel? A Complete Feature Comparison with the Original Clash Kernel

First, distinguish the original Clash, Clash Meta, and mihomo

The “original Clash” here generally refers to the open-source Clash kernel maintained by Dreamacro. It reads YAML configuration, establishes proxy connections, evaluates rules, and provides proxy services to local applications through HTTP, SOCKS5, or a mixed port. After the original project stopped receiving updates, the community fork Clash Meta continued expanding protocol, rule, DNS, and transparent proxy support. The project was later renamed mihomo.

Clash Meta and mihomo are therefore not two kernels that require choosing one over the other. The former is the old name; the latter is the current name. Some client interfaces, subscription converters, and older configurations still display “Meta”, so check the actual kernel version rather than relying only on the client name.

The kernel and the graphical client should also be understood separately. The client handles the tray menu, configuration downloads, system proxy toggles, and log display; the kernel is what actually recognizes fields such as proxies, rules, dns, and tun. When the same configuration behaves differently in two clients, the usual cause is not the interface but a different kernel type or version bundled with each client.

Core scope of the comparison

Protocol support: more than just new proxy types

The original Clash already handles common nodes such as Shadowsocks, VMess, Trojan, Snell, SOCKS5, and HTTP. Building on that foundation, mihomo continues to add protocol and transport implementations, notably VLESS, XHTTP, Reality, TUIC, Hysteria, Hysteria2, WireGuard, and more Shadowsocks plugins and transport combinations. The exact fields available still depend on the kernel version, so when a subscription contains new fields, first confirm that the bundled mihomo is recent enough.

VLESS and Reality

The original Clash does not recognize VLESS nodes in a mihomo configuration. mihomo can read type: vless and process fields such as uuid, flow, network, and tls. Reality configurations may also include reality-opts, public-key, and short-id. Passing these fields directly to the original kernel will usually trigger an unsupported proxy type or field error during configuration validation.

proxies:
  - name: vless-reality-example
    type: vless
    server: example.net
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    network: tcp
    tls: true
    udp: true
    servername: www.example.com
    reality-opts:
      public-key: example-public-key
      short-id: "01234567"
    client-fingerprint: chrome

This example only demonstrates the field hierarchy. The address, UUID, public key, and short ID must come from an actual service configuration. Reality parameters must match as a set; simply changing a standard VLESS node’s tls to true is not enough.

TUIC and Hysteria2

TUIC and Hysteria2 are both built on QUIC and UDP, but their configuration fields are not interchangeable. Common TUIC fields include uuid, password, congestion-controller, and udp-relay-mode; common Hysteria2 fields include password, obfs, obfs-password, and bandwidth parameters. The protocol supplied by the node provider must match the type in the kernel configuration.

• When the network allows TCP only, these UDP-based protocols may be unable to establish a connection.
• After switching between Wi-Fi and cellular data, a QUIC session may need to be established again.
• Passing a latency test does not guarantee higher throughput for large files; packet loss and carrier throttling also matter.
• When a client reports “configuration valid”, it only means the YAML can be parsed—not that the server-side parameters match.

Global TLS fingerprints

mihomo supports setting a global client fingerprint with global-client-fingerprint, while individual proxy nodes can also specify client-fingerprint. Common values include chrome, firefox, safari, ios, and random. A node-level field is usually more specific than the global setting, so avoid writing conflicting values during migration.

global-client-fingerprint: chrome
unified-delay: true
tcp-concurrent: true

unified-delay standardizes latency calculation so test results better reflect the complete connection process; tcp-concurrent tries multiple resolved IP addresses concurrently and continues with the connection that succeeds first. These are common top-level mihomo extensions, and configurations for the original Clash should not depend on them.

Rules: from sequential matching to logical composition

Both kernels follow the basic rule order of “top to bottom; stop at the first match”. Common original Clash rules include DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD, IP-CIDR, GEOIP, PROCESS-NAME, RULE-SET, and the final MATCH. mihomo retains these forms while adding more network attributes and logical composition capabilities.

AND, OR, and NOT

Logical rules are useful for expressing conditions that must be met together or for excluding a condition. For example, UDP traffic destined for port 443 can be routed to a specific policy group by combining network and port conditions. Parentheses and comma nesting are strict, so run the kernel’s validation command first instead of overwriting an active configuration.

rules:
  - AND,((NETWORK,UDP),(DST-PORT,443)),QUIC policy
  - OR,((DOMAIN-SUFFIX,example.com),(DOMAIN-SUFFIX,example.net)),Proxy
  - NOT,((GEOIP,CN)),Traffic outside mainland China
  - MATCH,Final choice

The value of logical composition is not simply reducing the number of rules; it avoids splitting one condition into several duplicated lists. As rules become more complex, place frequent, precise domain rules first, and broad GEOIP rules, rule sets, and MATCH later.

Port, network, and process rules

mihomo can route traffic based on source port, destination port, inbound type, network protocol, and process path. Common fields include SRC-PORT, DST-PORT, IN-TYPE, NETWORK, PROCESS-NAME, and PROCESS-PATH. DNS commonly uses port 53, HTTPS commonly uses port 443, and a local mixed port is often configured as 7890.

Rule providers and sub-rules

rule-providers remains the primary way to maintain large domain and IP rule lists. mihomo supports behavior types such as domain, ipcidr, and classical, and can use YAML text or payload formats such as MRS. A provider’s behavior must match its file contents: a pure domain collection should not be labeled ipcidr, while a list containing complete rule syntax should use classical.

rule-providers:
  private-domains:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/private-domains.yaml
    url: https://example.net/rules/private-domains.yaml
    interval: 86400

rules:
  - RULE-SET,private-domains,DIRECT
  - MATCH,Proxy

interval: 86400 means checking for updates every 86,400 seconds, or 24 hours. If a remote rule fails to download for the first time, the kernel cannot generate its contents; check URL accessibility, file format, write-directory permissions, and the HTTP status code in the logs.

TUN mode: broader interception and a more complete protocol stack

The system proxy affects only applications that actively read proxy settings. Browsers can usually use it, but games, command-line tools, some store apps, and software that creates UDP sockets directly may bypass it. TUN mode creates a virtual network interface and passes IP traffic matching the routing conditions to the kernel, providing broader coverage.

The open-source original Clash and the older Premium kernel historically had different TUN capability boundaries. mihomo places TUN, DNS hijacking, automatic routing, and traffic sniffing in one continuously maintained configuration system, with protocol-stack options such as system, gvisor, and mixed. Availability on each platform still depends on the operating system and client permissions.

tun:
  enable: true
  stack: mixed
  dns-hijack:
    - any:53
    - tcp://any:53
  auto-route: true
  auto-redirect: true
  auto-detect-interface: true
  strict-route: true

Choosing among the three stacks

• system: relies more heavily on the system network stack, usually offering good performance and OS compatibility, though behavior depends on the operating system implementation.
• gvisor: uses a user-space network stack to handle more protocol details with clearer isolation; it can help with comparison testing in unusual network environments.
• mixed: combines handling by connection type and is a common starting point on desktop systems, but follow the recommendations of the actual client.

auto-route automatically adds routes so traffic enters TUN; auto-detect-interface identifies the current outbound network interface; strict-route more strictly limits bypass paths. Routing differs across Windows, macOS, and Linux. If a LAN printer or NAS becomes unreachable after enabling these options, first check that private subnets are routed directly as intended instead of immediately changing the proxy node.

Traffic sniffing fills in missing domain information

Connections intercepted by TUN sometimes contain only the destination IP and no original domain. mihomo’s sniffer can extract a domain from a TLS ClientHello, HTTP Host header, or QUIC handshake, then pass it to domain-rule matching. This helps prevent cases where a domain rule is configured but the connection matches only an IP rule.

sniffer:
  enable: true
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443
  skip-domain:
    - Mijia Cloud

Sniffing is not a replacement for DNS resolution, and it cannot recover complete domains from every encrypted connection. Limit the port range in the configuration, and use skip-domain to exclude services whose destination information should not be rewritten. During troubleshooting, temporarily disable sniffing and compare the results to determine whether the issue comes from the node, DNS, rules, or domain overrides.

DNS and GEO data: significantly more control

The original Clash provides nameserver, fallback, fallback-filter, enhanced-mode, and fake-ip-filter. mihomo retains these fields and adds finer controls such as default-nameserver, proxy-server-nameserver, direct-nameserver, nameserver-policy, and respect-rules.

The roles of different nameservers

• default-nameserver: primarily resolves the hostnames of other DNS servers; it is usually set to servers reachable directly by IP address.
• nameserver: handles ordinary domain resolution and serves as the main upstream in the DNS configuration.
• proxy-server-nameserver: resolves proxy node hostnames separately, preventing node address resolution from entering a proxy loop.
• direct-nameserver: provides a dedicated upstream for domains determined by the rules to use a direct connection.
• nameserver-policy: assigns DNS upstreams by domain or rule set for more granular resolution paths.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query

The example makes the kernel listen for DNS on port 1053 instead of directly occupying the commonly used system port 53. TUN’s dns-hijack then sends matching queries on port 53 into the kernel. If a local DNS service already runs on the system, check port usage first to prevent two processes from listening on the same address.

GEOIP, GEOSITE, and GeoSite.dat

GEOIP matches based on the region associated with the destination IP, while GEOSITE matches maintained domain categories; they are different data types. Domain rules may match before DNS resolution, whereas GEOIP generally requires the destination IP first. Sending all traffic through GEOIP cannot replace domain categorization and may add post-resolution matching overhead.

mihomo provides top-level settings such as geodata-mode, geodata-loader, geox-url, geo-auto-update, and geo-update-interval to control data format, loading method, download location, and update frequency. Some versions also support separate URLs for GeoIP, GeoSite, MMDB, and ASN data.

geodata-mode: true
geo-auto-update: true
geo-update-interval: 24
geox-url:
  geoip: https://example.net/data/geoip.dat
  geosite: https://example.net/data/geosite.dat
  mmdb: https://example.net/data/country.mmdb
  asn: https://example.net/data/ASN.mmdb

geo-update-interval: 24 is generally interpreted in hours, meaning updates are checked every 24 hours. Supported fields and data formats vary across mihomo versions, so consult the current kernel documentation and startup logs before deployment. If a download URL returns an HTML error page, data loading will still fail even when the HTTP status appears successful.

Which fields cause problems when moved back to the original Clash

Basic fields such as port, socks-port, mixed-port, allow-lan, mode, log-level, proxies, proxy-groups, and standard rules are generally easy to keep compatible. Migration failures are more often caused by mihomo-only node types, logical rules, and enhanced top-level settings.

Validate first, then replace the active configuration

After editing the YAML, validate it in a separate directory first. A common mihomo command format is shown below; -d points to the working directory containing the configuration and data files, while -f specifies the configuration file:

mihomo -t -d ./mihomo-work -f ./config.yaml

Passing validation only confirms that the syntax, fields, and local files can be read at a basic level. Also check node handshakes, rule-provider downloads, DNS listening, and TUN routes in the runtime logs. At minimum, test four cases: visit a site that should connect directly, visit one that should use the proxy, make one UDP request, and disable the system proxy to verify that TUN still captures the target application’s traffic.

How to tell whether you need mihomo

If a configuration uses only Shadowsocks, VMess, Trojan, and simple domain rules, and the system proxy covers every application, switching kernels may make little visible difference. Stability still depends mainly on node parameters, rule order, and the DNS path—not the kernel name itself.

mihomo is a better fit when a subscription includes VLESS Reality, TUIC, or Hysteria2; when TUN is needed to capture games and command-line programs; when routing should be based on processes, inbounds, or logical conditions; when node-hostname DNS needs separate management; when using GEOSITE, ASN, MRS rule sets, or automatic GEO updates; or when domain recovery through sniffing is needed in transparent-proxy scenarios.

1. Open “Settings” → “Kernel” in the client and check the actual kernel name and version.
2. Export the current configuration and search for type: vless, type: tuic, type: hysteria2, sniffer:, and geox-url:.
3. Run configuration validation and resolve unknown fields, indentation errors, and missing data files.
4. Open the logs and temporarily set the level to info; use debug only briefly when troubleshooting complex connections.
5. Enable TUN, DNS hijacking, and sniffing one at a time instead of changing the entire network path at once.