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

The short version: Core configs are similar, but newer features don’t work in reverse

If your config uses common proxies, a select group, and domain-based routing rules, moving to mihomo usually takes only a few adjustments. But being able to parse YAML doesn’t mean every field works the same way. Validate new protocols, rule data files, DNS hijacking, and TUN routing separately rather than replacing the config you rely on day to day.

First, distinguish between two things people call the “original Clash”: the original open-source core and the separately released Clash Premium core. They have different feature sets. In particular, support for rule providers or TUN in an older client doesn’t mean the original open-source core supports those features. mihomo is a continuation of Clash Meta, not just a new name displayed for the old core.

• Moving an older config to mihomo: The basic syntax has a lot in common, but check for settings that have been removed, renamed, or overridden by the client.
• Moving a mihomo config to an older core: Don’t assume extended features such as VLESS, Hysteria2, or GEOSITE will work.
• Switching desktop clients: This can also change service permissions, config directories, overrides, and system proxy controls. Comparing cores alone isn’t enough.

Protocol support: Check node types and transport settings together

Common outbound types in the original open-source Clash include Shadowsocks, VMess, Trojan, SOCKS5, and HTTP. mihomo expands protocol and transport support with options such as VLESS, Hysteria2, and TUIC, along with related REALITY settings. Available options depend on the mihomo build you have installed; don’t apply fields from current documentation to a much older Clash Meta binary without checking compatibility.

The same protocol name doesn’t mean you can copy a node config unchanged

For example, a WebSocket node requires checking network, the path, headers, and TLS server name—not just type. REALITY nodes have their own parameters, including a public key and short ID. Copying only the server address and port is usually not enough to connect. If a subscription converter doesn’t recognize these fields, it may discard them, leaving you with a node that appears in the list but won’t connect.

• First make sure the subscription provides a config format mihomo can read, not JSON intended for another client.
• Check the node’s type, then verify all parameters required for that type.
• For apps that need UDP, also check that the node, policy, and network allow UDP. Being able to load a webpage doesn’t prove UDP works.

More protocols don’t automatically mean lower latency. Server routes, congestion, packet loss, and the network between your client and the server all affect performance. Choose a core based on the features you need, and compare nodes on the same network, against the same destination, using the same test method.

Rule set differences: rule-providers are not GEOSITE

rule-providers declares external rule sources, and RULE-SET references them in the rules list. GEOSITE matches domains against categories in a domain-classification database. Both can reduce the number of rules in your main config, but they use different data sources, file formats, and update methods.

Validate references with a local rule file first

The following is a partial mihomo config example. Merge it into an existing config; it isn’t a complete config you can use on its own. It reads classical rules from rules/local-direct.yaml in the config directory and sends matching connections to DIRECT:

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

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

Here’s the corresponding rules/local-direct.yaml file. The example.com entry demonstrates domain suffix matching. Replace it with a domain that you actually need to connect to directly:

payload:
  - DOMAIN-SUFFIX,example.com

With behavior: classical, each entry includes a rule type such as DOMAIN-SUFFIX. If you switch to behavior: domain, the file must use the corresponding domain-rule format. Changing the declaration alone isn’t enough. Binary rule formats also have their own support requirements; changing a file extension won’t make it compatible with a different parser.

GEOSITE requires checking both the database and the category

For example, GEOSITE,cn,DIRECT depends on the domain-classification data containing a cn category. It’s different from GEOIP,CN,DIRECT: the former matches domain categories, while the latter uses IP geolocation data. A site hosted on an overseas CDN can match differently under these two rules. That reflects their different matching criteria, not necessarily a core problem.

Remote rules or geolocation data may need to be downloaded the first time they load. If those resources must be fetched through a proxy that hasn’t started yet, startup can get stuck in a dependency loop. For the initial migration, keep a minimal rule set, prepare the required data locally, and then restore remote updates one at a time.

TUN differences: Core support is only the first step to routing traffic

System proxy settings usually work only for apps that actively use them. TUN routes traffic through a virtual network interface. mihomo supporting TUN doesn’t guarantee that enabling it will route every app through the proxy. OS permissions, virtual interface creation, route installation, and conflicts with other VPNs can all prevent traffic from being captured.

Older Clash Premium versions also support TUN, but that doesn’t make their entire TUN config a standard mihomo configuration. When migrating, check fields such as stack, auto-route, auto-detect-interface, and dns-hijack, and account for support on your current OS.

Verify TUN with evidence from three layers

1. Interface: Check the startup logs to confirm the virtual interface was created successfully, with no permission or device-in-use errors.
2. Routing: Confirm that target traffic reaches the virtual interface. Multiple network adapters, other VPNs, and manually configured static routes can all change the traffic path.
3. Connection: Start a new connection from the target app, then check the connections panel for the destination, matched rule, and final policy.

For example, any:53 in dns-hijack is a DNS interception setting, not a switch that “captures all encrypted DNS.” HTTPS DNS requests made by an app use HTTPS connections and can’t simply be treated as regular queries on port 53. Check IPv6 traffic separately, too; IPv4 results alone don’t prove that all traffic is being captured.

On Linux, you may need root or appropriate network-management permissions. Desktop clients on Windows and macOS may handle permissions through a background service. The service installation steps vary by client, so follow its documentation. Avoid stacking multiple virtual adapters and routing tools while troubleshooting.

DNS and config compatibility: Keep the current resolution path before trying enhanced modes

mihomo retains familiar Clash config concepts such as dns, nameserver, and fallback, and also supports more granular resolution policies. How these fields are combined determines where queries go. Changing every DNS address to the same service doesn’t guarantee better compatibility; it can obscure the difference between resolving node hostnames and resolving domain names used by apps.

Don’t switch between fake-ip and redir-host at the same time as the core

fake-ip assigns virtual addresses to domains, commonly from 198.18.0.0/16. These addresses link domains to subsequent connections; they aren’t the actual addresses of remote servers. redir-host usually returns the real DNS result. Either mode can affect LAN devices, apps that depend on real IPs, and existing DNS caches.

If your old setup used redir-host, keep it for the first migration test. After confirming that nodes and rules work, test fake-ip separately. For an app that misbehaves, add an appropriate exclusion based on the symptoms rather than disabling TUN, changing DNS, and switching nodes all at once.

• Node hostname won’t resolve: Check the resolution path used before the node connection is established, and review related settings such as proxy-server-nameserver if needed.
• Domain rules appear to have no effect: Check whether the connection still has its domain information and whether DNS is following the expected path.
• Changes don’t seem to stick: Check whether the client’s merge rules, overrides, or subscription updates are rewriting the DNS section.

Don’t assume fallback means the backup DNS is used only when the primary DNS fails completely. It works together with filtering conditions to determine which result is selected. When troubleshooting a migration, check the active config and logs before changing this layer.

Migration steps: From syntax checks to real connection tests

Keep the old core, config, and client overrides, and create a separate test directory. The example below uses a standalone binary; mihomo-test is just the directory name for this test. File paths and the working directory in the commands are relative to your current terminal location:

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

Use -t to test the config, -d to set the working directory, and -f to specify the config file. Passing the syntax check only means the config test found no blocking errors. It doesn’t prove that servers are reachable, the system proxy is set up, or TUN routes are active.

First, test only the local proxy port

Use the basic settings below for your test config. 7890 is the mixed proxy port explicitly set here; it isn’t a fixed port used by every client. Merge these fields into a config with valid nodes and policy groups, then start the test:

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info

If the old client also uses 7890, stop its core first or choose an unused port for the test config. Closing the old client window may not be enough; its background service could still be running. Don’t enable TUN or configure LAN sharing at this stage.

1. Parse the config: Fix unknown node types, invalid rules, missing policy groups, and incorrect rule file paths.
2. Start the core: Confirm that the port is listening and there are no startup errors such as “address already in use.”
3. Test with an explicit proxy: Run the command below in a terminal and check whether the request succeeds and appears in the connections panel.
4. Restore routing rules: Add rule providers and geolocation rules in batches, checking which rules actually match.
5. Route system traffic last: Test the system proxy first, then enable TUN separately to avoid introducing multiple variables at once.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

This command tests a request through the local proxy. If the destination matches DIRECT, the request may still succeed by connecting directly, so check the policy chain in the connections panel. A successful test doesn’t mean every app is using a remote node or that download speeds have reached the line’s maximum.

Common migration issues and how to choose a core

If you need VLESS, Hysteria2, TUIC, GEOSITE, or more complete modern routing features, mihomo is the better option to evaluate. For basic proxy use, compare desktop clients by maintenance status, platform integration, and config management instead of deciding from a core feature list alone.

Clash Review Hub provides client selection and config guides; it isn’t a client developer. For migration, rely on the documentation, startup logs, and connection records for the core you actually installed. Treat “config loads,” “requests succeed,” “rules match correctly,” and “system traffic is fully routed” as four separate acceptance checks. This makes troubleshooting clearer than replacing every setting at once.

For the basics, see the quick glossary. For checking rules and proxy modes, see the rule reference in the user guide.