mihomo vs. the original Clash core: new protocols, rule-provider syntax, and TUN implementation compared

First, distinguish the core, the client, and Clash Premium

Before comparing cores, separate these three layers. The core parses configuration, establishes proxy connections, handles DNS, and matches rules. Desktop and mobile clients manage configuration, tray menus, subscription updates, and permission requests. Subscriptions provide nodes, proxy groups, and rule data. A client with Clash in its name does not necessarily run the original Clash core or support every mihomo configuration.

The original open-source Clash core and Clash Premium are not the same feature set. Premium was a closed-source enhanced core from the original project, historically including features such as TUN and rule sets. mihomo is the open-source core that continued from Clash Meta. It retains much of Clash's YAML configuration structure while extending protocol, routing, and DNS support. The original project is no longer maintained. When migrating, check the actual binary version rather than treating an old client name as a feature list.

Check the actual version from the command line

mihomo -v
mihomo -t -d ./mihomo-data -f ./config.yaml

The first command displays the current binary's version. The second specifies a working directory and configuration file, then tests the configuration. The file must already exist; a successful test only confirms that the configuration parses, not that the nodes work. A GUI client may use a bundled core, so the mihomo in your terminal may differ from the binary launched by the client. Check the client logs as well.

New protocols: VLESS, REALITY, and Hysteria2

The clearest difference between mihomo and older cores is whether they can recognize the node types and parameters in a subscription. Common protocols in the original Clash include Shadowsocks, VMess, Trojan, SOCKS, and HTTP. mihomo adds support for VLESS, Hysteria2, TUIC, and REALITY in specific protocol combinations. Changing only the YAML type does not convert an existing node to another protocol; the server must provide the corresponding endpoint.

Assess protocol support separately from network conditions

Hysteria2 and TUIC use QUIC and rely on UDP. If a LAN, firewall, or carrier network restricts UDP, handshakes may time out even when the configuration test passes. VLESS behavior depends on the actual transport, so don't assume all VLESS nodes behave the same way on the network. The protocol name alone does not guarantee lower latency or higher throughput.

• Unsupported node type: First confirm that the client actually launched mihomo and that the subscription is formatted for that core.
• Authentication failed: Check the UUID, password, and server protocol version before changing DNS.
• TLS handshake error: Check the system clock, SNI, and certificate requirements. Don't treat disabling certificate verification as a routine fix.
• Persistent QUIC timeouts: Test on another network, then check outbound UDP and the server status.

rule-providers: keep the structure, check behavior and format

rule-providers is not exclusive to mihomo; Clash Premium already supports it. You can usually keep the basic structure: declare a rule set, then reference it with RULE-SET. The rule set describes what to match, while the reference in rules specifies the policy to apply when a match is found. Keep the two separate.

Example of a local domain rule set

Merge the snippet below into your existing configuration. It sends the example domain rules to DIRECT and does not depend on a node name. The working directory must contain rules/local-domains.yaml. If rule-providers or rules already exists, merge the entries instead of adding another top-level key with the same name.

rule-providers:
  local-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-domains.yaml

rules:
  - RULE-SET,local-domains,DIRECT
  - MATCH,DIRECT

Contents of rules/local-domains.yaml:

payload:
  - '+.example.com'
  - 'intranet.example.net'

+.example.com matches the domain and its subdomains. This example uses a direct-connection fallback to demonstrate how the reference works; it is not a drop-in replacement for your existing proxy setup. When migrating, keep your own proxy groups and final fallback rule.

The three behavior values are not interchangeable

• domain: Entries are domains or supported domain-matching expressions, without a DOMAIN-SUFFIX prefix.
• ipcidr: Entries are address ranges, such as 192.168.0.0/16, not complete rule statements.
• classical: Entries are rule expressions, such as DOMAIN-SUFFIX,example.com. They typically don't include a policy name at the end.

Putting DOMAIN-SUFFIX,example.com in a behavior: domain file creates a content-format mismatch, even if the YAML indentation is correct. When checking a rule set, inspect both the provider declaration and the downloaded file; the file extension alone isn't enough.

Rule-set format extensions in mihomo

mihomo supports YAML, plain text, and rule-set formats such as MRS. MRS is a binary format for rule sets and works with domain and ipcidr, not classical. Don't assume an older Premium configuration can read MRS. Before using these formats, check your mihomo version and the rule source documentation. Avoid copying newer configuration fields into an older core.

Rules are still matched from top to bottom. If you put MATCH before rule-set references, the rules after it won't get a chance to match normally. When troubleshooting routing, check the matched rule and applied policy in the connection details first—not just the currently selected node in a proxy group.

TUN implementation: stack selection, route capture, and system permissions

System proxy and TUN are different traffic entry points. A system proxy directs applications that honor system settings to a proxy port. TUN creates a virtual network interface that receives IP traffic through routing rules. TUN is better suited to applications that ignore the system proxy, but whether it captures a connection still depends on routes, interface selection, exclusions, and operating-system permissions.

The original open-source Clash core and Premium differ in their TUN capabilities, so it's inaccurate to say that every Clash version includes TUN. Premium's historical TUN implementation was associated with the gVisor stack; mihomo offers stack options such as system, gvisor, and mixed. Check support for your platform and version rather than copying a TUN section from another core.

Desktop configuration snippet

mixed-port: 7890
allow-lan: false
mode: rule

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

Here, 7890 is an example mixed-proxy port, not a fixed value for all clients. auto-route configures routes automatically, while auto-detect-interface helps select the outbound interface; neither replaces permission requests. Windows typically requires a client service or privilege elevation. Linux needs appropriate network-management permissions, and macOS requires authorization according to the client's implementation.

1. Turn off TUN in other VPNs or proxy clients first to reduce route conflicts.
2. Confirm that system proxy mode works, then enable TUN separately to avoid introducing two sets of issues at once.
3. Check the logs for failures creating a virtual interface, adding routes, or obtaining permissions.
4. After switching between Wi-Fi and Ethernet, or waking from sleep, check the outbound interface and routes again.

DNS and Fake-IP: keep the mechanism, recheck the resolution path

Fake-IP is not a new concept in mihomo. It maps addresses to domains to associate domain names with connections, helping the core match rules by domain. When migrating, focus on whether DNS queries reach the core, which domains need real IP addresses, and which resolution path is used for proxy server domains.

Test DNS and TUN separately

dns:
  enable: true
  listen: 127.0.0.1:7874
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - 'localhost'
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

This snippet demonstrates DNS resolution behavior: DNS listens on local port 7874, Fake-IP uses the 198.18.0.1/16 range, and two specific IPv4 DNS addresses serve as upstreams. Choose upstreams based on your network and privacy requirements; these are not guaranteed to suit every connection. fake-ip-filter only excludes domains from Fake-IP allocation. It does not force direct connections or replace local DNS server configuration.

In an environment with dig installed, query the core's DNS directly:

dig @127.0.0.1 -p 7874 example.com A

For domains that don't match a filter, the response will typically contain a mapped address from the configured range. This is expected behavior, not an incorrect public IP returned by the DNS server. Then visit the domain and check the core's connection log to confirm that the connection is associated with the domain and matches the expected rule.

Encrypted DNS and proxy server domain resolution

• Browser DoH: Browsers may bypass the system DNS path. To troubleshoot, route DNS through a consistent resolver first, then compare behavior.
• TUN DNS hijacking: any:53 handles traditional DNS traffic; it does not automatically capture all DoH or DoT requests.
• Proxy server domain resolution: mihomo can use proxy-server-nameserver to specify a resolver for proxy server domains, reducing circular dependencies in the startup resolution path.
• Rules affecting DNS egress: Settings such as respect-rules change how DNS connections are routed. Configure them according to the documentation for your version; enabling a single option is not enough.

If LAN services are inaccessible, check local domain suffixes, router DNS, and subnet rules. Adding only *.lan won't cover every domain used on a corporate network. Enhanced mode can also interact with browser, system, and app caches; mappings from an old cache may persist briefly.

Migration checklist: Clash Premium to mihomo

Migration is less about rewriting every rule and more about finding what depends on the old core. Most basic fields, traditional nodes, and rule statements are a useful starting point, but don't carry over Premium scripts, legacy experimental fields, or specific TUN parameters unchanged. mihomo is not a drop-in replacement for the Premium scripting interface.

1. Back up your configuration and runtime setup: Keep a working copy of your YAML and note the listening ports, selected proxy groups, system proxy, and TUN status. Store subscription URLs securely and don't share them publicly.
2. Check the subscription output format: Prefer the provider's mihomo or Clash Meta format. If nodes use VLESS or Hysteria2, confirm that all protocol parameters are included.
3. Test the configuration: Run mihomo -t and resolve unknown protocols, incorrect field types, rule-file paths, and policy name errors first.
4. Test system proxy only: Disable TUN and verify nodes and rules through an explicit port. For example, if the port is 7890, configure a proxy-capable app to use 127.0.0.1:7890.
5. Check rule sets: Verify behavior, format, local file contents, and rule order. Confirm that every referenced proxy group exists.
6. Enable DNS and TUN separately: Troubleshoot permissions, interfaces, routes, and resolution in that order. Change one variable at a time and keep logs for comparison.
7. Verify client overrides: Check the final runtime configuration. A client may merge or override ports, DNS, TUN, or rules, so editing the subscription source file may not change the values actually in use.

Compare speeds under repeatable conditions

Protocol support doesn't automatically mean faster speeds. When comparing cores, keep the node, test target, network, and time window constant. Record single-connection download speed, concurrent performance, and CPU usage. A latency test measures one request to a specific target; it doesn't represent large-file throughput or prove that every website uses the same route.

mihomo is the core to evaluate when you need additional protocols, regularly updated rule-set support, or more granular DNS configuration. If you only need traditional protocols and a simple system proxy, focus on client maintenance, compatibility with your operating system, and how easy the configuration is to manage. Check the glossary for Fake-IP, proxy groups, and rule sets, then follow the configuration guide to test each step.