mihomo vs. Original Clash: Protocols, Rule Providers, and TUN

Understand the difference between clients, cores, and configurations

If a subscription imports successfully but its nodes won't connect, don't rush to replace the subscription. The GUI client manages subscriptions, the interface, and system settings; the core parses the configuration, establishes proxy connections, and applies routing rules. A node appearing in the interface doesn't mean the core can handle its protocol. Check the core name and version in the client logs first, rather than relying on the version number shown in the app window.

mihomo is the renamed continuation of the original Clash Meta project. It retains the Clash configuration ecosystem and continues to expand it. When comparing it with “original Clash,” distinguish between the historical open-source core and the closed-source Premium core: their feature sets differ, particularly for rule providers and TUN. Conflating the two can lead to mistaken claims such as “older Clash had no rule sets at all.”

If you're running the standalone core, check its version with mihomo -v. In a GUI client, confirm the binary actually loaded in the core information or startup logs. Updating the app doesn't necessarily switch it to the core you expect.

New protocols: the first compatibility check for a node

One key difference from the historical original Clash is mihomo's support for more proxy protocols and transport combinations, including VLESS, Hysteria2, and TUIC. These aren't different names for the same protocol, and changing the type in a config won't convert one into another. The client must use the authentication, transport, and TLS settings that match the protocol deployed on the server.

Treat VLESS and REALITY as separate components

VLESS is a proxy protocol; REALITY is a security mechanism that can be used for the connection. They are not interchangeable terms. A VLESS node may use standard TLS or REALITY, and different combinations can involve fields such as network, servername, flow, and reality-opts. Use the parameters specified by the server configuration; don't add REALITY settings just because a node uses VLESS.

• UUID: Identifies a VLESS user. It can't be replaced with a password from another protocol.
• Server name: servername is used during the TLS handshake. An incorrect value can cause certificate or handshake errors.
• REALITY parameters: The public key, short ID, and other values must match the server. Matching node names don't prove the parameters are the same.
• Transport: TCP, WebSocket, gRPC, and other settings must match on both ends; changing only one field isn't enough.

Hysteria2 and TUIC require a working UDP path

Hysteria2 and TUIC use QUIC-based transport and need a working UDP path to reach the server. Being able to open regular HTTPS websites doesn't guarantee these nodes can connect if the current network restricts UDP. Check the logs for timeouts, authentication failures, and TLS errors instead of repeatedly changing rule modes.

Hysteria v1 and Hysteria2 aren't interchangeable either. If a subscription converter exports a v2 node as a v1 type or drops required authentication parameters, changing proxy groups won't fix it. The safest option is to use a mihomo-compatible configuration explicitly provided by the subscription service and verify the generated node type.

Rule sets: reuse rules and control match order

rule-providers lets you maintain a group of rules as a separate resource and reference it in your main rules with RULE-SET. This wasn't introduced by mihomo; the historical Clash Premium core already supported it. mihomo continues to extend the format and matching capabilities, but the available fields depend on the core version you're running.

Know the three rule behaviors

• domain: For domain entries. Don't paste a complete rule like DOMAIN-SUFFIX,example.org as if it were a plain domain.
• ipcidr: For IP ranges, such as 192.168.0.0/16.
• classical: For entries that include a rule type, such as DOMAIN-SUFFIX,example.org.

Here's an example of a local rule set with no proxy nodes. Merge the first block into your existing configuration. Paths are resolved relative to the core's working directory, and the file shown in the second block must exist there. This demonstrates how to reference a rule set; it isn't a complete configuration that can replace your subscription.

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

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

The contents of rules/local-direct.yaml are shown below. The two entries match an example reserved domain and a private IP range:

payload:
  - DOMAIN-SUFFIX,example.org
  - IP-CIDR,192.168.0.0/16,no-resolve

When migrating, keep your intended final policy. Don't copy MATCH,DIRECT from the example and expect traffic to use a proxy. Rules are usually evaluated from top to bottom, so a broad DIRECT rule near the top can prevent later proxy rules from matching. Referenced proxy group names must also exist and match exactly, including capitalization and spaces.

Rule set formats aren't freely interchangeable

mihomo's MRS binary rule format has specific use cases, mainly for domain and ipcidr behavior. You can't use an arbitrary classical file by simply changing its extension. For remote rule sets, interval is measured in seconds; for example, 86400 means one day. This is the rule resource's update interval, not the refresh interval for the client's subscription profile.

TUN improvements: wider traffic coverage, more troubleshooting layers

System proxy settings affect apps that explicitly honor them. TUN uses a virtual network interface and routing to capture more IP traffic, making it useful for apps that ignore system proxy settings. The historical Premium core also supported TUN, so the difference isn't simply “the old version didn't have it.” mihomo's strengths include an actively maintained TUN implementation, network stack options, and configuration for working with routes and DNS.

The stack, routing, and DNS are separate concerns

On Linux, creating a TUN device and changing routes require appropriate permissions. A GUI client may handle this through an installed privileged service; with the standalone core, you'll need to manage permissions and services yourself. If permissions are denied, first check the service status, logs, and whether /dev/net/tun is available. Repeatedly switching nodes won't fix a device creation failure.

The following is a common TUN configuration snippet. Merge it with your existing DNS, nodes, and rules before testing. It doesn't include a complete DNS listener configuration, and automatic routing isn't suitable for every device.

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

Configuration compatibility: parsing successfully doesn't guarantee the same behavior

Familiar structures such as proxies, proxy-groups, and rules are still there, but migration takes more than copying text. Legacy fields may have newer recommended forms, and older cores may reject or ignore newly added fields. Even if the syntax passes, test the actual DNS behavior, proxy group selection, and process matching.

Validate the file before enabling traffic capture

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

The second command checks the configuration; it isn't a full connectivity test. After it passes, verify the node handshake, DNS resolution, and routing results. If you're using a GUI client, note that it may merge or override the subscription before startup. The raw YAML you inspect manually may not be the same configuration ultimately passed to the core.

1. Check the listening port: If you plan to use mixed-port: 7890, make sure your browser or system proxy points to localhost port 7890, not another port from an older configuration.
2. Check the control interface: external-controller serves a different purpose from the proxy port. If you use 127.0.0.1:9090, port 9090 is the management interface, not the HTTP proxy port for browsing.
3. Check the subscription contents: A subscription containing only a node list may not include proxy groups, DNS, or rules. Check the client's configuration merge mechanism to see how these are added.
4. Check local overrides: Put custom rules, ports, and DNS settings in the client's persistent override mechanism. Direct edits to a remote subscription file may be overwritten on refresh.

Test DNS and process rules separately

fake-ip and redir-host are DNS modes, not proxy modes. If you change the DNS mode, upstream servers, and TUN setting all at once when switching cores, it's difficult to tell which layer caused a problem. Keep your existing DNS setup initially, confirm basic connectivity, and then adjust one setting at a time.

Process name and path rules also depend on operating system support, core permissions, and whether connection details can be retrieved correctly. A rule may be valid but fail to match if the process can't be identified. Check process information and the matched rule in the connection log; not every mismatch is caused by rule order.

Migration testing: change one variable at a time

The goal of migration is to identify which capabilities you've gained and whether existing configurations still behave as expected. Work through the checks below, recording the result at each step before moving on. This makes problems easier to isolate than enabling every enhanced feature at once.

1. Back up: Save your original profile, local rules, override configuration, and current port and DNS settings. Subscription URLs may contain access credentials, so don't post them in full in public logs.
2. Basic proxy: Start with TUN disabled. Test the local proxy on port 7890 with a node you know works to rule out protocol and authentication errors.
3. Test rules: Visit sites that should connect directly and through a proxy. Check the matched rule and final policy in the connection log, not just whether the page loads.
4. Load rule sets: Check each provider's loading status. An incorrect file path, a failed download, and malformed entries are different issues; troubleshoot each based on the logs.
5. Enable TUN: Turn on TUN last. Test apps that ignore system proxy settings, then check local network access, other VPNs, and network switching.
6. Refresh the subscription: Run a manual refresh and make sure your custom settings remain in place before scheduling automatic updates.

Whether migration is worthwhile depends on what you need. mihomo is a clear fit if your subscription includes VLESS or Hysteria2 nodes, or you need more granular rules and actively maintained TUN features. If your current connection is failing, first distinguish a node outage from a configuration error or system network conflict. Switching cores can fill capability gaps, but it can't replace checking server parameters and local routes.

For more on fields and rules, see the Core and Configuration Reference. When setting up a virtual interface for the first time, follow the TUN Mode Guide to check permissions and traffic coverage step by step.