mihomo Core Features: Rules, Protocols, and Runtime Differences from Original Clash

mihomo and the original Clash: compatibility

The original Clash established a configuration structure that is easy to combine: define nodes in proxies, organize manual selection, automatic testing, or failover strategies in proxy-groups, then pass connections to those groups in order through rules. mihomo preserves this basic structure, so a typical Clash YAML configuration can often serve as a starting point for migration. Basic rules such as DOMAIN-SUFFIX, DOMAIN, IP-CIDR, GEOIP, and MATCH, along with common group types such as select, url-test, and fallback, have broadly similar meanings in both configuration models.

This compatibility does not mean that every configuration field is identical. Fields, proxy types, or rule syntax added by mihomo may not be recognized by the original Clash. Conversely, legacy fields in older configurations may have been changed, deprecated, or supported only by a particular client’s preprocessing layer. Subscription-converter output is especially likely to mix core fields, client-specific fields, and template variables. During migration, inspect the final YAML passed to the core rather than relying only on the subscription URL’s label.

Configuration compatibility has three levels

1. Syntax can be parsed: YAML indentation, lists, and field names pass parsing, allowing the core to start.
2. Objects are recognized: The current core version supports the node protocols, proxy-group types, rule types, and DNS fields in use.
3. Behavior matches expectations: Rule order, DNS responses, latency testing, and the scope of traffic interception match the intent of the original configuration.

A “configuration imported successfully” message usually covers only part of the first two levels. A proper compatibility check also requires confirming that proxy groups are complete, rule providers update successfully, DNS is listening, logs show no unknown fields, and the target site is actually matched by the intended policy.

Rule-system differences: from ordered matching to compound conditions

Clash and mihomo both follow a key rule-processing principle: rules are checked from top to bottom, and the first match determines where a connection goes. A larger rule set does not necessarily mean more accurate routing; order and condition scope matter more. Putting a broad domain-suffix rule before a specific rule may prevent the later rule from ever running. Moving MATCH upward will immediately take over all remaining traffic.

On top of the basic rule model, mihomo provides richer matching dimensions. In addition to common conditions such as domains, destination IPs, source IPs, ports, and processes, supported versions can combine conditions with logical AND, OR, and NOT relationships. This makes it possible to express more precise requirements, such as routing a specific process through a chosen policy only when it accesses a particular port, or using a proxy when both a domain set and protocol type match. Rule names and nesting syntax may change between versions, so check the documentation and startup logs for the version in use before writing rules.

What basic and extended rules each focus on

• Domain rules: DOMAIN matches a complete domain exactly, while DOMAIN-SUFFIX matches a domain and its subdomains, making them suitable for stable site categories.
• IP rules: IP-CIDR and IP-CIDR6 match against destination address ranges. If you need to avoid an extra DNS lookup for this rule, use the relevant option where supported.
• Geographic data rules: GEOIP classifies addresses using an IP database. mihomo also commonly works with GEOSITE or rule sets for domain classification. Result quality depends on the source and update time of the data files.
• Process rules: Route traffic by process name or path. This is useful on desktop systems, but permissions, the operating system, and the interception method can affect detection.
• Inbound and network conditions: Further refine policies by inbound source, TCP or UDP, source address, port, and other connection details. This is useful for gateway or multi-entry deployments.
• Rule providers: Move large rule sets out of the main configuration with rule-providers, update them on a defined schedule, and reference them through RULE-SET.

Rule providers are highly useful in large configurations, but more is not always better. Multiple rule sets may cover the same domain, and failed updates can produce routing results different from expectations. Put required direct connections for the LAN and system services near the top, order clearly defined business rule sets by priority, and keep an explicit fallback policy at the end. For rule sets from unknown sources, long overdue for updates, or unusually large, verify their format and behavior first.

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

rules:
  - DOMAIN,router.local,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - RULE-SET,service-set,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

This structure demonstrates how rules can be organized; it is not suitable for direct copying into every environment. Remote URLs, proxy-group names, rule-set formats, and storage paths must match the actual configuration. In particular, behavior must match the downloaded file’s content format, or the rule provider may fail to load. After the client reports a successful update, also check the core log to confirm that parsing completed.

Protocol support: importing a node does not guarantee a connection

The original Clash supports a range of traditional proxy protocols and uses unified proxy groups for node switching. mihomo extends this foundation with more modern protocols and transport combinations, commonly including VLESS, Reality, Hysteria2, TUIC, WireGuard, and protocol-specific TLS, WebSocket, and gRPC options. The usable range depends on the mihomo version, build target, and the client’s integration status. The presence of a particular link format in a subscription is not proof that it will work.

Subscription import usually has two stages: the client or subscription service first converts node links into YAML objects, then the core reads those objects and establishes connections. If a node never appears in a proxy group, the conversion stage may not have recognized it. If the node is displayed but connection attempts fail, the more likely causes are core parameters, server-side settings, the network environment, or the system clock. Checking these stages separately is more effective than repeatedly reimporting the subscription.

Parameters to verify when migrating protocols

• Confirm that the server address, port, user identifier, and authentication details are complete.
• Check whether TLS is enabled and whether the server name, ALPN, and certificate-related parameters match the server.
• Confirm whether the transport uses TCP, UDP, WebSocket, gRPC, or another method, and whether the path and service name match.
• For Reality, verify the public key, short ID, and fingerprint parameters.
• Check whether UDP-based protocols such as Hysteria2 and TUIC are restricted by the current network, router, or firewall.
• Confirm that the proxy group references the relevant node and that renaming the node has not left a dangling reference.

Latency tests cannot fully represent the real browsing experience. url-test generally measures response time against a specified URL and repeats the test at set intervals. It can help select a reachable, lower-latency node, but it does not measure video throughput, long-connection stability, UDP quality, or restrictions imposed by the destination site. If every node passes testing but a particular app still fails, check rule matches, DNS results, the IPv6 path, and whether the app bypasses the system proxy.

One major benefit of switching from the original Clash to mihomo is the ability to handle more node types within the same policy system. More protocols also mean more complex configuration fields. Subscription users should preferably have the provider generate a mihomo-compatible configuration. Users maintaining configurations manually should first verify a single node and a simple proxy group, then add automatic selection, load balancing, and complex rules incrementally.

Runtime differences: DNS, sniffing, and TUN mode

The core’s runtime capabilities determine how traffic enters the proxy system and what information is available for rule matching. A system proxy generally affects only applications that follow the operating system’s proxy settings. TUN mode uses a virtual network interface to intercept a broader range of IP traffic, making it suitable for programs that ignore system proxy settings, some games, or environments that require unified handling. mihomo offers extensive configuration options for TUN, DNS, and traffic identification, but it also depends more heavily on system permissions and correct network parameters.

Key points about TUN mode

After TUN is enabled, the client generally needs to create a virtual network adapter, adjust routes, or enable automatic redirection. Implementation details vary by operating system. A client may offer stack options such as system, gVisor, or mixed; the available choices depend on the current core and client. A stack that is stable on one device may behave differently across operating-system versions, virtual machines, or corporate security environments.

Common TUN issues include routes not being written correctly, LAN access being intercepted, inconsistent DNS paths, virtual interfaces failing after sleep or wake, and other VPN software modifying the default route at the same time. During troubleshooting, first disable other traffic-interception tools, confirm that ordinary system-proxy mode works, then enable TUN and inspect the logs. If only LAN devices become unreachable, check whether private address ranges are configured for direct access instead of changing every rule.

DNS modes and domain rules

Whether domain rules work accurately is closely tied to DNS handling. Common enhanced DNS modes in mihomo include redir-host and fake-ip. fake-ip returns a mapped address from a reserved range for the domain, then restores the domain during connection handling. This helps applications that initiate IP-only connections still participate in domain-based rule matching. Some LAN services, device discovery mechanisms, game platforms, or programs that require real-address checks may need to be added to the fake-IP filter list.

DNS configuration may also distinguish between the default resolver, the resolver for proxy-node domains, policy-selected resolvers, and fallback resolvers. The most common pitfall is a circular dependency: the proxy server address is itself a domain, but resolving that domain is configured to require a proxy that has not yet connected. A sound setup provides a directly reachable baseline resolution path for node domains and clearly separates resolving the proxy server address from resolving destination websites after the proxy is established.

The limits of traffic sniffing

Traffic sniffing can identify destination domains from handshake information such as HTTP Host and the TLS Server Name, supplying domain information that is missing when only a destination IP is available. This is useful for rule matching in TUN scenarios, but sniffing does not decrypt HTTPS content and cannot extract a domain from every connection. Encrypted handshakes, QUIC, application-specific protocols, or connections that use an IP directly can all limit detection.

If enabling sniffing causes connection problems in a particular app, first check whether the detected domain is correct, then configure a bypass for the relevant target if needed. Do not treat sniffing, DNS, and rule issues as the same problem: if the log shows a domain but the policy is wrong, inspect rule order; if it shows only an IP, focus on DNS and sniffing; if the connection never reaches the core, check the system proxy, TUN routes, or the app’s own settings.

A practical order for migrating a Clash configuration to mihomo

The safest way to migrate is not to enable every extension at once. Start with a minimal, testable configuration and restore features layer by layer. This makes it possible to identify whether an error occurs during YAML parsing, node connection, proxy-group references, rule loading, DNS handling, or system traffic interception.

1. Confirm the client’s actual core. Check the core name and version on the client’s About page, core-management page, or startup log. “Clash” in the interface title is not sufficient evidence.
2. Back up the original configuration. Keep the original YAML, subscription URL, custom rules, and DNS settings. The client database and an independently exported YAML may not contain the same data, so save important changes separately.
3. Verify YAML parsing first. After importing, check the logs for unknown fields, duplicate keys, indentation errors, and failed rule-provider loads. YAML uses spaces to express hierarchy; tabs or incorrect indentation can change the structure.
4. Test nodes with a simple policy. Create a manual selection group with only a few nodes and confirm that TCP and any required UDP connections work. Do not add complex latency testing or load balancing yet.
5. Check proxy-group references. The group targeted at the end of the rules must exist. Node and group names referenced inside proxy groups must also match exactly. Spaces and punctuation are part of the name.
6. Load rule sets gradually. Add LAN direct rules, core business rules, regional rules, and the final fallback in sequence. Each time, observe the rule-provider update status and the actual match result.
7. Adjust DNS and TUN last. Confirm basic connectivity in system-proxy mode before enabling enhanced DNS, sniffing, and TUN. After adding each interception layer, retest websites, command-line programs, LAN access, and UDP apps.

How to isolate the cause of a problem

If the core cannot start, first check configuration syntax, supported fields, and port conflicts. If every node is unavailable, check network connectivity, protocol parameters, the system clock, and node-domain resolution. If only some sites are routed incorrectly, inspect the domain, destination IP, and matched rule in the connection log. If the browser works but an app does not, check whether the app reads the system proxy or requires TUN interception. If the entire network fails after enabling TUN, return to system-proxy mode first, then check the virtual adapter, default route, and DNS listening status.

Adjust the log level as needed. Normal use requires only the standard level; during troubleshooting, enable more detailed logging temporarily and remember that logs may contain visited domains, node addresses, and local paths. Restore the normal level after identifying the cause to reduce irrelevant output and long-term log usage.

Choosing between the original Clash and mihomo

For users choosing a client today, the more practical question is usually which client uses which core, rather than which standalone command-line core to install. If a configuration contains only traditional protocols and basic routing, works reliably in the current environment, and has no new capability requirements, there is no need to migrate simply because the name has changed. A stable configuration, clear rules, and repeatable backups matter more than chasing every new field.

If a subscription includes VLESS Reality, Hysteria2, TUIC, or similar nodes, or requires logical rules, rule providers, fine-grained DNS policies, traffic sniffing, or TUN interception, mihomo generally provides a more complete foundation. Also confirm that the graphical client integrates the relevant version promptly, can manage core updates, presents logs clearly, and offers system-proxy and TUN controls that fit the conventions of the current platform.

The difference can be summarized this way: the original Clash established the configuration and rule-routing model, while mihomo preserves that model and extends its protocols, rules, and runtime capabilities. Migration is not about turning on every extension; it is about understanding what each added capability solves and validating the result through logs and staged testing. For most configurations, ensuring that basic nodes, proxy groups, and rule order are correct before handling DNS, sniffing, and TUN will prevent the most common chain reactions.