Clash core versions compared: Clash Premium vs. Clash Meta vs. mihomo

First, clarify the names: these are not three independently evolving versions

A Clash client usually consists of three parts: the graphical interface, the core, and the configuration file. The interface handles subscription imports, proxy switching, and log display; the core establishes proxy connections, parses rules, applies DNS policies, and takes over traffic. Clients with the same name may use different cores. To determine supported features, check the core name and version rather than the app name alone.

The original Clash refers to the open-source core released by Dreamacro, with support for HTTP, SOCKS, mixed proxy ports, proxy groups, and basic rule matching. Clash Premium was an enhanced build released by the original author, adding TUN, rule sets, scripts, and more complete traffic interception. After the original repository stopped being maintained in 2023, neither the original core nor Premium remained a suitable baseline for ongoing feature development.

Clash Meta is an enhanced community fork of Clash. It retains the Clash configuration structure while expanding protocol, rule, DNS, TUN, and proxy-group capabilities. The project later adopted mihomo as its official name, so Clash Meta and mihomo are primarily successive names for the same project, not two entirely separate new cores. Older clients may still display Meta, while newer releases, documentation, and process names more often use mihomo.

Names and maintenance status

Protocol support: start with the transport used by your subscription nodes

A core being able to read a subscription does not mean it can connect to every node in that subscription. After conversion, a subscription usually becomes a set of proxies, with each node containing a type, server address, port, and authentication fields. When an unsupported type is encountered, the core may fail during loading or skip that node, so the subscription appears updated while the node count drops.

The original Clash and Premium: basic coverage

The original Clash mainly supported common types at the time, including Shadowsocks, VMess, Trojan, Snell, SOCKS5, and HTTP. Premium’s main advantages were TUN, rule sets, and runtime capabilities; it should not be assumed to support every proxy protocol introduced later. Loading a subscription with newer fields into an older Premium client may still produce unsupported proxy type or field-parsing errors.

mihomo’s expanded protocol coverage

Building on compatibility with common Clash node structures, mihomo has continued adding types and transport combinations such as VLESS, Reality, Hysteria 2, TUIC, WireGuard, and ShadowTLS. Exact fields vary by core version. For example, VLESS Reality commonly uses servername, reality-opts, a public key, and a short ID; Hysteria 2 generally requires a server port, authentication details, and a TLS server name. If an older core does not recognize these fields, renaming the node will not fix the problem.

• When a subscription mainly contains Shadowsocks, VMess, and Trojan, the three core families overlap considerably in basic connection support.
• When a subscription includes VLESS Reality, Hysteria 2, or TUIC, confirm directly that the client includes mihomo.
• With WireGuard nodes, distinguish the proxy node type from a standalone WireGuard app running on the system; they use different configuration paths.
• Node support also depends on the client wrapper. Even when the core supports a feature, you may need to configure it through YAML if the graphical interface has no fields for it.

Rule capabilities: basic syntax is compatible, but extension fields are not universal

All three follow Clash’s top-to-bottom rule model, stopping at the first match. Common rules such as DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD, IP-CIDR, GEOIP, and the final fallback rule are broadly compatible. The major differences lie in rule sets, process matching, inbound conditions, and how geographic data is loaded.

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - DOMAIN-KEYWORD,video,Media
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Final

This configuration illustrates the general principles: place domain rules before rules that require IP resolution; connect directly to local network addresses; use no-resolve to prevent an IP-CIDR rule from actively triggering DNS resolution; and use MATCH at the end for connections that match nothing else. Some older configurations use FINAL; during migration, standardize it to the syntax supported by the target core.

RULE-SET and rule providers

Premium introduced rule-set capabilities to address the maintenance burden of very long rule lists. Meta and mihomo expanded the use of rule-providers, which can load domain, ipcidr, classical, and other behavior types from local files or remote URLs. Check not only the rule file contents but also whether behavior matches the format. If a domain list is declared as ipcidr, the core will not infer and correct it automatically.

rule-providers:
  private-domain:
    type: file
    behavior: domain
    path: ./rules/private-domain.yaml

rules:
  - RULE-SET,private-domain,DIRECT
  - MATCH,Final

Remote rule providers may also include url, interval, and a cache path. Update intervals are usually measured in seconds; for example, 86400 means 24 hours. More frequent updates are not necessarily better. Fetching a public geographic list once a day is usually sufficient, while frequent updates add startup work and network requests.

Process and inbound matching

mihomo supports richer rule conditions, including PROCESS-NAME, PROCESS-PATH, NETWORK, IN-PORT, SRC-IP-CIDR, and logical combinations. Process matching depends on operating-system permissions and implementation details, so availability differs across Android, Windows, and macOS. When mobile-system restrictions are significant, domain and IP rules are usually more reliable.

GEOSITE vs. GEOIP: similar names, different match targets

GEOIP matches the region associated with the destination IP. When a connection contains only a domain, the core may need to resolve it to an IP before determining the region. GEOSITE instead matches precompiled domain categories, such as search services, streaming platforms, or domain groups associated with a particular region. It is not a real-time lookup of website ownership and does not analyze page content.

The original Clash supported basic geographic matching such as GEOIP relatively early. Premium and later forks expanded the available data and rule formats. mihomo can work with GeoIP, GeoSite, and data files in different formats, but the file format, download path, and configuration keys must match the specific version. If the rules are present but the data files are missing, startup logs usually report a resource-loading failure.

rules:
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Final

The example first routes an advertising domain group by category, then sends commonly used mainland China domains directly, and finally uses GEOIP for connections whose IP addresses are already known. The order matters. If the broad GEOSITE,cn,DIRECT rule appears before a specific domain rule that needs the proxy, the specific rule may never be reached.

Common checks for geographic data

1. In the client’s “Settings” → “Core” or “About” section, confirm whether the active core is Premium, Meta, or mihomo.
2. Open the configuration directory and check that the GeoIP and GeoSite data files exist, with reasonable modification times.
3. In “Settings” → “Logs,” search for geo, rule, or provider to confirm that the files loaded successfully.
4. Test the target domain with a more specific DOMAIN or DOMAIN-SUFFIX rule to rule out bias in the geographic classification itself.
5. Check whether updating the client’s core also updated its geographic data. The two are often managed through separate controls.

TUN mode differences: coverage depends on the core, permissions, and system routes

The system proxy affects only applications that honor HTTP or SOCKS proxy settings. Games, command-line tools, some store apps, and software with its own network stack may bypass the system proxy. TUN mode uses a virtual network interface to capture more TCP and UDP traffic, making it useful on desktop and mobile devices that need unified routing.

The original foundation core focused mainly on proxy ports. Premium made TUN an important enhancement. mihomo retains and expands TUN configuration, with common fields including enable, stack, auto-route, auto-detect-interface, strict-route, and dns-hijack. Supported values may change between versions, so when migrating an old configuration, follow the errors reported by the current core.

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

auto-route automatically adds the required routes; auto-detect-interface attempts to identify the current outbound network interface; strict-route helps reduce traffic leaks around the tunnel; and dns-hijack hands specified DNS requests to the core. In the example, any:53 means capturing DNS traffic targeting port 53, but whether it fits your system depends on the local DNS setup, LAN devices, and other VPN software.

Choosing a common TUN stack

• system: Relies more heavily on the operating system’s network stack and is often faster directly; a good first option for desktop testing.
• gVisor: Uses a user-space network stack for some connections. Compatibility may differ, making it useful for comparison testing with specific UDP or application issues.
• mixed: Combines handling methods by traffic type. Availability and exact behavior depend on the mihomo version, so check startup logs after migrating an older configuration.

If the internet stops working after enabling TUN, that does not necessarily mean the core is unusable. Disable TUN first and confirm that a regular system proxy can connect. Then check administrator permissions, the virtual adapter, default routes, and DNS. On Windows, look for conflicts with other VPN virtual adapters; on macOS, verify system-extension or VPN permissions; on Android, make sure only one active VPN service is enabled.

DNS behavior differences: evaluate Fake-IP together with rules and TUN

Common DNS enhancement modes in Clash cores include fake-ip and redir-host. Fake-IP first returns a reserved address to the application, then restores the original domain during connection handling so domain rules can participate earlier. This can reduce repeated resolution in some situations, but it may affect device discovery, printers, game platforms, or corporate intranet domains that depend on real local-network addresses.

mihomo offers more ways to combine Fake-IP filtering, DNS routing, fallback resolution, and nameserver-policy. The more complex the configuration, the more clearly each DNS group’s purpose must be defined. Sending every domain to multiple upstream resolvers is not necessarily faster and can produce inconsistent results. On a home network, start with one primary resolver group, one direct-connection rule set, and only the Fake-IP exclusions you need.

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

The example listens for core DNS requests on port 1053 and uses 198.18.0.1/16 as the Fake-IP range. This range should not be mistaken for the real address of a proxy server. When logs show connections to 198.18.x.x, check the domain mapping before deciding that the destination is wrong.

Configuration compatibility: starting successfully is only the first step

Clash Meta and mihomo aim to preserve the Clash YAML structure, but compatibility is not bidirectional. A basic Clash configuration is usually easier for mihomo to read; a configuration using mihomo’s newer protocols, rule types, or extended DNS fields cannot be handed directly to the original Clash or Premium. Clients may also rewrite configurations when saving them, so distinguish between a subscription-generated configuration and a local override before editing by hand.

Migration checklist: Premium to mihomo

1. Record the old client’s mixed port, LAN access setting, operating mode, and current proxy-group selection.
2. Keep a copy of the original YAML, then import the subscription into the new client; do not overwrite your only configuration.
3. Leave TUN disabled at first and test whether local proxy ports such as 7890 connect normally.
4. Check the logs for deprecated fields, duplicate keys, failed rule-provider loads, and proxy-type errors.
5. Test DIRECT, REJECT, the node-selection group, and the automatic latency-test group one by one to confirm that rule actions behave as expected.
6. Finally enable TUN and DNS hijacking, then test the browser, command-line tools, games, and LAN devices separately.

Automatic latency-test groups can also produce different experiences. A common url-test periodically visits a specified URL and selects a node based on connection time. An interval of 300 means testing every 5 minutes. The lowest latency does not necessarily mean the highest download speed, because the test usually covers only DNS, TCP, TLS, or one small HTTP request—not long-lived bandwidth or congestion during peak hours.

proxy-groups:
  - name: Auto
    type: url-test
    proxies:
      - Node-A
      - Node-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

tolerance: 50 reduces frequent switching when candidate-node latency differences are small. For meetings, downloads, and continuous playback, a stable connection is usually more valuable than chasing a few milliseconds after every test. If node switching increases noticeably after a core migration, check the test URL, interval, and tolerance instead of changing only the rules.

Choosing a core by platform

Windows and macOS

For a new installation, prefer a client that clearly states it uses mihomo, displays the core version, and provides access to logs. Desktop systems often need TUN, process rules, and rule providers, areas where mihomo offers broader coverage. After installation, check “Settings” → “Core version,” “Configuration” → “Subscription,” and “Logs” to confirm that the interface version and active core are not maintained through separate update paths.

If an older client still uses Premium and the current subscription contains only basic protocols, it may continue working in the short term. But as the operating system is updated, geographic data expires, or the subscription adds newer node types, troubleshooting becomes increasingly difficult. Before migrating, preserve the rules and port settings, then restore them step by step in a mihomo client; this is usually more direct than adding new protocol support to an old core.

Android

Android clients capture traffic through the system VPN interface, so whether the app integrates mihomo matters more than desktop-style system proxy settings. Check the core documentation, per-app proxying, IPv6, UDP, and background execution policy. Android generally allows only one primary VPN service at a time, so Clash-style clients usually cannot capture traffic simultaneously with another VPN or DNS-filtering app.

iPhone and iPad

On iOS, users generally do not install a standalone core program named mihomo. Instead, they use a network tool that supports Clash configurations or a similar rule system. Implementations vary between apps, so a configuration-file extension alone cannot prove full compatibility. Before importing, check the app’s documented support for protocols, rule types, and TUN behavior, especially VLESS Reality, Hysteria 2, and complex rule providers.

Routers, NAS devices, and command-line environments

Routers and NAS devices place greater emphasis on CPU architecture, memory usage, startup method, and firewall integration. Match the downloaded core to the actual architecture, such as amd64 or arm64. After running it from the command line, use a version command or control interface to confirm the core identity, and check whether ports such as 7890, 9090, and 1053 conflict with existing services. On low-memory devices, limit the number of rule providers and their update frequency.

Final decision: choose by required features, not by guessing from the name or age

The original Clash established the configuration, proxy-group, and rule systems. Premium added important TUN and advanced rule capabilities of its time. Clash Meta carried on community development under the mihomo name. For most users, Meta and mihomo should not be treated as two mutually exclusive technologies; the key factors are the actual version built into the client and its configuration compatibility range.

When using only basic Shadowsocks, VMess, or Trojan nodes through the system proxy, an older core and mihomo may feel similar. If you need VLESS Reality, Hysteria 2, TUIC, full rule providers, GEOSITE, process rules, or finer TUN and DNS controls, mihomo is the better current baseline.

After choosing a core, validate it in this order: regular proxy connection → basic rules → DNS → TUN → extended rules. Check the logs after adding each layer, and record the ports, mode, and test results. This makes it much easier to identify whether a problem comes from the node, rules, DNS, or system routing when the client or subscription structure changes.