mihomo vs. the Original Clash Core: Protocols, Rule Providers, and TUN Support

First, distinguish the original open-source core, Premium, and mihomo

The bottom line: mihomo inherits Clash's configuration system, but the two are not simply the same binary under different names. Continuing the Clash.Meta development line, mihomo adds protocol, rule, and traffic-interception capabilities. Basic fields can often be carried over during migration, but newer configs are not guaranteed to work with older cores.

“Original Clash” can refer to two different things: the original open-source core and the former Clash Premium. Premium included additional features such as rule providers and TUN. Treating them as one and claiming “Clash doesn't support rule providers, and only mihomo supports TUN” would be misleading.

• Client: Provides the interface, manages subscriptions and system proxy settings, and launches the core. The client version is not the core version.
• Core: Reads the config, establishes proxy connections, resolves DNS, and applies rules. The core actually running determines which fields are supported.
• Subscription converter: May generate different node fields for different target cores. A converter can change the output structure, but it cannot add new protocol implementations to an older core.

Check the core information shown by the client or its startup logs, then verify the executable itself. The commands below are for standalone binaries; files bundled with GUI clients may have different names. Don't start a second core just because the filename differs.

mihomo -v
clash -v

Protocol support: importing a node doesn't mean it can connect

Shadowsocks, VMess, and Trojan are common protocols supported by both lines. mihomo adds support for VLESS, Hysteria2, TUIC, and more; check the current core documentation for supported transport combinations and parameters. Historical original-core builds also vary, so don't generalize from one older release to every build.

Check all four layers of node settings when migrating

1. Protocol type: Start with type, such as vless or hysteria2. If the core doesn't recognize the type, switch cores or change the subscription output target.
2. Credentials: Check the password, UUID, and authentication fields. Changing a VMess node's type directly to VLESS does not convert it.
3. Transport: Make sure transport settings such as WebSocket and gRPC match the server, especially the path, Host, and service name.
4. TLS settings: Check the server name, certificate verification settings, and REALITY parameters. Don't disable certificate verification as a substitute for troubleshooting.

Hysteria2 and TUIC use QUIC-based transport and require the network to allow the relevant UDP traffic. A config test only confirms that the fields can be parsed; connections may still fail if the outbound network restricts UDP. Changing cores won't remove network-side restrictions.

rule-providers: Check behavior first, then the file format

rule-providers loads rule sets; it isn't for node subscriptions. Node providers use proxy-providers. After declaring a rule set, you must also reference it in rules with RULE-SET, or it won't be used for matching.

When migrating from Premium to mihomo, existing standard YAML rule sets can often be kept. Check that behavior matches the file contents: classical is for complete rule expressions, domain for domain-matching entries, and ipcidr for IP ranges. These formats can't be mixed by simply changing the declaration.

Example of a local classical rule set

Merge the following snippet into your existing main config. Proxy is an example policy group name; replace it with an existing group or define the group in your config. Paths are relative to the core's working directory, not necessarily the GUI client's installation directory.

rule-providers:
  local-sites:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-sites.yaml

rules:
  - RULE-SET,local-sites,Proxy
  - MATCH,DIRECT

Create rules/local-sites.yaml with the following contents. example.com is a sample domain; replace it with a domain you want to route differently.

payload:
  - DOMAIN-SUFFIX,example.com
  - IP-CIDR,192.168.0.0/16,no-resolve

• A rule file with format: yaml includes payload. For plain-text formats, write entries line by line according to the format's requirements; don't wrap them in YAML.
• mihomo's mrs is a binary rule-set format for domain and ipcidr. You can't use an arbitrary classical file just by changing its extension.
• HTTP-type providers also need an accessible url. interval: 86400 sets the update interval to 86,400 seconds; it is not a connection timeout.
• Rules are still matched from top to bottom. A broad rule near the top can prevent more specific rules below it from matching; MATCH usually goes last.

Domain sniffing: recover domain information, not decrypt HTTPS

A connection to an IP address may not include a destination hostname that domain rules can match directly. mihomo's sniffer can extract domains from HTTP Host headers, server names in TLS handshakes, and recognizable QUIC handshake information to help route traffic. This is not HTTPS decryption, and it cannot recover the domain from every connection.

The following is a mihomo sniffing snippet. Start with override-destination: false, check which rules match, and then decide whether to override the connection destination. This option does not need to be enabled in every config.

sniffer:
  enable: true
  override-destination: false
  sniff:
    HTTP:
      ports: [80, 8080-8880]
    TLS:
      ports: [443, 8443]
    QUIC:
      ports: [443, 8443]

Sniffing and Fake-IP: where each fits

• Fake-IP uses DNS mappings to associate domains with synthetic IP addresses; sniffing attempts to extract domains from connection data. They rely on different sources of information.
• Sniffing may not find a usable domain if an application hard-codes an IP address, uses an unrecognized protocol, or encrypts the handshake information.
• If domain rules are needed but only the destination IP appears, first check whether DNS is handled by the core and whether the mapping is valid. Then check sniffing instead of immediately widening its scope.

If only a few sites behave unexpectedly after migration, temporarily disable sniffing to compare results. Change one setting at a time and check the destination domain, matched rule, and outbound policy in connection details. This helps separate sniffing, DNS, and node issues.

TUN support: test the stack, routing, and DNS interception separately

TUN sends traffic through a virtual network interface. Unlike the system HTTP proxy, it can route traffic from apps that ignore system proxy settings. The original Premium already had TUN, and mihomo continues to expand in this area; TUN support alone is not unique to mihomo.

mihomo's TUN config can use stacks such as system, gvisor, and mixed, depending on the platform and build. mixed combines the system TCP stack with the gVisor UDP stack. Stack names aren't performance rankings; compare them on the same network and with the same node when troubleshooting.

Minimal TUN test snippet

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

This TUN snippet must be merged into an existing config and also requires valid dns settings. auto-route configures routes automatically, while auto-detect-interface detects the outbound interface. Verify the detected interface when multiple VPNs or virtual adapters are in use.

1. Check permissions first: On Windows, a client service or administrator privileges are typically needed to configure the virtual interface. Linux requires the relevant network permissions. Don't mistake a permissions error for a failed node.
2. Then check routing: Confirm that the virtual interface was created and that the target traffic is reaching the core. If there are no connection records in the logs, check the traffic interception path first.
3. Check DNS separately: any:53 applies to standard DNS on port 53 that enters the interception path. Browser-based DoH uses HTTPS and won't automatically become a core DNS query because of this setting.
4. Test UDP last: UDP can be affected by the node protocol, server, outbound network, and client application. Being able to open a webpage doesn't prove that game or voice traffic is working.

Migrate legacy configs in stages and keep a rollback path

The safest order is to validate config parsing, test a standard proxy, then enable DNS, rule sets, and TUN. Replacing the core and enabling every new feature at once makes it hard to identify which change caused a failure.

Step 1: Test the config that's actually in use

The command below checks config.yaml. If the client applies overrides, scripts, or merged configs, test the final runtime file it generates—not just the original subscription download.

mihomo -t -f config.yaml

For an unknown proxy type, check whether the subscription target is mihomo. For a missing policy, check rule references and policy group names. For a rule-set loading error, check the working directory, file path, and format. A passing test doesn't confirm node authentication, network connectivity, or successful updates to remote rule sets.

Step 2: Establish a baseline with a standard proxy

Keep TUN disabled and use the mixed-port in your existing config. If it's set to 7890, run the request below. It explicitly specifies the HTTP proxy to rule out interference from the system proxy toggle.

curl -I --proxy http://127.0.0.1:7890 https://example.com

Check the response, connection logs, and matched rule together. This test only verifies the current HTTP proxy path; it doesn't test UDP or prove that every app is being intercepted. If an old process is occupying the port, exit the old core first rather than running multiple cores on different ports without a clear reason.

Step 3: Restore enhanced features one at a time

1. Restore the rule sets and check each RULE-SET reference and download status.
2. Restore the DNS config and verify the actual resolution path for enhanced-mode, nameserver, and nameserver-policy.
3. Enable sniffing if needed, then compare destination domains with matched rules.
4. Enable TUN last and check the interface, routes, DNS, and UDP.

Keep a copy of the config that the old core can read. A rollback means restoring the matching rule-set formats and fields as well as the binary; don't let a config generated by the new core overwrite your only backup of the old one.

How to choose and reference materials

If your existing config uses only basic protocols and standard rules, focus on maintenance status, platform support, and client integration when migrating. For VLESS, Hysteria2, TUIC, mrs, or fine-grained sniffing options, choose a client that explicitly uses mihomo and provides the features you need. A button in the client interface doesn't guarantee that the selected core can perform the action.

This comparison focuses on capability boundaries; behavior in a particular release isn't a permanent guarantee. For platform limitations, default field values, and new protocol parameters, consult the documentation for your installed version. The resources below help verify project details, field definitions, and release changes.

• mihomo project repository: Project overview, source code, and issue tracker.
• mihomo rule provider documentation: Provider types, behavior, and file formats.
• mihomo TUN configuration documentation: Stacks, routing, and platform-specific options.
• mihomo domain sniffing documentation: Supported protocols and destination override settings.
• mihomo release history: Check fixes and behavior changes against your local version.

For the full config structure, see the site's Advanced Configuration; for first-time installation and subscription import, follow the Getting Started guide. Validate a migration against four checks: the config parses, nodes connect, rules match correctly, and traffic interception works as intended.