mihomo vs. Original Clash: Core Features and Configuration Compatibility

Start by separating the core, client, and configuration layers

When comparing mihomo with original Clash, the most common mistake is treating the core, graphical client, and subscription configuration as one product. Original Clash generally refers to the open-source core maintained by Dreamacro. It listens on local ports, establishes proxy connections, applies rules, handles DNS, and exposes runtime status to graphical interfaces through an external control API. After the original project stopped receiving ongoing maintenance, its core could still run existing configurations, but it no longer kept pace with new protocols, rule capabilities, or platform networking changes.

mihomo is a core project descended from Clash.Meta. It retains Clash’s configuration model, proxy groups, and rule-matching behavior while expanding support for protocols, DNS, TUN, rule sets, and traffic controls. The name change does not mean the configuration system was redesigned: many clients, configuration directories, and documents that still use the Clash.Meta label have already switched to mihomo under the hood. Check the core name and version in the client settings rather than relying only on the application title.

A graphical client is the management layer around the core. It typically downloads subscriptions, switches configurations, edits proxy groups, controls the system proxy, and displays connection logs. One client may support multiple cores, and the same configuration may be read by several clients. Therefore, saying that “a client supports a field” has two meanings: whether its bundled core can parse the field, and whether the interface can display and edit it correctly. It is common for the core to execute a setting normally even when the interface offers no corresponding control.

Protocol support: mihomo covers more ground, but configuration and network limits still apply

Original Clash supports common proxy types including Shadowsocks, VMess, Trojan, Snell, HTTP, and SOCKS, covering the basic needs of traditional Clash configurations. Building on that foundation, mihomo adds and maintains support for VLESS, Reality-based transports, Hysteria, Hysteria2, TUIC, WireGuard, and other capabilities while adapting to protocol parameter changes. The exact range still depends on the installed mihomo version; an older core bundled with a client may not recognize newer fields.

Supporting a protocol does not guarantee that an imported node will connect. A VLESS node may also depend on TLS, Reality, WebSocket, gRPC, or other transport parameters. Hysteria2 and TUIC primarily use UDP and may time out during the handshake on networks that restrict UDP. WireGuard configurations also involve addresses, private and public keys, routes, and MTU. If a subscription converter drops fields, the core cannot recover the missing parameters even when it supports the protocol.

When migrating from original Clash to mihomo, existing Shadowsocks, VMess, and Trojan nodes are usually the easiest to keep compatible. The reverse migration is different: configurations containing VLESS, Hysteria2, TUIC, or mihomo-specific options may produce an unknown proxy type error in the original core, or stop loading when they reach an unsupported field. Configuration compatibility is better understood as “mihomo offers strong compatibility with traditional Clash syntax,” not as full two-way equivalence between the cores.

What to check before switching protocols

• The actual core version bundled with the client and whether the core can be updated independently.
• Whether the node’s protocol, transport layer, TLS, server name, certificate verification, and other fields are complete.
• Whether the current network allows UDP, and whether the router, firewall, or corporate network restricts the relevant traffic.
• Whether subscription updates pass through a conversion service, and whether that conversion preserves parameters for newer protocols.
• Whether same-named proxy groups still reference valid nodes, so that existing nodes are not left unused by every group.

Rules and proxy groups: the basic model is shared, but extensions differ

The core traffic-routing model is similar in both: connections are matched against rules in order, then sent to a proxy node or proxy group; unmatched connections are usually handled by a final MATCH rule. Common rules such as DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD, IP-CIDR, GEOIP, and PROCESS-NAME are easy to migrate. Proxy groups including select, url-test, fallback, and load-balance also retain the organization familiar to Clash users.

mihomo expands rule expressions with more rule types, logical combinations, inbound conditions, network types, and rule-set capabilities. AND, OR, and NOT rules are useful for compound conditions such as “a specific domain from a particular inbound,” but parentheses, commas, and nested rule structures must follow the syntax supported by the current core. Complex rules do not automatically improve accuracy; the more conditions you add, the more important it becomes to review connection logs and rule-trace data when investigating matches.

Rule sets also come in different data formats. Traditional domain lists, IP CIDR collections, classic rule text, and binary rule sets differ in behavior, format, and loading method. If a rule-provider is declared as domain but contains full comma-separated rules, the update may succeed while matching still fails. mihomo can also classify traffic with GEOSITE and GEOIP data, but category names depend on the geographic data files in use, and different sources do not necessarily contain the same labels.

mode: rule

proxy-groups:
  - name: Manual Selection
    type: select
    proxies:
      - DIRECT

rule-providers:
  local-direct:
    type: file
    behavior: domain
    format: text
    path: ./rules/direct.txt

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

The example only shows how a rule set and a proxy group reference each other. When migrating a real configuration, preserve the existing proxy nodes, proxy providers, and complete proxy groups; do not overwrite an active file with this fragment alone. If the configuration comes from a subscription, add custom rules through the client’s override or merge feature whenever possible, so the changes are not lost at the next subscription update.

DNS and TUN: more complete capabilities, with greater dependence on the system environment

The DNS module in Clash-family cores does more than resolve domains to IP addresses. It also affects rule matching, proxy-server address resolution, and protection against DNS leaks around the system resolver. Original Clash already provides fake-ip, redir-host, nameserver, fallback, and fallback-filter mechanisms. mihomo extends these with nameserver-policy, proxy-server-nameserver, direct-nameserver, and fake-ip-filter, allowing proxy-node domains, direct domains, and ordinary queries to use different resolution paths.

These fields have distinct responsibilities. nameserver handles regular queries; proxy-server-nameserver can resolve the proxy server’s own domain and prevent a dependency loop before the proxy is established; nameserver-policy assigns resolvers by domain; and fake-ip-filter excludes domains that should not receive a virtual address. When enabling an option such as respect-rules that uses rule selection to choose a resolution path, make sure proxy-node domains have an independent resolver. Otherwise, DNS may need the proxy while the proxy connection is waiting for the DNS result.

fake-ip mode assigns virtual addresses to domains, then restores the domain name when the core takes over the connection, which generally provides more consistent rule matching. Local-network discovery, some games, printing services, and applications that require real addresses may need to be added to the filter list. redir-host returns real resolution results and behaves more like traditional DNS, but complex routing and polluted network environments require more careful upstream resolver planning. During migration, do not copy only the enhanced-mode line; also review the listen address, IPv6, filter scope, and upstream protocols.

TUN mode takes over traffic that does not follow system proxy settings, including some command-line tools, games, and applications with custom network stacks. mihomo provides comprehensive TUN routing, DNS hijacking, automatic routing, and interface detection, but availability still depends on operating-system permissions, virtual network adapter drivers, firewalls, and other networking software. Network stacks such as system and gVisor differ in performance, compatibility, and platform support. Start with the client’s recommended default, then adjust it for a specific issue.

Configuration compatibility is more than whether YAML loads

A configuration parsed successfully by mihomo only means that its field syntax passed validation. It does not mean that nodes are usable, rules match correctly, or the external control interface is fully compatible. Migration should be assessed across at least four layers: YAML structure, core fields, runtime resources, and client control. Indentation errors, duplicate keys, and incorrect data types belong to the YAML layer. Unknown proxy types and invalid proxy-group parameters belong to the core layer. Missing rule files and unavailable geographic databases belong to the resource layer. The external control address, authentication secret, and API differences affect the graphical client.

mihomo can generally read traditional proxies, proxy-groups, rules, proxy-providers, and rule-providers structures, while retaining common fields such as mixed-port, socks-port, redir-port, allow-lan, mode, and log-level. However, some older configurations depend on specific Clash Premium behavior, while others include client-specific overrides. When field names look identical, also verify the value format and the documentation for the current version; a file extension alone cannot determine compatibility.

The external control interface generally continues to follow the Clash API model, so many dashboards can still display traffic, connections, proxy groups, and logs. If a dashboard has not adapted to mihomo’s newer proxy types or configuration fields, it may show only basic information or even remove unknown content when saving. Keep important extensions in separate configuration or override files, and confirm that the client’s save operation will not rewrite the original subscription.

Common incompatibilities and where to look

• Immediate error on startup: Start with the reported line number, then check YAML indentation, field types, and whether the current core supports the relevant proxy type.
• Configuration loads, but every node times out: Check node parameters, proxy-server DNS, system time, UDP availability, and whether subscription fields are complete.
• Proxy group is empty: Check proxies, use, filter, and exclude-filter, and confirm that the provider name and filter expression match the nodes.
• Rules do not match as expected: Check rule order, rule-set behavior, resolution results, and whether the connection is actually being handled by TUN or the system proxy.
• The interface connects but cannot edit: The client may not yet provide a form for that field. Maintain extended fields through a supported override method.

Migration sequence from original Clash to mihomo

The key to a stable migration is limiting the number of variables. Do not replace the core while also rewriting DNS, replacing every rule set, and enabling TUN; otherwise, it becomes difficult to identify the source of a failure. First make sure the original configuration parses and establishes a basic connection in the new core, then enable mihomo extensions one at a time.

1. Preserve the current configuration and client settings. Record listen ports, system proxy status, current proxy-group selection, DNS mode, and the external control address. Save the subscription URL and local overrides separately.
2. Confirm where the configuration comes from. Distinguish local YAML, remote subscriptions, proxy providers, and client-generated configurations. Direct edits to cached files are usually overwritten when the subscription refreshes.
3. Validate the syntax with mihomo. In a command-line environment, run mihomo -t -f config.yaml to check the configuration. In a graphical client, review the core log for the exact file and line number.
4. Test the basic proxy first. Keep the existing rule mode, select a known-working node, and confirm that web access, DNS queries, and proxy-group switching work normally. Do not add nodes using new protocols at this stage.
5. Verify rules and providers. Check that remote rule sets download successfully, proxy groups contain members, and a final MATCH rule exists. Use connection logs to confirm which rule actually matches frequently used domains.
6. Enable DNS extensions separately. Configure proxy-server resolution, domain policies, and fake-IP filtering as needed. Change only one group of fields at a time and watch for resolution timeouts or dependency loops.
7. Test TUN last. Close other proxy clients, confirm virtual adapter permissions and route recovery, then test applications that do not use the system proxy. If the network goes down, exit TUN first instead of repeatedly changing node parameters.

mihomo -t -f config.yaml

After syntax validation passes, perform runtime checks as well. Review the core log, proxy-group selection, DNS queries, connection details, and system routes in that order. If the old configuration contains many custom fields, first create a minimal copy with one local port, one node, one proxy group, and a final rule. Once the minimal configuration connects, restore rule providers, DNS, and TUN settings section by section.

How to choose: assess configuration needs and maintenance status

On devices that still use fixed traditional nodes, simple domain rules, and a stable network environment, an original Clash configuration may continue to work. However, the original core is no longer actively maintained, so repair options are limited when new protocols, operating-system networking changes, or long-term compatibility issues arise. For new installations and users who need current protocols, complex rule sets, fine-grained DNS, or TUN interception, mihomo is generally the more suitable core.

When choosing a graphical client, confirm its bundled mihomo version, core update method, configuration override mechanism, and log access. Simply stating “supports Clash configurations” does not mean the client can fully manage mihomo extensions. Configurations that require long-term maintenance should also minimize dependence on client-specific fields and manage node sources, proxy groups, rule sets, and local overrides in separate layers.

The final criterion is not the number of features, but whether the current configuration can be verified, updated, and rolled back. mihomo expands the boundaries of Clash’s configuration model, but every extension adds its own parameters and environmental requirements. Migrating in the order of “make the old configuration compatible first, then add new capabilities” keeps protocol, DNS, rule, and system-interception issues separate and makes changes easier to diagnose after a core update.