Clash Project Family Tree: How mihomo and GUI Clients Evolved After the Original Core Was Discontinued

Start by separating the three layers: core, GUI client, and subscription

Search for “Clash download” and you may find command-line tools, desktop installers, and mobile apps all in the same results. They belong to different layers: the core handles proxy traffic and routing, the GUI client manages and launches the core, and a subscription provides proxy nodes or configuration data. Keeping these layers separate helps you figure out whether switching clients can actually solve a problem.

• Core: Listens on proxy ports, opens outbound connections, matches rules, and handles DNS. mihomo belongs to this layer and can run on its own without a GUI.
• GUI client: Manages subscriptions, selects proxy groups, toggles the system proxy, installs background services, and displays core logs and connection history.
• Subscription: May provide only a list of proxy nodes, or a complete YAML configuration with DNS, rules, and proxy groups. A subscription service is not itself a core project.

For example, a client showing “Running” only means that some process or service has started; it doesn’t mean the nodes in your subscription are reachable. Likewise, browsing through 127.0.0.1:7890 doesn’t prove that TUN is routing traffic for the whole device. Identify which layer is causing the problem before deciding what to upgrade—it’s usually faster than reinstalling everything.

How the original Clash, Premium, Meta, and mihomo evolved

Original Clash: the starting point for its configuration model and rules

Dreamacro/clash was a key starting point for this ecosystem. Written in Go, the original open-source core was licensed under GPL-3.0. Many configuration concepts still in use came from it, including proxies, proxy-groups, and rules, as well as the top-to-bottom rule matching order. The original project stopped public maintenance around November 2023, but that didn’t make existing clients and tutorials disappear from the internet.

That’s why older tutorials can be misleading: their explanations of HTTP proxies and rule order may still apply, but installers, core capabilities, and system permission settings may have changed. When you see “Clash supports this field,” ask which core and which build the claim refers to.

Clash Premium is not a “paid premium version” of mihomo

Clash Premium was a separately distributed, closed-source core branch in the original ecosystem, with additional features such as TUN and scripting. Premium is the name of a branch, not a paid plan for a particular GUI client. Since its complete implementation was never open source, mihomo shouldn’t be portrayed as a simple continuation of publicly available Premium source code.

The original open-source Clash, Premium, and Meta have overlapping features, but their configurations are not interchangeable field for field. In particular, don’t assume legacy Premium script rules will keep working simply by swapping in the mihomo executable. During migration, rewrite them using rules and proxy groups supported by the target core.

Clash.Meta → mihomo: a name change and expanded capabilities

Clash.Meta was a community fork developed from Clash open-source code and was later renamed mihomo; its repository is MetaCubeX/mihomo. So references to the “Meta core” in older docs or “Clash Meta format” on subscription platforms often refer to today’s mihomo ecosystem—not a separate program you need to install alongside it.

mihomo retains Clash-style YAML configuration and a controller API, while continuing to expand protocol, rule, and DNS support. It’s licensed under GPL-3.0, but GUI clients that use mihomo may have different licenses. To assess software licensing, check the LICENSE for both the front end and the core rather than relying on the installer’s name.

Original Clash open-source code
  └─ Community fork → Clash.Meta
                       └─ Project renamed → mihomo

Clash Premium
  └─ Closed-source core branch in the original ecosystem; not the public source upstream of mihomo

Clash Verge Rev / FlClash and other GUI clients
  └─ Bundles, launches, and manages via the controller API → mihomo

Where Verge, FlClash, and Nyanpasu fit

These names mainly refer to GUI clients, not three entirely different proxy protocols. They may use the same type of core, but differ in subscription merging, background services, system proxy settings, and update policies. The sections below distinguish projects by their relationships—similar-looking interfaces don’t prove code inheritance.

Tell Clash Verge and Clash Verge Rev apart

“Verge” is often used as shorthand, but the original Clash Verge and the later Clash Verge Rev don’t share the same release source. Rev continues the original project line and uses the mihomo core. If you find installation instructions for an older version, check the full project name and release repository before following the screenshots. Menus may have the same names even when the background service implementation has changed.

Don’t assume FlClash and FlClashs are the same release

FlClash uses Flutter for its interface and supports desktop platforms and Android, among others. If you also see FlClashs in a download list, verify its maintainer, repository, package name, and documentation as a separate distribution. A one-letter difference isn’t enough to assume their release histories are interchangeable. The name shown on a site, the installed app name, and the upstream project name may not match exactly.

Check the actual release to see which cores Nyanpasu supports

Clash Nyanpasu is also a GUI management client. Releases from different periods may offer different core options, so don’t treat a core-switching menu in an old screenshot as a permanent feature list. When troubleshooting, note the client version, selected core, and core version. “I’m using Nyanpasu” alone isn’t enough to tell whether a configuration directive can be parsed.

Why the same subscription behaves differently in two clients

Subscription compatibility isn’t a single toggle. After importing the same URL, clients may send different request headers, prompting the server to return different content. Even when the response is identical, a client may apply local overrides before passing it to a different core version. Compare the effective configuration, not just the text in the subscription editor.

1. Check the response format: A full Clash YAML configuration typically includes fields such as proxies or proxy-providers. Content that contains only proxy links may not load directly as a complete configuration.
2. Check core support: Older cores aren’t guaranteed to support newer protocols or fields. If the logs show errors such as unsupported proxy type, check which core is running before repeatedly updating the same subscription.
3. Check local overrides: A client may override mixed-port, dns, tun, and external-controller. If the original configuration specifies port 7890, the final listening port may be different.
4. Check rule references: Proxy group names in rules must match the names actually defined. In MATCH,PROXY, PROXY is a referenced name—not a built-in group that every configuration includes.

Use commands to identify the core that’s actually running

Don’t guess from the installer’s filename. First, note the version shown in the client’s About or core information page; the exact menu name varies by release. To inspect a standalone core binary, run the command below from its directory. The filename shown is a common name for mihomo; adjust it if your local file is named differently.

.\mihomo.exe -v
.\mihomo.exe -t -d . -f .\config.yaml

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

-v prints the core version; -t checks the configuration; -d . sets the current directory as the working directory, making local data files easier to locate. Configurations that use remote rule sets or other resources may also depend on network access and file paths during checks. Passing a config test only means it passed the relevant checks; it doesn’t mean every node has connected.

If the client has a local controller API enabled, you can also query the version. The example below applies only on a local machine where the controller is at 127.0.0.1:9090 and no controller secret is configured. If a secret is set, add Bearer authentication as configured—don’t remove the secret just to run the example.

curl http://127.0.0.1:9090/version

Migrating from an old client: verify configuration, permissions, and traffic in three steps

Step 1: Back up inputs; don’t overwrite the entire directory

Keep your subscription URLs, local rules, proxy group selections, and override scripts. Import the subscription into the new client first, then migrate local changes one at a time. Don’t copy the old app’s entire data directory over the new app’s directory. Database schemas, path conventions, and script APIs may differ; similar YAML doesn’t mean the internal data is compatible.

Step 2: Test the explicit proxy before enabling TUN

Check the actual mixed-port in the new client. If it’s 7890, use the command below to test the explicit HTTP proxy connection first. The example domain demonstrates the command syntax; the response depends on your network and rules, so no specific “measured latency” is claimed.

curl -I --proxy http://127.0.0.1:7890 https://example.com

Once the explicit proxy works, test the system proxy and TUN. The system proxy mainly affects apps that follow system settings. TUN routes traffic through a virtual network interface and usually also requires a background service, administrator privileges, or platform VPN authorization. On Android, these clients generally use the system VPN API, which works differently from installing a service on desktop.

Step 3: Check DNS, UDP, and recovery from sleep

• DNS: Compare access in a regular browser with access inside apps to confirm that system DNS requests are handled as expected. Enabling TUN doesn’t automatically put all encrypted DNS under control.
• UDP: Voice calls, games, and QUIC also depend on node and protocol support; loading a web page doesn’t verify UDP connectivity.
• Recovery from sleep: After the device wakes and reconnects, check that the background core is still running and the system proxy port is still listening.
• Reset on exit: After closing the client, confirm that the system proxy settings are restored. If the system still points to a closed port 7890, it can look as if the entire network is down.

Choosing a client: check the maintenance chain, not just the name

Desktop users can compare how Clash Verge Rev, FlClash, and Clash Nyanpasu manage configurations, handle service permissions, and update the core. Android users should check system VPN authorization, background execution limits, and supported CPU architectures for the current release. iOS users should verify the configuration compatibility of the specific app; don’t assume it supports every feature available in desktop mihomo.

What matters is a traceable chain: installer source → client release → actual core version → effective configuration. Changing the interface alone may not fix a protocol compatibility issue, and upgrading the core alone may not clear stale system proxy settings. Document each layer and check the logs to turn the project family tree into a troubleshooting tool rather than a list of names.

For installation steps, see the cross-platform guide. If terms like TUN and proxy groups are unfamiliar, start with the glossary. Choose a download for your operating system and processor architecture, and check whether the client is still maintained.