mihomo Core Features: How It Differs from Original Clash

Scope: original Clash, Premium, and mihomo

mihomo is the core name adopted after the Clash Meta project was renamed. It retains Clash’s YAML configuration system while continuing to expand support for outbound protocols, rule expressions, DNS, and traffic interception. A client labeled “Clash” or “Meta” does not necessarily run the original Clash core. Keep the client’s name, configuration format, and core name distinct.

Here, “original Clash” means the open-source core before the original project was discontinued; it does not include Clash Premium features. Premium previously offered extensions such as TUN and rule providers, so the fact that a feature is absent from the original open-source core does not mean it was absent from every historical Clash variant. This distinction matters when migrating older configurations.

Protocol support: check the subscription’s type, then its transport options

The most noticeable difference is support for additional outbound protocols. An older core may report an unsupported proxy type during startup when it encounters type: hysteria2 or type: vless. Changing proxy groups or rule order won’t fix this: the outbound connection hasn’t been established yet.

VLESS and REALITY are not interchangeable node types

VLESS is a proxy protocol; REALITY is a secure handshake mechanism available in the corresponding outbound configuration. In mihomo, a VLESS node is generally declared as type: vless, with REALITY settings under reality-opts. Setting the node type to reality is not an equivalent conversion.

• uuid is an authentication parameter and must match the server.
• Set servername, reality-opts.public-key, and short-id using the values provided by the server. Don’t try to infer them from the domain name.
• flow, transport settings, and fingerprint options must also be compatible. Adding a single field won’t turn an existing VMess node into a VLESS node.

Hysteria2 and TUIC need a working UDP path

Hysteria2 and TUIC use QUIC, so a successful connection depends on more than core support. If the current network blocks or heavily restricts UDP, it’s entirely possible for TCP nodes to work while these protocols time out. Hysteria and Hysteria2 also use different configurations; use the protocol type specified by the subscription rather than simply changing the name.

For example, if the server listens on UDP 443, check that the port is allowed by the local firewall, upstream network, and server security group. Being able to open a website over TCP 443 does not prove that UDP works on the same address. Switching protocols is no guaranteed speed boost either: packet loss, server capacity, and rate limits all affect performance.

Rule set extensions: from inline rules to separately maintained data files

Original Clash already matches rules in order, and mihomo retains the same basic principle: the first matching rule determines the outbound. The extensions are in where rules come from and how they can be expressed. Use rule-providers to manage external rule sets, then reference them with RULE-SET. Logical rules such as AND, OR, and NOT let you combine conditions.

Minimal structure for a local rule provider

Save the two snippets below as the main configuration and a rule file, respectively. The example uses only DIRECT to demonstrate rule loading; it does not create proxy nodes. Create a rules folder in the working directory and place the rule file there. Relative paths are resolved from the core’s runtime environment, which may differ from the location of the subscription file on your desktop.

# Relevant section of the main configuration
rule-providers:
  work-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/work-domains.yaml

rules:
  - RULE-SET,work-domains,DIRECT
  - MATCH,DIRECT

# ./rules/work-domains.yaml
payload:
  - '+.example.com'
  - 'example.org'

behavior: domain means the file contains domain-matching patterns; don’t mix entries such as IP-CIDR,192.168.0.0/16 into it. To include multiple types of rule statements in one rule set, choose classical and format the file accordingly.

• domain: Best for a set of domains.
• ipcidr: Best for a set of IP ranges.
• classical: Best for rule sets containing multiple rule types.
• mrs: is a binary rule format supported by mihomo, primarily for the domain and ipcidr behaviors. Simply changing a YAML file’s extension does not convert it to mrs.

Rule providers and proxy providers serve different purposes. rule-providers supply match conditions; proxy-providers supply proxy nodes. A successful subscription update only confirms that the resource in question was updated—it doesn’t mean the other type of resource was downloaded or activated.

GEO data: GEOIP matches addresses; GEOSITE matches domain categories

GEOIP rules aren’t unique to mihomo; original Clash already supported IP matching based on geographic data. One mihomo addition is data-driven functionality such as GEOSITE, along with more options for loading and updating GEO data. The two rule types match different things, so replacing one keyword with the other won’t produce the same results.

geodata-mode: true switches how GEOIP data is handled and typically uses GeoIP.dat. The other mode, used by default, relies on MMDB data. GEOSITE uses its own domain-category data; enabling GEOIP mode does not provide every domain category. Check the data files, core version, and category names together.

Don’t treat cn as a live network measurement. Datasets are curated by their maintainers, and domain categorization and IP geolocation can change between versions. If traffic is routed incorrectly, first check which rule matched and when the local data was last updated. Then decide whether to add a more specific domain rule above it.

Enhanced TUN mode: traffic interception doesn’t mean all traffic uses a proxy

System proxy settings usually affect only apps that honor them. TUN uses a virtual network interface and routing to intercept more IP traffic. mihomo’s TUN support can handle apps that ignore the system proxy, but routing, permissions, and rules still apply. Even with TUN enabled, connections matching DIRECT go straight through.

# Merge into an existing mihomo configuration with working network access
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1

This configuration only demonstrates how traffic interception relates to DNS; it does not include proxy nodes. 1053 is the built-in DNS listening port, while 53 in dns-hijack is the destination port for traditional DNS traffic to intercept. They don’t have to use the same number. The upstream DNS servers shown are examples; use resolvers that are reachable and allowed by your network policy.

Troubleshoot stack and permissions separately

• system, gvisor, and mixed use different network stack implementations. mixed typically handles TCP with the system stack and UDP with gVisor. Confirm support for your platform and version.
• On Windows, administrator privileges or a privileged service installed by the client are usually required. On Linux, check that you have the necessary network permissions and that /dev/net/tun is available. On macOS, grant permissions as required by the client.
• auto-route modifies routing. If you use another VPN, virtual machine network, or enterprise access tool, disable the other traffic-interception tool first and compare results.
• Apps that use DoH send DNS over HTTPS. Intercepting traditional DNS traffic on port 53 won’t automatically route DoH through the same DNS path.

DNS and sniffing: enrich domain information, but don’t replace proxy rules

Fake-IP assigns a mapped address to a domain first, then restores the domain information when the connection reaches the core. The example range 198.18.0.1/16 is reserved for benchmarking and is commonly used for this purpose. Seeing an address in this range doesn’t by itself indicate a public DNS failure. Check whether the app initiating the connection is also routed through the same core.

mihomo’s sniffing feature can extract domain names from protocol data such as HTTP Host and TLS SNI, helping connections that only have a destination IP match domain rules. It doesn’t decrypt HTTPS, and it can’t extract a domain from every connection. Encrypted handshake data, non-standard protocols, and app-specific connection methods may prevent it from finding a usable name.

sniffer:
  enable: true
  sniff:
    HTTP:
      ports: [80, 8080]
    TLS:
      ports: [443, 8443]

The example limits sniffing to specific protocols and destination ports. If an application depends on a specific IP, uses an internal certificate domain, or behaves differently with sniffing enabled, first compare the results with sniffing disabled. Then narrow the scope using the bypass conditions supported by your version. Sniffing isn’t a universal fix for rules that don’t match.

Migration order: validate syntax, test nodes, verify rules, then enable TUN

You don’t need to rewrite your entire configuration to migrate. Keep the mixed port, existing nodes, and simple rules in place, then add new features one at a time. That makes it easier to tell whether an issue comes from node parameters, rule data, or system-level traffic interception. This sequence works for standalone cores and as a checklist for GUI clients.

1. Keep a restorable backup. Note the original client, core version, configuration source, and working directory. If the client supports subscription overrides or configuration merges, save those too.
2. Check that the configuration loads. Run the test command below. It can catch YAML errors, some invalid fields, and resource loading issues, but it can’t confirm that a remote node is reachable.
3. Test the proxy listener first. Confirm which port mixed-port is actually listening on, then send a request through the local proxy. The example uses 7890; update the command if your configuration uses a different port.
4. Verify which rules match. Check the connection log for the destination domain, matched rule, and final outbound. After adding GEOSITE or RULE-SET, test the same destination again.
5. Test TUN last. First make sure the system proxy path works, then enable TUN. Test a browser, an app that ignores system proxy settings, local network access, and DNS resolution separately.

mihomo -v
mihomo -t -d ./mihomo-data -f ./config.yaml
curl -I --proxy http://127.0.0.1:7890 https://example.com/

If the main configuration uses relative paths, make sure -d points to the intended working directory during testing, and prepare the rule files in advance. Once the test command succeeds, check the final configuration passed to the core by the client. Some clients merge subscriptions, overrides, and UI settings before starting the core, so the subscription file on disk may not match the active configuration.

Three errors, three troubleshooting paths

• Unsupported proxy type: Check the core name and version first, then make sure the subscription uses a mihomo-compatible format. Don’t start by changing DNS settings.
• Rule set or GEO data failed to load: Check the path, file format, permissions, and download access. Don’t hide the problem by deleting all routing rules.
• Proxy works, TUN doesn’t: Check permissions, the default network interface, conflicting routes, and DNS interception. This doesn’t mean the remote node is down.

Find client downloads and installation instructions in the Download Center. For your first subscription import, see the User Guide. To check DNS, proxy group, and TUN fields, look them up in the Configuration Handbook.