Clash, mihomo & Client Lineage: An Open-Source Ecosystem Guide

First, separate the four layers: core, client, dashboard and configuration

On download pages, Clash can refer to a proxy core, a graphical app, or simply a configuration format compatible with Clash YAML. To understand how two projects relate, first identify the layer each one serves, then check the core name and version it actually runs. The presence or absence of “Clash” in an app's name alone tells you nothing definitive about protocol support, rule syntax or TUN capabilities.

For example, a graphical client opening successfully only confirms that its UI process is running. If the core rejects the configuration, the proxy may never start. Conversely, connections may continue through the proxy after you close the UI if its background service is still running. When troubleshooting, check the UI, core process and system proxy status separately.

Project lineage: Clash, Premium, Meta and mihomo

Original Clash: the starting point for rule-based proxy cores

Original Clash usually refers to the Dreamacro/clash project, a rule-based proxy core written in Go. It established the configuration structure common across this ecosystem, including proxies, proxy-groups, rules and dns. The original project stopped receiving public maintenance in 2023. Older binaries may still run, but that does not mean they will receive further protocol or system compatibility updates.

Clash Premium was a separate release line that added features such as TUN, rule providers and scripts. Those features should not be assumed to exist in every version of the original open-source core. Premium's enhancements were not fully open source, so “the Clash ecosystem includes open-source projects” and “every release branded Clash publishes all its source code” are two different claims.

Clash.Meta: a fork with expanded protocol and rule support

Clash.Meta is a fork that grew out of Clash, adding support for more protocols, DNS features, sniffing and TUN. In older guides, Meta, Clash Meta and the filename clash-meta usually refer to this fork. It is not a toggle in the original core or a client with a different skin.

mihomo: the name adopted by the Meta project

MetaCubeX renamed its Clash.Meta project mihomo. To identify the current project, check the MetaCubeX/mihomo repository, release notes and binary version. Older configurations, paths and client interfaces may still say Meta; an incomplete rename does not automatically mean a different core is in use.

Dreamacro/clash
├─ Original open-source core
├─ Clash Premium (historical enhanced release line)
└─ Clash.Meta (fork)
   └─ mihomo (the Meta project's later name)

Graphical client → launches, configures or bundles a core
Control panel   → connects to the core's control API

Where Verge Rev, ClashX and Nyanpasu fit

These names primarily refer to graphical clients. Clients handle interactions such as the system tray, subscription management and permission requests; the bundled core does most of the protocol and rule processing. App releases and core releases may follow separate version schedules, so include both when reporting an issue.

For forks with the same name, check the maintainer and release history

The original Clash Verge and Clash Verge Rev are not the same continuously released project. Rev is a separately maintained successor fork: the original project's discontinued status says nothing about Rev's status, and their version numbers should not be treated as one update sequence. Check each ClashX fork separately as well, especially its minimum OS version, processor architecture and core source.

For macOS installers, distinguish Apple Silicon arm64 builds from Intel x86_64 builds. Even if an app launches through a compatibility layer, check the architecture, install location and permissions of its background helper separately. iOS is subject to system network extension requirements, so desktop steps for installing helper services do not apply directly to iPhone.

“Clash configuration compatible” doesn't mean every field will work

Clash YAML is a shared foundation, not a guarantee that every core version supports the same features. Older cores may lack newer protocols, sniffing options or DNS fields. Some fields can prevent startup; others may simply not work as expected. Being able to import a subscription also doesn't prove that every proxy has passed a connection test.

Check three kinds of differences before migrating

1. Proxy protocols: Check each proxy's type and parameters. For proxies such as Hysteria2 and TUIC, verify support in your target mihomo version rather than assuming the original Clash core supports them.
2. Rules and resources: Check the format of rule-providers, its behavior and update path. If you use RULE-SET, confirm that the referenced resource name actually exists.
3. System-level routing: Check tun, DNS hijacking, routing and permission requirements. Passing configuration syntax checks and successfully installing system routes are separate acceptance steps.

The same subscription can produce different runtime configurations

After downloading a subscription, a client may append rules, rewrite ports or merge DNS settings. The original YAML saved on the configuration page may not be the file the core ultimately reads. If the same subscription works in another client, compare the runtime configurations first instead of importing it a dozen more times.

# 7890 is used in this example; it is not a standard port for every client
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

mixed-port: 7890 accepts HTTP and SOCKS proxy connections on the same port. It is not the control API port and does not enable TUN. If the client overrides the port, system proxy settings should point to the effective port; changing the number in the subscription alone may not change the runtime behavior. This snippet shows one field only, not a complete configuration with proxies and routing rules.

How to identify the active core instead of relying on the app title

Menu labels vary between client versions. Cross-check the core entry in the UI, startup records in the logs and the version output of the actual binary. The version number in the client's About page describes the app shell, not the core.

1. Record the app version: Open the client's About or version information page and note its full name, version and OS architecture. Avoid writing only “latest.”
2. Find the core information: In Settings, look for “Core” or a core management page. Record the selected core and update channel; don't mistake other cores in the download list for the one currently running.
3. Check the startup logs: Reload the configuration and check the logs to confirm the core started successfully and used the expected configuration path. Look for unknown proxy types, failed resource loads or port conflicts.
4. Check the runtime binary: For further troubleshooting, run the version command on the binary the client actually uses. A separately downloaded file with the same name only tells you that file's version.

# macOS / Linux: mihomo and config.yaml are in the current directory
./mihomo -v
./mihomo -t -f ./config.yaml

# Windows PowerShell: mihomo.exe and config.yaml are in the current directory
.\mihomo.exe -v
.\mihomo.exe -t -f .\config.yaml

-v displays the version, -t tests the configuration and -f specifies a configuration file. Passing a syntax test only means the configuration passed checks for that version; it does not prove remote proxies are reachable or that TUN permissions have been granted. If the configuration references local rules, certificates or provider files, make sure their paths and working directory match the actual environment.

Choose a client for the task: validate the config, then verify system-level routing

For newer protocols or mihomo-specific fields

Choose a client that explicitly documents mihomo support, then check the core version and field compatibility. Seeing a proxy name in the client doesn't prove the protocol is supported. A minimal validation path: pass a configuration test, select the intended policy group, establish a real connection, then check the matched rule and outbound name on the connections page.

For apps that need TUN because they ignore system proxy settings

Check whether the client provides a service or helper for your platform, and whether the OS has granted the required permissions. System proxy settings mainly affect apps that honor them; TUN handles traffic through a virtual network interface and routes, with coverage determined by routing rules, exclusions and platform limitations. TUN does not force all traffic through a proxy: the final outbound path still depends on rules, policy groups and direct-connection settings.

Migrating from an older client to a maintained project

1. Back up the subscription source, custom rules, DNS settings and policy group selections; don't rely on screenshots of the UI alone.
2. Import one configuration into the new client first and confirm it passes a configuration test before restoring overrides one by one.
3. Turn off the old client's system proxy and TUN, confirm its background service has stopped routing traffic, then enable the new client.
4. Check the proxy port, then test DNS resolution, rule matching and the destination website connection separately. If something fails, record which of these three layers is affected.
5. Remove old services and startup items only after validation, to prevent two programs from competing for the same listening port.

The most useful details to record when choosing or troubleshooting a client are the app name and version, core name and version, source of the runtime configuration, and system-level routing method. The app's interface determines how you operate it; the core determines protocol and rule support; OS permissions determine whether traffic can be routed as intended. Check these separately to work out whether the fix is to change clients, update the core or correct the configuration.

For a side-by-side look at platform support, see the client comparison. To understand the differences between policy groups, rules and DNS, see the quick reference. After installing a client, verify its actual settings; don't rely on menu screenshots from a different fork.