mihomo vs. Original Clash: Protocol Support, DNS Configuration, and Migration Guide

Start by separating Clash, Clash Meta, mihomo, and the client

Original Clash usually refers to the Clash core released by the Dreamacro project. It reads YAML configuration, opens HTTP, SOCKS, or mixed listening ports, and decides where connections go based on proxy groups and rules. Clash Meta was a fork that extended this configuration model and later adopted mihomo as its project name. During migration, “Clash Meta configuration” and “mihomo configuration” can be understood as names for different stages of the same technical line, but that does not mean every version is fully compatible.

Graphical clients such as Clash Verge Rev and FlClash handle configuration imports, system-proxy toggles, log display, and kernel management; mihomo is the core that executes protocols, DNS, rules, and TUN interception. Subscription services provide nodes and policy configuration. These three layers are the interface, execution layer, and configuration source respectively, so identify the source layer before troubleshooting an error.

Confirm the active kernel from the command line

For a command-line deployment, start by querying the version. Build output can include different extra details, but it should show the mihomo name, version, target operating system, and processor architecture.

mihomo -v

For example, a machine might show Mihomo Meta v1.19.3 linux amd64. Here, v1.19.3 only illustrates how to read the version; it is not a universal minimum requirement for every feature. Protocols, configuration fields, and defaults change between releases, so use the current binary's version information and release notes when migrating.

If the machine still uses an older executable named clash, also run clash -v. Renaming a new file to the old name does not upgrade the old kernel to mihomo; rely on the program output and the actual process path, not the filename.

What actually changes in protocol and rule support

Original Clash supports common proxy types such as Shadowsocks, VMess, Trojan, HTTP, and SOCKS5, along with DIRECT, REJECT, proxy groups, rule modes, and basic DNS features. mihomo retains these configuration structures while adding or extending support for VLESS, Reality, Hysteria2, TUIC, WireGuard, and more. Whether a specific protocol works still depends on the kernel version, how the subscription was generated, and whether the server parameters are complete.

Matching protocol names do not mean parameters can be reused unchanged

The easiest migration mistake is assuming that a node must work because it appears in the subscription. If the client parses the YAML successfully, that only means the basic configuration format is readable; it does not confirm that the handshake parameters are correct. For example, VLESS Reality commonly requires the server name, public key, short ID, client fingerprint, and flow-control parameters. Hysteria2 requires checking the server address, authentication details, TLS server name, and certificate verification settings. A node with missing fields may still appear in the list, while the connection fails during the handshake.

• Choose one known-good node first instead of testing indirectly through an automatic latency-test group.
• Temporarily set the log level to debug, complete one target connection, and inspect the handshake error immediately afterward.
• Distinguish timeouts, DNS resolution failures, TLS name mismatches, and authentication failures; each points to a different fix.
• A subscription converter may rewrite fields, so compare the original subscription with the configuration saved by the client when necessary.

Rules still run in order

mihomo does not change the core rule principle: rules are evaluated from top to bottom, and the first match determines the route. If all traffic goes through the proxy after migration or a specific domain no longer connects directly, check rule order first instead of repeatedly switching nodes.

mode: rule
rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN,blocked.example,REJECT
  - MATCH,PROXY

Here, PROXY must be a policy group defined in the configuration; it is not a built-in kernel exit. no-resolve means that this IP rule does not actively resolve a domain to an IP address for matching; it does not disable all DNS. If a legacy configuration lacks a policy group named PROXY, the configuration test should report the reference error before connection testing begins.

Why DNS is a high-risk part of migration

After moving an old Clash configuration to mihomo, proxy nodes may connect successfully while websites load slowly, LAN hostnames stop working, DNS results for mainland China and outside China are unexpected, or DNS fails completely when TUN is enabled. These issues are usually not protocol incompatibilities; they result from an incorrect path between system DNS, mihomo DNS, proxy-node hostname resolution, and fake-ip mappings.

Understanding fake-ip and redir-host

enhanced-mode: fake-ip first returns a reserved address to the application, then stores the domain mapping in the kernel and restores the real destination when intercepting the connection. A common address pool is 198.18.0.1/16. This works well when rules need to operate by domain, but LAN discovery, printers, some games, and applications that validate certificates or addresses themselves may need to be added to the filter list.

redir-host is closer to resolving the real address first and then processing the connection. It reduces fake-ip's impact on LAN applications, but domain-rule matching, resolution latency, and caching behavior differ. During migration, do not overwrite an existing configuration simply because a template uses fake-ip; first confirm the current interception method and application requirements.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

The example limits DNS listening to 127.0.0.1:1053 to illustrate the relationship between the port and listening address. If TUN DNS hijacking intercepts requests, the configuration must also work with the TUN section generated by the client. Port 1053 is not mandatory and does not automatically change the operating system's DNS.

Proxy-node hostnames require separate consideration

If the proxy server is specified by hostname, the kernel must resolve that hostname before it can establish the proxy connection. If that lookup is itself routed through a proxy that has not started yet, a startup loop can occur. mihomo can use proxy-server-nameserver to specify resolvers for proxy-node hostnames and nameserver-policy to choose a resolution path for specific domains.

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - 223.5.5.5
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query

This configuration only illustrates the relationship between fields; it does not include complete proxy, policy-group, or rule definitions. When using encrypted DNS, also make sure its hostname can be resolved initially. If DNS timeouts persist after migration, first verify the basic path with a regular IP-based DNS server, then restore DoH, policy-based resolution, and rule-following one at a time instead of changing four or five variables together.

TUN migration: check permissions, routes, and interfaces

The system proxy affects only applications that actively read the system proxy settings. Terminal commands, games, virtual machines, and some updaters may bypass the system proxy, so many users enable TUN when moving to mihomo. TUN creates a virtual network interface and changes routes, providing broader coverage but depending more heavily on operating-system permissions and routing configuration.

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

The available stack values and behavior should be checked against the current mihomo version; common choices include system, gvisor, and mixed. During migration, keep the client's default first and address compatibility issues based on the logs. Copying a router template directly to a desktop system may also bring along interface names, routing tables, or DNS-hijacking behavior and cause a network outage.

Narrow down TUN issues in order

1. Disable TUN and enable only the mixed port to confirm that the proxy node itself works.
2. Check the listening port. A common example is mixed-port: 7890; temporarily set the browser's HTTP and SOCKS5 proxy to 127.0.0.1:7890.
3. Enable TUN and confirm that the client has permission to create the virtual interface and modify routes.
4. Check whether a VPN, virtual-machine network, game accelerator, or another transparent proxy is running at the same time.
5. Test an IP address and a domain separately. If the IP is reachable but the domain fails, return to the DNS configuration first.
6. Access a LAN device and confirm that private-address rules appear before the catch-all rule.

On Windows, the client usually handles permission requests; on macOS, VPN configuration or network-extension authorization may be involved; Linux service deployments require checking the service user, network capabilities, and permission to modify routes. Clients package these steps differently, so a menu toggle in one client should not be treated as a universal mihomo kernel configuration field.

Reproducible steps for migrating a legacy configuration to mihomo

Step 1: Preserve the old files and runtime details

Copy the current config.yaml, rule sets, local overrides, and client configuration directory. Record the old kernel version, system-proxy port, control port, TUN status, and the nodes that work normally. Do not put a subscription URL in public logs or screenshots. If the client supports multiple configurations, identify which one is active so you do not edit an unselected file.

Step 2: Run a static configuration test first

mihomo provides a configuration-test option that can check YAML syntax, policy-group references, and some field errors before the service starts. Assuming the configuration file is in the current directory, run:

mihomo -t -f config.yaml

A passing test only means the kernel can load the configuration. It does not mean every node can connect or that remote rule sets will download successfully. If the test fails, fix the first error; later errors may simply cascade from an earlier indentation or field-structure problem.

Step 3: Verify listening ports with a minimal configuration

During migration, temporarily keep one proxy, one policy group, and a small number of rules. Set the mixed port to 7890 and restrict the control interface to 127.0.0.1:9090. If an external control interface is enabled, set an access key as well and confirm that the address, port, and key entered in the client match.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090
secret: "change-this-local-secret"

The key shown here is an example and must be replaced in a real configuration. The control port is for the management interface to read status and switch policies; it does not carry web proxy traffic. Pointing the browser proxy at 9090 will not work.

Step 4: Restore rule sets, DNS, and TUN one at a time

Restore components in this order: node connection → policy groups → local rules → remote rule sets → DNS → TUN. After adding each layer, test a domain, an IP address, a LAN destination, and the logs. This limits rollback to one step when something breaks.

• Rule providers: check behavior, file format, update interval, and reference names.
• Geodata: confirm that the GEOIP and GEOSITE data files can be read by the current kernel.
• Policy groups: check that rule targets exactly match the names in proxy-groups.
• Subscription overrides: confirm whether updating the subscription overwrites local DNS or TUN settings.
• LAN access: enable allow-lan only when other devices need to connect, and configure the listening address and firewall.

Common migration symptoms and what to check

When testing from a terminal, specify the proxy explicitly so that “the terminal is not reading the system proxy” is not mistaken for a kernel failure. If the mixed port is 7890, a SOCKS5-capable tool can connect to socks5h://127.0.0.1:7890; resolving the domain through the proxy is useful for verifying mihomo's domain-rule path.

Acceptance criteria after migration

Migration is not complete just because the client's tray icon changes color. At minimum, verify that the configuration test passes; the selected node connects; DIRECT and proxy rules match as intended; reject rules actually block traffic; DNS does not time out continuously; system-proxy and TUN coverage match expectations; and local overrides remain after a subscription update.

1. Record the current mihomo and client versions for future upgrade comparisons.
2. In the logs, confirm the matched rule for one direct request, one proxied request, and one rejected request.
3. Disable the system proxy and check that TUN still intercepts traffic as expected; disable TUN and check that the mixed port still works independently.
4. Update a subscription once and reload the configuration, confirming that policy-group names, DNS, and rule providers were not overwritten.
5. Restart the client or system and confirm that the kernel, configuration, and permission state recover correctly.