Why mihomo Is More Capable Than Classic Clash: Protocols, Rule Sets, and TUN Mode Compared

Start by separating the kernel from the client

Clash, mihomo, and FlClash operate at different layers. The kernel reads YAML configuration, establishes proxy connections, matches rules, handles DNS, and forwards traffic. The client manages subscriptions, edits configuration, toggles the system proxy, displays logs, and requests platform permissions. FlClash is a graphical client; mihomo is a proxy kernel it can use. When comparing “classic Clash” with mihomo, the real comparison is between kernel capabilities—not window layouts or button counts.

The original Clash usually refers to the open-source Clash released by Dreamacro. Its public releases stopped at v1.18.0, with common baseline capabilities including HTTP, SOCKS5, and mixed inbound modes, rule mode, proxy groups, DNS handling, and proxy types such as Shadowsocks, VMess, and Trojan. Clash Meta continued extending the original codebase and was later renamed mihomo. Many configuration fields remain compatible, so older subscriptions can often be loaded directly. Compatibility, however, does not mean the two kernels offer identical features.

Differences you can observe directly

Protocol support: node types are the first major difference

Classic Clash already covers traditional subscriptions with common outbound types such as Shadowsocks, VMess, Trojan, HTTP, SOCKS5, and Snell. The issue is that proxy protocols continue to evolve. If a server offers Hysteria2, TUIC, VLESS Reality, ShadowTLS, or WireGuard nodes, an older kernel may report that the proxy type is unsupported or ignore those nodes after parsing the subscription.

mihomo provides native configuration entries for these types and brings them into the same proxy-group, health-check, and rule-routing system. For example, a url-test proxy group can contain both traditional Trojan nodes and Hysteria2 nodes, then select one automatically based on probe latency. For users, the improvement is not simply a longer protocol list; nodes in a subscription can be used by the same rule system.

More protocols do not mean you must enable every one

• Hysteria2: Built on QUIC and typically using UDP, it is a good fit when both the server and network provide stable UDP connectivity.
• TUIC: It also relies on QUIC and UDP. The UUID, password, and congestion-control settings must match the server.
• VLESS: It can be used with TLS, Reality, and different transport methods, so the node name alone does not reveal the transport structure.
• WireGuard: It uses a tunnel-interface model and requires the correct private key, public key, address, and allowed-route range.
• ShadowTLS: It is used for specific chained setups, and the configuration usually references another dialer proxy.

When choosing a node, also consider server deployment quality, packet loss, and the local network. A single latency test reflects only the round-trip time to the probe URL at that moment. For example, a TCP node probing at 82 ms and a QUIC node at 61 ms does not mean the latter will always download faster; if the carrier throttles UDP, the QUIC node may become noticeably unstable after a few minutes.

rule-providers: move large rule sets out of the main configuration

The main purpose of rule-providers is to store rules in separate files and reference them from the main configuration through RULE-SET. This concept was not invented by mihomo; later versions of the original Clash configuration system already supported rule providers. mihomo’s advantage is its continued improvement in format support, match types, update workflows, and related behavior, along with support for richer rule syntax.

A configuration with only a few dozen rules can place domains directly under rules. Once the list reaches tens of thousands of entries, embedding everything makes the main file difficult to read and complicates subscription overrides and version control. After splitting the data out, the main configuration keeps only the rule-set URL, update interval, and target policy; the rule content is maintained separately.

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

  private-ip:
    type: http
    behavior: ipcidr
    format: yaml
    url: https://example.com/rules/private-ip.yaml
    path: ./ruleset/private-ip.yaml
    interval: 86400

rules:
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,private-ip,DIRECT,no-resolve
  - MATCH, choose a node

behavior determines what the file can contain

• domain: For domain-based entries, such as domain suffixes and full domains.
• ipcidr: For IPv4 and IPv6 network ranges. If the match does not need to trigger DNS, add no-resolve after the rule reference.
• classical: Each entry can include a complete rule type, such as DOMAIN-SUFFIX, PROCESS-NAME, or IP-CIDR.

interval: 86400 checks the remote rule once every 86400 seconds, or 24 hours. It does not download the file for every request. After the first successful fetch, the kernel uses the local cache; if the remote server is temporarily unreachable, the existing file can usually continue matching traffic. Keep in mind that the rule URL itself must be reachable from the current network, or the first startup may have no usable cache.

mihomo also supports the binary mrs format for rule collections. It is suited to large domain or IP rule sets and aims to reduce parsing overhead and storage usage. mrs is not plain text and cannot be edited line by line in a regular editor; for private rules that require manual maintenance, YAML or a text format remains more practical.

Rule order still matters more than rule count

Clash rules are evaluated from top to bottom, stopping at the first match. Even when a rule set updates successfully, a broad proxy rule placed before a direct rule prevents the later direct entry from running. A common order puts private domains, LAN ranges, and reserved addresses first; application rule sets in the middle; GEOIP or other regional checks later; and MATCH as the final fallback.

TUN mode: from system proxying to broader traffic capture

A system proxy usually affects only apps that actively read the operating system’s proxy settings. Browsers generally do, but games, command-line tools, some store clients, virtual machines, and software that sends UDP directly may bypass it. TUN mode creates a virtual network interface and sends matching IP traffic into the kernel, giving it broader coverage.

Different versions and distributions of the original Clash have offered TUN support, but their configuration, platform integration, and maintenance status were inconsistent. mihomo continues to expand automatic routing, DNS hijacking, multiple network stacks, interface selection, and strict routing for TUN. This is a major reason modern graphical clients commonly use mihomo.

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

What these fields control

• stack: mixed: Uses a mixed protocol stack to handle connections and is often a good starting point on desktop systems. The available values depend on the current kernel version.
• auto-route: true: Automatically adds the required routes so target traffic enters the TUN interface.
• auto-detect-interface: true: Automatically detects the current default interface, reducing manual adjustments when switching between Wi-Fi and wired networks.
• strict-route: true: Enforces tighter routing constraints and reduces the chance of traffic bypassing TUN; virtualized or LAN environments may require additional testing.
• dns-hijack: Takes over DNS requests sent to specified ports. Traditional DNS commonly uses UDP or TCP port 53.

In FlClash, first import the configuration and confirm that the regular system proxy works, then open “Settings” → “Network Settings” and enable TUN mode. Android and desktop systems may ask to create a VPN or virtual network interface; after granting permission, check the logs for the TUN initialization result. If the menu wording differs slightly in your client version, look in “Settings” for TUN, VPN service, or network-interface options.

Common TUN conflicts

1. Another VPN is running: If both programs try to take over the default route, the network may disconnect or the route may switch repeatedly.
2. LAN access fails: The subnet used by printers, NAS devices, or development machines may need a direct rule. Common private ranges include 192.168.0.0/16, 10.0.0.0/8, and 172.16.0.0/12.
3. Virtual machines and containers: Docker, WSL, Hyper-V, and similar tools create virtual network adapters. If automatic interface detection is wrong, check the selected egress interface and excluded routes.
4. DNS is being intercepted twice: System security software, encrypted DNS tools, and mihomo listening for or redirecting DNS at the same time can cause query timeouts.

Sniffing: recover domains under transparent proxying

The rule engine works best when traffic can be matched by domain, but TUN often sees only the destination IP first. For example, an app may perform its own DNS lookup and then connect directly to 203.0.113.10:443. If the kernel receives only the IP, it cannot directly apply a DOMAIN-SUFFIX rule. A sniffer analyzes early connection data and extracts the domain from the TLS server name, HTTP Host, or QUIC information for rule matching.

sniffer:
  enable: true
  parse-pure-ip: true
  override-destination: true
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443

parse-pure-ip allows mihomo to try identifying a domain when the destination appears as a bare IP; override-destination determines whether the sniffed result replaces the original destination information. Set port ranges according to the actual workload instead of enabling every parser on every port just to “cover everything.” Private protocols that are not HTTP, TLS, or QUIC cannot yield a usable domain through these parsers.

Sniffing is not a replacement for DNS

Sniffing occurs while a connection is being established, whereas DNS determines how a domain is resolved; they solve different problems. A stable configuration still needs appropriate DNS fields such as nameserver, fallback, fake-ip, or redir-host. With Fake IP, the kernel maps a domain to an address in a reserved pool and restores the domain during connection handling. Sniffing can supplement this by covering traffic that bypasses the kernel’s DNS and connects directly to an IP.

Some applications use certificate pinning, encrypted client hellos, or custom QUIC behavior, so sniffing may not produce a usable name. If a connection is overridden incorrectly, check the original and sniffed destinations in the logs first. Then exclude specific traffic with skip-domain or skip-source-address rules instead of disabling sniffing everywhere.

Check DNS, rules, and TUN as one configuration

mihomo’s enhanced features are interconnected. Enabling TUN without handling DNS may leave rules without a domain; enabling sniffing without correct rule ordering can make a recovered domain match the wrong policy; and a correctly configured rule set still cannot be saved on first startup if its download URL is blocked by the current network. Troubleshoot in this order: inbound capture → DNS → sniffing → rule matching → proxy group → outbound connection, reviewing the logs at each step.

A repeatable troubleshooting workflow

1. In regular system-proxy mode, confirm that at least one basic node can establish a TCP connection.
2. Check whether the mixed inbound port is already in use. A common value is 7890; do not let two clients listen on the same port.
3. Confirm that the DNS logs return results, and check whether they are real IP addresses or Fake IP addresses.
4. After enabling TUN, turn off the system proxy and test whether apps that ignore system-proxy settings appear in the kernel logs.
5. Review the Host, destination IP, matched rule, and final proxy group in the connection records to ensure the sniffed result has not overridden the destination incorrectly.
6. Update the rule provider manually and verify the HTTP status, save path, and update time. Then wait through one complete interval cycle to confirm automatic updates.
7. Test TCP and UDP separately. A webpage loading only shows that the TCP path basically works; it does not prove that QUIC, in-game voice, or DNS over UDP works.

Who will notice mihomo’s advantages most

Users who only browse the web, use basic Shadowsocks nodes, and maintain a few domain rules may not see an immediate speed change after switching kernels. mihomo’s value is more about coverage and configuration headroom: it can parse new protocols in subscriptions, use TUN to capture apps that bypass the system proxy, use sniffing to recover missing domains from transparent traffic, and update large rule sets independently through rule providers.

• Subscriptions include Hysteria2, TUIC, or VLESS: Protocol compatibility is a direct requirement.
• You need to proxy games, terminals, or store clients: TUN provides more complete coverage than setting up only an HTTP system proxy.
• You maintain extensive routing rules: rule-providers separates the main configuration from rule data.
• You use Fake IP and transparent proxying: Coordination between DNS, sniffing, and domain rules becomes more important.
• You frequently switch between Wi-Fi, wired networks, and hotspots: Automatic interface detection and routing reduce manual adjustments.

When migrating an older configuration to mihomo, do not enable every enhancement at once. A safer order is to verify nodes and proxy groups first, then rules, then DNS, and finally TUN and sniffing. If something breaks, you can quickly identify whether the cause is the proxy protocol, resolution path, rule order, or system routing.

The conclusion comes down to four points: Classic Clash established the configuration syntax and rule-based proxy model; mihomo preserves that compatibility foundation while continuing to add protocols; rule providers are better suited to large, updateable rule data; and TUN plus sniffing extends routing from apps that support system proxies to a broader share of device traffic. Configure only the features you need rather than mechanically stacking fields.