mihomo Core vs. Classic Clash: Features, Configuration Compatibility, and Which One to Choose

Scope: Cores, Clients, and Configuration Files

When discussing the differences between Clash and mihomo, first separate the core from the client. The core reads YAML, establishes proxy connections, performs DNS resolution, matches rules, and opens local listening ports. Desktop and mobile clients provide interfaces for subscription management, system-proxy toggles, log viewing, configuration editing, and service installation. A client using the mihomo core does not mean all of its settings are stored in the main configuration file; conversely, the presence of a field in the configuration does not guarantee that the client exposes a matching toggle.

In this article, “classic Clash” primarily refers to the classic open-source core developed by the Dreamacro project and its commonly used configuration baseline. Premium builds with different capabilities also existed, so not every version ever released under the Clash name should be treated as the same feature set. mihomo descends from the core branch continued by Clash Meta, extending the classic configuration structure with more proxy protocols, rule types, DNS behavior, TUN takeover options, and external resource management.

The shared foundation remains clear: configurations usually use YAML; proxy nodes go under proxies; proxy groups go under proxy-groups; routing rules go under rules; and the operating mode is controlled by mode. Common fields such as mixed-port, allow-lan, log-level, and external-controller retain similar purposes. Because the basic structure is so alike, many classic configurations can be read by mihomo—but “starts successfully” does not mean “behaves identically.”

Key Capability Differences: From Protocols to Traffic Interception

Classic Clash configurations mainly revolve around HTTP, SOCKS5, Shadowsocks, VMess, Trojan, Snell, and similar proxy types. mihomo retains widely used types while adding or improving support for VLESS, TUIC, Hysteria2, WireGuard, and other types, along with finer transport-layer, TLS fingerprint, UDP, and multiplexing parameters for some protocols. If a subscription already contains these newer types, a classic core generally cannot connect by merely renaming fields because the underlying protocol implementations are unavailable.

Traffic identification is another area with major differences. mihomo can enable protocol sniffing to use the accessed domain when handling connections that expose only a destination IP. It can also route traffic based on process name, process path, inbound type, network type, and destination port. These features suit TUN takeover, transparent proxying, and application-level routing, but they also increase configuration complexity. An incorrect sniffing scope, excluded-domain list, or port list can make the detected destination differ from the one expected by the rules, so do not enable every extension at once.

The basic concept of an external control interface is similar in both cores, and clients typically use the control port to read connection, log, and proxy-group status. However, the exact control API fields and capabilities change with core versions. An older client may start a newer mihomo core yet fail to display new policy information; a newer client connected to an older core may show buttons whose requests do nothing. Use the core and client combination recommended by the publisher.

Configuration Compatibility Boundaries: Parsing, Running, and Matching Results

Configuration compatibility can be checked at three levels. The first is syntax parsing: whether YAML indentation, lists, and data types are valid and whether the core recognizes the fields. The second is resource availability: whether proxy nodes, rule sets, Geo data, and DNS upstreams can load. The third is runtime behavior: whether the same request reaches the same proxy group, DNS returns the expected result, and system traffic actually passes through the intended inbound. Seeing “configuration loaded successfully” is not enough to confirm the latter two levels.

The following is a basic structure commonly found in both configuration families. Actual node parameters should come from the configuration source in use; the example focuses on the relationships between fields.

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

proxies:
  - name: example-node
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - example-node
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,DIRECT

When moving to mihomo, classic fields can often be retained and extensions added as needed. The reverse migration is stricter: newer protocol nodes, rule-providers, sniffer, extended DNS fields, logical rules, or mihomo-specific policy parameters may be rejected by an older core or fail to work as designed. Deleting every “unknown field” is not a universal fix, because the removed section may be essential for establishing a node connection or matching rules correctly.

Also distinguish the main configuration from client overrides. Many graphical clients merge local settings before starting the core, such as the control port, runtime directory, TUN switch, secret, DNS overrides, or system-proxy port. The YAML edited by the user may be only part of the final configuration. When troubleshooting compatibility, export or inspect the actual runtime configuration from the client and confirm the path read by the core in the logs, rather than repeatedly editing a file that is never loaded.

Fields Commonly Missed During Migration

• The path, URL, update interval, and behavior type for proxy-providers and rule-providers.
• The node names and provider names referenced by proxy groups, plus the proxy-group name referenced at the end of the rules.
• external-controller, the authentication secret, and the client control-interface address.
• geodata-mode, the Geo data loading method, and whether the required resource files exist.
• DNS enhanced-mode, fake-ip-range, filter lists, and upstream groups.
• TUN protocol stack, automatic routing, DNS hijacking, and interface-exclusion settings.

Rule Support: More Types Do Not Mean Different Priority

Rules in Clash-family cores are generally matched from top to bottom, and the policy specified on the first matching line is used. mihomo adds more rule types, but it does not generally replace ordered matching with “more specific rules always win.” If a broad DOMAIN-SUFFIX rule appears before an exact DOMAIN rule, the former may still intercept the request first; if MATCH appears too early, later rules never get a chance to run.

Common rules include DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD, IP-CIDR, IP-CIDR6, GEOIP, DST-PORT, SRC-IP-CIDR, PROCESS-NAME, and MATCH. mihomo environments also frequently use GEOSITE, RULE-SET, NETWORK, PROCESS-PATH, and logical rule combinations. The core version’s documentation and startup logs remain the authority on which types are available.

RULE-SET does not create rules by itself; it references an external rule set defined under rule-providers. Common rule-set behaviors are domain, ipcidr, and classical. domain suits domain entries, ipcidr suits IP ranges, and classical can contain classic entries with rule types. If the behavior type does not match the actual content, the file may download successfully while its entries fail to load as intended.

rule-providers:
  private-domains:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/private-domains.yaml
    url: https://example.com/private-domains.yaml
    interval: 86400

rules:
  - RULE-SET,private-domains,DIRECT
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,PROXY

no-resolve is commonly used for IP-based rules when the matching stage should not actively resolve domain names. It does not mean the connection never needs DNS, nor does it disable the DNS module; it only affects whether resolution is triggered while that rule is being evaluated. Adding it mechanically to every rule does not improve speed in every scenario and may change matching paths that depend on resolution results.

Process-rule availability also varies across operating systems. Desktop systems can usually expose process names or paths more readily, while mobile systems are constrained by permissions and network-stack limitations, so a client may not provide the core with the same information. When moving a configuration that relies on PROCESS-NAME from desktop to phone, prepare domain or IP rules as a supplement instead of assuming identical rule text will produce identical results.

DNS and TUN: The Area Most Often Misdiagnosed

A standard system proxy mainly receives traffic from applications explicitly configured to use an HTTP or SOCKS proxy, while TUN mode captures a broader range of connections through a virtual network interface. Common mihomo TUN fields include enable, stack, auto-route, auto-detect-interface, and dns-hijack. Whether these fields work also depends on operating-system permissions, routing tables, firewalls, client services, and whether another VPN application is simultaneously claiming traffic-interception capabilities.

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

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

This configuration illustrates field relationships, not a fixed answer that every device should use unchanged. TUN stack options supported by different mihomo versions may change, and clients may generate related fields automatically. If the client already manages TUN, adding a second set of parameters to the subscription configuration may be overwritten on every update or conflict with local routing settings.

DNS fake-ip mode first returns a mapped address from a reserved range to the application, then lets the core associate it with the real domain and apply rules. This helps preserve domain information during transparent interception, but LAN device discovery, some games, specific authentication flows, and applications that depend on real DNS responses may need to be added to fake-ip-filter. redir-host follows a different path, and compatibility varies with the system and application. Choose the mode by testing the observed failure, not by comparing the number of fields.

mihomo also provides finer DNS separation through nameserver-policy, proxy-server-nameserver, and direct-nameserver. The first lets selected domains use specified upstreams; the latter two distinguish resolution for proxy-server addresses from resolution for direct targets. This can reduce DNS path mixing, but incorrect settings can create a loop—for example, when resolving a proxy server’s domain requires using a DNS server that itself is reachable only through a proxy that has not yet been established.

Migration Proofing Steps from Classic Clash to mihomo

A safe migration starts with a copy of a configuration known to work; do not keep stacking changes onto your only file. Verify the basic proxy first, then add rule sets, DNS, and TUN in stages. This quickly shows whether a failure belongs to node connectivity, rule matching, or system interception.

1. Record the current runtime details. Save the original core version, client version, listening ports, system-proxy status, DNS mode, and available proxy groups. If behavior changes after migration, these details provide a baseline for comparison.
2. Check the YAML structure. Confirm that indentation uses spaces only, node names exactly match proxy-group references, ports are numeric, and Boolean values have not accidentally become strings. Fix parsing errors before investigating network errors.
3. Build a minimal connection test. Temporarily use one known-working node, one select proxy group, and a small set of rules. Once the local mixed port is reachable, import the full subscription or proxy provider.
4. Restore rule resources one by one. Check each provider’s download status, file path, behavior, and format. When a rule-set update fails, do not only check whether the proxy group exists; confirm the entry count in the logs as well.
5. Validate DNS separately. Check the proxy server’s domain, a direct-access domain, and a domain that requires the proxy separately. If domains fail while direct IP access works, the problem is usually closer to the DNS path than to the node protocol.
6. Enable TUN last. Disable other VPN or traffic-interception tools first, confirm administrator privileges and service components, then inspect the routing table, DNS hijacking, and LAN access. If the standard system proxy works but TUN does not, focus on system-level configuration.
7. Verify the final effective configuration. If the client supports overrides, scripts, or merging, inspect the merged result. After a subscription update, confirm again that local rule and DNS changes are still present.

Error types in the logs can narrow the scope. unknown field or configuration parsing failures usually point to a field/version mismatch; rule-provider download failures call for checking the URL, network path, and storage directory; connection timeouts require separating proxy-server resolution, transport handshake, routing, and rule selection. When several errors appear at once, do not change the port, DNS, node, and TUN all together; batch changes destroy the baseline needed for comparison.

How to Choose: Start with the Configuration Source and Real Requirements

If the existing configuration uses only classic protocols, simple proxy groups, and a small number of domain rules, and the client/core combination has remained stable, staying with a compatible classic environment can reduce migration costs. Still, watch the project’s maintenance status, operating-system upgrades, and client support—especially whether the control interface, system-proxy service, and certificate components continue to work together.

If the subscription includes newer node types such as VLESS, TUIC, or Hysteria2, or the configuration depends on GeoSite, rule providers, logical rules, protocol sniffing, fine-grained DNS routing, or actively maintained TUN support, mihomo is usually the better fit. Choose a client that clearly identifies its core version, and keep the client, core, and configuration syntax within mutually supported version ranges.

There is no need to chase the core with the most fields. For typical desktop users, a stable system proxy, refreshable subscriptions, and clear proxy groups cover the main needs. Users who need gaming UDP, LAN sharing, container networking, per-process routing, or full TUN takeover should test the relevant implementation on their operating system. The same YAML may behave differently on Windows, macOS, Linux, Android, and iOS because permissions and network frameworks differ.

Four Checks Before Choosing

• Whether the node protocols in the subscription are supported by the target core.
• Whether the rules depend on mihomo-specific types, Geo data, or external rule sets.
• Whether the client can manage the required TUN, service mode, and system-proxy settings.
• Whether the configuration update mechanism preserves local overrides and custom rules.

From a configuration-management perspective, mihomo is better suited to expanding protocol and rule requirements, while classic Clash configuration remains an important foundation for understanding ports, proxy groups, and top-to-bottom rule matching. The key to migration is not adding more fields to an old file, but verifying protocol support, resource files, DNS paths, and system interception one item at a time. Keeping a minimal working configuration and making every change verifiable is usually more reliable than copying a complex configuration wholesale.

Frequently Asked Questions