The Clash Project Family Explained: How Cores, GUI Clients, and Rule Sets Fit Together

The ecosystem map: four layers of projects

When researching Clash, you'll often see names like Clash, Clash Meta, mihomo, ClashX, Clash Verge, subconverter, and geoip all mixed together, and newcomers naturally assume they're competing pieces of software to compare against one another. In reality these projects sit at four distinct layers, each handling a different job, and together they form a complete rule-based routing setup.

The first layer is the core — the background process that actually handles network connections, executes proxy rules, and maintains connection pools. It has no graphical interface and only accepts configuration files and API calls. The second layer is the GUI client, which wraps the core into an application users can click through, handling subscription fetching, node switching, system proxy settings, and TUN adapter management. The third layer is rule sets and geo databases, which supply categorized lists of domains and IP ranges for the core to match against when routing traffic. The fourth layer is conversion and dashboard tools, which normalize subscriptions in different formats into configurations the core can read, or provide a web-based connection monitoring panel.

Once you understand how these four layers depend on each other, it becomes clear why the same computer might have both a client process and a separate core process running, and why swapping clients doesn't require re-downloading your rule set files.

The core's evolution: from the original Clash to mihomo

The core layer has seen the most change in the whole ecosystem, and understanding the timeline helps you decide which version to use today.

1. Original Clash

   Started by Dreamacro and written in Go, this original version laid the groundwork for the configuration file format, proxy groups, and rule-based routing model still in use today. This repository is now archived — no new features are merged and no new compatibility issues are fixed — but the configuration syntax it defined is still followed by every later fork.

2. Clash Premium

   Built on top of the original with additional closed-source features and more complete rule syntax, this was for a time the most feature-rich fork. Its update pace has also slowed considerably, and its protocol support has fallen behind newer transport methods.

3. Clash Meta

   Taken over by the community once the original stopped receiving updates, Clash Meta added support for Vision, Hysteria, TUN mode, and other new protocols and features. It was for a time the most actively updated fork, and a large number of GUI clients switched their underlying core to it.

4. mihomo

   The continuation of Clash Meta under a new name. Despite the repository migration and rename, the original team and community keep contributing code here — new protocol support, bug fixes, and adaptations to new OS versions all happen in this project. Most mainstream GUI clients today have already switched, or are in the process of switching, their underlying core to mihomo.

In other words, checking "which core a client uses" really means checking whether it's tied to a branch that has already stopped receiving updates, or to mihomo, which is still actively maintained. This directly determines whether newly introduced proxy protocols will work, and whether the app can still trigger the network extension permission correctly after a system update.

Which GUI clients are maintained, and which have stalled

Updates at the GUI client layer are the easiest to overlook, because the interface still opens as usual even when the underlying core hasn't been updated in a long time. Below is a snapshot of typical situations across platforms — check each project's release page for the current version.

iOS is a special case: platform policy prohibits distributing unsigned executable cores, so most iOS clients are independently built apps that follow a similar core design, distributed through the App Store. Their configuration syntax is compatible with the Clash family but isn't literally the same core codebase. When choosing an iOS client, focus on whether it supports standard subscription link formats and rule syntax, rather than worrying about whether it's "official."

A practical way to check for yourself is to open the client's About or Settings page and look for a "core version" label, then compare it against the latest version on mihomo's release page. A large gap usually means the client itself hasn't updated its dependencies in a while.

Rule sets and conversion tools: the missing pieces beyond the core

The core is only responsible for "executing rules" — where those rules come from is handled by a separate set of projects. Common rule set projects package frequently used domains and IP ranges worldwide into geosite and geoip format data files, categorized by region and service type. Once loaded, the core can reference a category name directly in its configuration instead of maintaining thousands of domain entries itself. These projects typically publish updates on a regular cycle, and their changelogs show exactly which categories were added or adjusted.

Conversion tools solve a different problem: subscription link formats vary across proxy providers — some are collections of standard protocol links, others are custom JSON. A conversion service translates between formats in the middle, turning a raw subscription into the YAML structure that Clash-family configs can read directly, while optionally inserting proxy groups and rule templates. When using a conversion service, stick to trusted sources and avoid submitting your subscription link to third-party sites of unknown origin.

Dashboard tools wrap the core's API in a web interface for viewing active connections, testing latency, and switching proxy groups. The "dashboard" page built into most GUI clients is essentially an embedded frontend from one of these open-source dashboard projects.

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

rule-providers:
  reject:
    type: http
    behavior: domain
    url: "rule set download URL"
    path: ./rules/reject.yaml
    interval: 86400

The snippet above shows how a rule set is referenced by the core: the core doesn't care how the rule data was actually generated — it simply pulls and loads it periodically from the address specified under rule-providers. This is exactly the benefit of a layered design: rule set projects can update independently, without waiting for a new core release.

How to choose: working backward through the dependency chain

Once you understand the layering above, choosing a setup becomes a three-step check rather than picking a project name that sounds familiar.

• Confirm your platform first. Available clients differ by operating system — iOS runs on its own App Store ecosystem, while desktop and Android offer more choice.
• Then confirm the core. Prefer clients whose underlying core is actively updated; check the core version number and last update date in the settings page or project documentation.
• Finally, confirm the rule source. If a client's built-in default rule set updates slowly, you can manually replace it with an actively maintained rule set URL in the configuration — no need to switch clients for this alone.

Worth noting: an archived core doesn't mean the software stops working immediately — already-released versions will keep running, they simply won't receive new protocol support or security fixes going forward. For everyday use, the safer approach is choosing a client whose underlying core is still actively maintained, so that when a new transport protocol appears or a system update breaks something, a fix arrives sooner, without you having to debug the core layer yourself.