Clash Open-Source Ecosystem: Clients, Cores, and Maintained Forks

Separate the core, client, and subscription configuration

The Clash ecosystem can be understood as a three-layer structure. At the bottom is the core, which listens on proxy ports, establishes outbound connections, parses rules, selects policy groups, handles DNS, and takes over more system traffic when TUN mode is enabled. The core usually runs as a command-line program or background process, so it determines which configuration fields are supported.

The second layer is the client: the desktop or mobile app that users operate directly. It provides interfaces for importing configurations, updating subscriptions, selecting proxy nodes, switching the system proxy, viewing logs, and starting or stopping the core. Some clients also install services, request network permissions, create TUN devices, or configure startup items. The graphical interface can be updated independently of the bundled core, so check the client version and core version separately.

The third layer is the configuration. A subscription link usually returns content that is converted to or saved as a YAML configuration containing proxy nodes, proxy groups, rules, DNS settings, and TUN options. A subscription is neither a core nor a client. Whether the same subscription works across different apps depends on whether the corresponding core supports its node protocols, configuration fields, and rule syntax.

How the original Clash, Clash Meta, and mihomo relate

Original Clash: the ecosystem foundation and configuration starting point

The original Clash established the core workflow built around rule-driven proxying, policy groups, and YAML configuration. Concepts such as proxies, proxy-groups, rules, DIRECT, and MATCH in countless tutorials come from this foundational model. The original project later stopped receiving active maintenance, so it is best treated as a reference for understanding the configuration model and historical compatibility—not as the preferred core for a new installation.

A project reaching end of maintenance does not make existing configurations fail immediately. Many basic nodes, domain rules, and policy groups retain similar semantics, but newer protocol support, DNS fixes, operating-system adaptations, and TUN improvements generally appear in later maintained forks. With an old core, the biggest limitation is often not the interface but the loss of these later capabilities and fixes.

Clash Meta: a community fork focused on extensions

Clash Meta extended the original configuration model with broader protocol support, more rule capabilities, additional DNS options, and TUN-related features. It preserves much of the configuration structure familiar to Clash users while adding fields that exist only in the Meta line or work more completely there. When a subscription service labels a configuration “Meta,” it usually means the content may depend on these extensions and should not be assumed to run on an earlier original Clash core.

mihomo: the current project name after Meta

mihomo is the project name used after Clash Meta, and can be understood as a continuation of the same maintenance line rather than an unrelated fourth configuration system. Some client interfaces, subscription converters, and older documents still say “Clash Meta,” while others say “mihomo.” Check the core repository, executable details, and actual version instead of relying on a single label in the interface.

Choosing the mihomo route for a new environment generally provides an actively evolving core while retaining Clash-style rules and policy groups. Keep in mind that mihomo extensions may not work when taken back to an older core. Conversely, most well-formed basic Clash configurations are easier to migrate to mihomo, but DNS settings, scripts, rule providers, and proxy protocol fields should still be reviewed.

Popular graphical clients and cores are separate projects

Graphical clients are usually maintained by independent teams. They add desktop tray controls, subscription lists, system proxy settings, TUN switches, configuration overrides, and log panels around a core. A client may switch cores between releases or let users choose a core channel. When comparing clients, do not rely on screenshots alone; confirm how each one manages its core components.

Clash Verge Rev: desktop system integration

Clash Verge Rev is a popular desktop graphical client focused on subscription management, system proxy settings, service mode, and TUN controls on Windows, macOS, and Linux. It has an inheritance relationship with an earlier project of the same name, but should be identified by its currently maintained repository and release history. For desktop users who want the mihomo core, tray-based switching, and graphical rule inspection, this type of client is generally easier to manage day to day than running a command-line core directly.

Clash Nyanpasu: an independent interface for multi-platform management

Clash Nyanpasu is another community-maintained graphical front end that provides configuration management, subscription updates, and core controls. Its relationship with mihomo is that of a client managing a core, not another name for mihomo. Whether it suits your device depends on the platforms currently supported by the project, its installation methods, known issues, and core version.

Mobile clients: the permission model matters more than the name

Clash-style clients on mobile platforms such as Android generally use the system VPN interface to take over traffic and run a compatible core inside the app. Check the OS version, background execution limits, VPN permissions, per-app routing, and core maintenance status. The desktop concept of a “system proxy” does not transfer directly to mobile: mobile apps more often rely on a VPN service to carry traffic, and connections may stop when the system terminates the app in the background.

For older clients with Clash in their names, also check the latest release date and repository status. Name recognition is not a substitute for maintenance. A client may still open while remaining locked to an older core, unable to recognize protocol fields in newer subscriptions, or missing required compatibility work for newer operating-system versions.

Choose a maintained fork and client by use case

Everyday desktop use: prefer a maintained mihomo graphical client

For Windows, macOS, or Linux users whose main needs are importing subscriptions, switching policy groups, enabling the system proxy, and occasionally using TUN, start by evaluating graphical clients that use and actively release the mihomo core. This preserves familiar Clash configuration workflows while providing interface-based management of the core and system permissions. Before choosing, confirm the operating-system architecture, such as Windows x64 or ARM64 and Apple silicon or Intel on macOS.

Servers and gateways: direct core management offers more control

On Linux servers, transparent gateways, or in containers, a graphical interface is not required. Running the mihomo core directly with an explicit configuration path, log output, and service manager is usually easier to control and upgrade predictably. These environments also require you to handle listening addresses, firewalls, forwarding, DNS port conflicts, and process permissions yourself; do not copy a desktop client's one-click TUN setup.

Stable existing configuration: validate before migrating

If your current configuration has been stable for a long time, there is no need to rewrite every rule just because a project changed its name. A safer approach is to copy the configuration and test it in parallel with the new client or core, checking startup logs, DNS resolution, policy-group selection, and rule matches. Replace the old environment only after confirming that critical connections work normally.

Subscription includes new protocols or Meta fields: use mihomo compatibility as the baseline

When the subscription documentation explicitly requires Clash Meta or mihomo, or the configuration contains extensions that an older core cannot recognize, choose the corresponding core. Removing unknown fields by force can change node parameters, DNS routing, or rule behavior. A better approach is to ask the subscription provider for a format supported by the target client and keep the client core within the version range recommended by the project.

Migration checklist for moving from an old project to a mihomo client

1. Back up the original configuration and overrides.

   In addition to the main YAML file, save the subscription URL, global extension scripts, local rules, policy-group selections, and DNS overrides from the client. Some clients store these items in separate directories, so copying only the subscription file may not restore the full behavior.

2. Confirm the new client's actual core.

   Check its name and version on the About page, in core settings, or in the startup log. Do not infer the core from the installer name, and do not mistake the graphical client's version number for the mihomo version.

3. Import the base configuration and check its syntax first.

   YAML is sensitive to indentation, and list nesting and spaces after colons affect parsing. When startup fails, find the first configuration error in the log instead of repeatedly switching the system proxy or reinstalling.

4. Validate proxy mode and TUN mode separately.

   Start with the system proxy to test browsers and other programs that follow proxy settings, then enable TUN if needed. TUN involves a virtual network device, routing, and DNS takeover, so its troubleshooting scope is broader than ordinary system proxying. Changing both modes at once makes diagnosis harder.

5. Check actual rule and policy-group matches.

   Confirm that commonly used domains enter the expected policy group, LAN addresses remain reachable correctly, and the final rule handles unmatched traffic. For automatic policy groups, also check the test URL, probe interval, and node availability so switching behavior is not mistaken for a core failure.

6. Remove the old client only after validation is complete.

   Running two clients at the same time can cause port conflicts, system-proxy overrides, VPN conflicts, or duplicate route changes. During migration testing, ensure that only one program is responsible for taking over traffic, and record how to restore the old environment.

How to tell whether a Clash project is worth continuing to use

A project's maintenance status cannot be judged solely by whether its repository is still accessible. A more reliable approach is to check release history, commit activity, issue handling, and documentation updates together. A mature project does not need to commit code every day, but it should usually respond clearly to new-system compatibility, critical bugs, and dependency updates.

• Check the latest official release: Confirm that the installer matches the source tag, then read the release notes for core changes, system permissions, and migration requirements.
• Check how the core is updated: Find out whether the core ships with the client, updates online through the client, or must be replaced manually. An automatic client update does not necessarily update the core.
• Check supported platform boundaries: Confirm the current operating-system version and CPU architecture rather than relying only on labels such as Windows, macOS, Linux, or Android.
• Check the issue tracker: Pay particular attention to startup failures, TUN, DNS, sleep and wake recovery, and compatibility after system upgrades, as well as whether maintainers provide actionable conclusions.
• Check the source of configuration documentation: Client settings, mihomo fields, and subscription-service rules belong to different layers, so the documentation should match the component actually in use.
• Check the release source: Obtain installers from the release channels explicitly listed by the project to avoid confusing repackaged builds with the original project.

The final choice follows a clear path: new users should start with a maintained graphical client that includes or supports mihomo; existing users should confirm their current core and configuration dependencies before deciding whether to migrate; server users should build an auditable service, logging, and upgrade process around the mihomo core. This turns the problem of “too many project names” into three verifiable questions: core capabilities, client integration, and configuration compatibility.