mihomo vs. the Original Clash Core: Protocols, Rules, and Config Compatibility

The short version: most older configs can be migrated, but newer features aren't backward-compatible

If your subscription still uses common Shadowsocks, VMess, or Trojan nodes and rules such as DOMAIN-SUFFIX, IP-CIDR, and MATCH, you usually won't need to rewrite the entire YAML file to migrate to mihomo. Check node-specific options, rule-set formats, DNS settings, and whether your client overwrites manually edited fields.

mihomo is the name now used by the successor project to Clash Meta. It retains Clash's configuration system while expanding protocol support and traffic handling. It's a core, not a specific Clash client with a graphical interface. The client manages subscriptions, system proxy settings, and config merging; the core establishes connections, applies rules, and handles DNS. Changing the interface alone doesn't necessarily change the core that's actually running.

The original project is no longer maintained. If you need newer protocols, actively updated rule features, or support for newer systems, consider a maintained core. But a newer core doesn't make every node faster: connection performance still depends on route quality, server configuration, packet loss, and the outbound policy actually selected.

Protocol support: check the node type, then its handshake parameters

“VLESS supported” doesn't mean every VLESS link will work as-is

The node's type is only the starting point. VLESS with Reality may also require servername, client-fingerprint, and a public key and short ID under reality-opts. With Vision, check flow as well. These parameters must match the server; don't copy them from another node and assume they'll work.

• “Unsupported proxy type” error: Check that the running core is actually mihomo; the client name or subscription filename alone doesn't tell you.
• Config loads, but the TLS handshake fails: Check the system clock, SNI, certificate hostname, and Reality settings. Don't start by disabling certificate verification.
• Hysteria2 or TUIC times out: Make sure UDP is allowed by your network and the server. Opening a website through another TCP node doesn't confirm that UDP is working.

Subscription converters have limits: they can change config fields, but they can't turn a Hysteria2 server into a VMess server supported by the original Clash core. If your client doesn't recognize a newer protocol, switch to a compatible core or use another node explicitly supported by your provider.

Rule support: basic syntax remains, but check rule-set formats

Clash applies rules in list order, from top to bottom, and selects an outbound policy at the first match. When migrating, keep your existing rule order to start with; don't change dozens of rules at once. Make sure every referenced policy group exists, then use MATCH to catch connections that didn't match anything above.

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,Proxy

Here, Proxy must be the name of a policy group or outbound already defined in your config; example.com is a reserved example domain used to illustrate the syntax. no-resolve means this IP rule won't trigger a DNS lookup. It doesn't disable DNS for the entire core. If the connection already has a destination IP, it can still match against that IP.

rule-providers and RULE-SET serve different purposes

rule-providers defines where rules are read from and how they're interpreted; RULE-SET references them in the main rule list. mihomo supports rule providers and offers more rule-combination and matching options. Premium users may already be familiar with some of these features.

rule-providers:
  private-net:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/private.yaml

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

The corresponding ./rules/private.yaml file can contain the following. Relative paths are usually resolved from the core's working directory, not necessarily the client application's directory. If the file isn't found, check the working directory in the startup log.

payload:
  - IP-CIDR,10.0.0.0/8,no-resolve
  - IP-CIDR,172.16.0.0/12,no-resolve
  - IP-CIDR,192.168.0.0/16,no-resolve

• behavior: classical accepts entries that include a rule type, such as the IP-CIDR entry above.
• behavior: domain and behavior: ipcidr each require their own content format. Don't put full-line classical rules in these files.
• mihomo's binary MRS rule sets are for domain or ipcidr behavior. Renaming an arbitrary classical YAML file to an MRS extension won't convert it to MRS.
• Validate logical rules, process matching, and other extensions individually. Process detection also depends on the operating system, permissions, and how traffic is intercepted.

If many sites fall through to the default policy after migration, first check that rule sets loaded, then review rule order. A rule-set URL being downloadable doesn't mean its contents match the configured behavior.

DNS differences: keep basic settings, test resolution and routing separately

The original Clash already included a DNS module and basic features such as Fake-IP. mihomo builds on these with controls such as choosing resolvers by domain and resolving proxy-node hostnames. Getting the right DNS response and routing a connection through the right policy are separate tasks: DNS determines the destination address, while routing determines the outbound path.

Which existing settings can you keep?

Common fields such as dns.enable, listen, enhanced-mode, fake-ip-range, and nameserver are a good starting point for migration. The DNS snippet below is for illustration only; it doesn't include complete nodes or policy groups and won't change your system DNS settings automatically.

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
    - 119.29.29.29

1053 is the local DNS listening port in this example. Standard system DNS settings typically accept only a server address, not a port. To intercept system DNS requests, configure forwarding separately or enable DNS hijacking in TUN where applicable. 198.18.0.1/16 is used for Fake-IP mapping; it's not a real public IP address for a remote website.

Don't enable every new feature at once

• nameserver-policy: Choose resolvers for specific domains or domain groups, useful for handling internal and public domains separately.
• proxy-server-nameserver: Set the resolution path for proxy-node hostnames so resolving a node's address doesn't depend on a proxy connection that hasn't been established yet.
• fake-ip-filter: Exclude domains with known compatibility issues from Fake-IP. Don't disable the entire routing setup just to accommodate one local network service.

During testing, check the client's DNS logs, the domain shown in connection details, and the final policy separately. A browser's secure DNS feature may use a separate resolution path. Changing the core's DNS settings alone doesn't prove that every browser query goes through it.

TUN and traffic sniffing: traffic capture is separate from rule mode

System proxy settings mainly serve apps that honor them. TUN captures traffic through a virtual network interface, making it useful for apps that don't use the system proxy. TUN determines how traffic enters the core; rule mode determines which outbound is used after it arrives. They're not mutually exclusive.

Don't conflate the original open-source core with Premium's TUN support. After migrating to mihomo, copying a tun block doesn't guarantee that TUN is working. The client may require a service to be installed, administrator privileges, or a setting generated and overwritten by its interface.

1. Test the subscription, nodes, and rules through the system proxy first. Don't add TUN before the config passes validation.
2. For comparison, disable other VPNs and virtual network adapters to avoid competing default routes.
3. After enabling TUN, check the logs to confirm that the virtual interface and routes were created successfully, with no permission errors.
4. Test access to local printers, NAS devices, and corporate network addresses. Add explicit bypass rules or route exclusions if needed.

mihomo can sniff host information from some HTTP, TLS, and QUIC traffic to help match domain rules. It doesn't decrypt HTTPS content or identify every connection. Features such as Encrypted ClientHello can limit what information is visible. Enable sniffing to address specific routing needs; don't treat it as a universal fix for DNS problems.

Migrating an older subscription: handle each config source separately

Migration steps

1. Back up the original config: Save the raw subscription and the current config generated by the client separately. They may differ, so don't rely on the subscription editor alone when troubleshooting.
2. Check which core is running: Find its name and version in the client's core information or startup log. If you're using a standalone binary, run mihomo -v to check the version.
3. Test the config first: From the config directory, run mihomo -t -f ./config.yaml. On Windows, use .\mihomo.exe -t -f .\config.yaml with the standalone executable.
4. Test one connection path: Select a known-working node, enable the system proxy, and visit a test page in rule mode.
5. Re-enable features one at a time: Add rule sets, DNS policies, and then TUN, checking the logs after each change.
6. Update the subscription once at the end: Make sure custom rules remain intact, then set up automatic updates and launch at startup.

A successful config test only confirms that the core can read the config. It doesn't confirm that subscription nodes are online, rule sets downloaded successfully, or the system proxy is enabled. Clients with a graphical interface may also merge configs before startup, so use the same file for command-line testing as the one the client actually runs whenever possible.

After migration: check ports, rules, and DNS separately

If the running config sets mixed-port to 7890, start by testing with an explicit proxy. This removes system proxy settings as a variable. Replace the port with the value shown in your client.

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

In Windows PowerShell, use curl.exe to avoid parameter parsing issues caused by a command alias with the same name in some environments. This test checks only this HTTP proxy request; it doesn't confirm that UDP, TUN, or other apps are working.

• Connection refused: First check whether the core is running, whether the local port is correct, and whether another process is using it.
• Proxy connects, but the request times out: Check the selected node, node hostname resolution, and server availability.
• The page loads, but traffic exits through the wrong route: In connection details, check the matched rule, the policy group's current selection, and whether the client is actually in Global mode.
• Only one app fails: Check whether it honors system proxy settings. If it doesn't, consider TUN instead of repeatedly changing subscriptions.

The choice is straightforward: for VLESS Reality, Hysteria2, TUIC, or finer-grained rule and DNS controls, use a mihomo client that supports those features. For a basic subscription, start by reusing a stable config. Checking core compatibility, config merging, and network connectivity separately makes issues easier to pinpoint than replacing every setting at once.

For details on individual fields, see the Clash Configuration Guide. For port conflicts, system proxy issues, or permission errors, work through the FAQ.