When searching for Clash downloads or configuration guides, you will often come across Clash, Clash Meta, Mihomo, Clash Verge Rev, and FlClash. They are not different versions of one program, nor can they be reduced to “new” and “old” releases. These projects occupy different layers, including proxy kernels, GUI clients, configuration files, routing data, and subscription services. Their names are similar because they follow the same configuration and proxy-routing model.

To decide whether a project suits your device, do not judge it by whether its name contains Clash. A more reliable approach is to check which kernel it uses, which configuration fields it supports, whether it is still receiving releases, and whether its GUI can manage the system proxy, TUN, DNS, and configuration updates. Once these layers are separated, client migration, subscription imports, and configuration troubleshooting become much clearer.

Separate the kernel, client, and configuration data first

The Clash ecosystem can be divided into three main layers: the kernel that handles network connections, the client that provides controls and presentation, and the configuration data that describes nodes and routing logic. Most usage problems come from confusing these layers.

The kernel handles proxying and rule matching

The kernel is the execution engine of a proxy application. It opens local listening ports, connects to proxy servers, processes DNS settings, and selects proxy groups according to the rule list. Once the system proxy, browser, or another application hands traffic to a local port, the kernel—not the client’s button styling—determines where the connection goes.

The original Clash kernel was written in Go and established the YAML configuration structure widely used today, including concepts such as proxy nodes, proxy providers, proxy groups, and rules. After the original project stopped receiving active maintenance, development attention gradually shifted to maintained forks. Mihomo, which originated from the Clash.Meta fork, is now widely used. It preserves much of Clash’s configuration syntax while adding broader support for DNS, TUN, traffic sniffing, routing data, and protocol features.

The client provides the GUI and system integration

A client is usually a desktop or mobile GUI application. It downloads and switches configurations, displays node latency, controls the system proxy, requests the permissions required by TUN, starts the kernel, and presents logs. Clients can be built with different technologies—native UI toolkits, desktop shells based on web technologies, or cross-platform toolkits. That is separate from which proxy kernel they invoke internally.

Some clients bundle the kernel inside the installation package and update it together with the client. Others let you download, switch, or specify a kernel file separately. As a result, different distributions of a similarly named client may include different kernel versions. When configuration fields have no effect, first check the actual kernel name and version in About, kernel settings, or the startup log instead of relying only on the client name.

Configuration, subscriptions, and routing data are not the client itself

A YAML configuration describes ports, nodes, proxy groups, DNS, and rules. A subscription URL is an entry point for retrieving configuration data. It may return a complete Clash configuration or only a node list, which the client or a subscription-conversion service then uses to generate proxy groups. GeoIP, GeoSite, MMDB, and rule-set files are routing data. The kernel can read and update them, but they are not the kernel program itself.

This means replacing the GUI client does not necessarily invalidate an existing subscription, and replacing the kernel does not necessarily make the existing configuration unusable. Migration depends on the subscription output format, the extension fields used in the configuration, and the target kernel’s support for those fields.

How Clash, Clash Meta, and Mihomo are maintained

The original Clash established the configuration model and rule-routing approach. As the original project stopped publishing regular releases, community forks took on new protocol support, operating-system compatibility, and feature extensions. Clash.Meta became one of the most influential forks and later continued under the Mihomo name. In today’s ecosystem, “Clash configuration” often refers to a compatible format rather than a program running the original Clash kernel.

A fork is more than a project-name change. Mihomo extends the classic configuration model with additional capabilities, and releases from different periods may also change fields, defaults, and resource formats. A configuration that loads in Mihomo does not mean that an older Clash kernel can recognize every part of it. Complex TUN parameters, enhanced DNS behavior, traffic sniffing, GeoSite rules, and specific proxy protocols are especially likely to expose version boundaries.

The simplified configuration below is only intended to illustrate the layer relationships. After reading the file, the client starts the kernel; the kernel listens on a local port and passes connections to the proxy group and the final rule:

mixed-port: 7890
mode: rule

proxies: []

proxy-groups:
  - name: Node Selection
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,Node Selection

Real subscriptions usually add node definitions, proxy providers, DNS settings, rule providers, and more complete proxy groups. If you see “configuration parsing failed,” use the log to identify the specific field instead of deleting the entire configuration section. YAML is indentation-sensitive, and field support also depends on the kernel type and version. These are separate issues and should be assessed separately.

How to tell whether a project is still maintained

A project name containing Rev, Next, Meta, or Community does not by itself prove that the project is maintained. Check its latest stable release, release notes, commit activity, issue handling, and supported operating-system versions. For projects that only provide client installers, also verify whether the bundled kernel is being updated regularly.

  • Kernel version: Check the runtime log or the client’s About page to determine whether it is using Mihomo, the original Clash, or another compatible implementation.
  • Client version: The client and kernel generally use separate version numbers; one cannot substitute for the other.
  • Release history: A consistent stream of stable releases is more meaningful than a “new version” label in the project name.
  • Platform support: Check whether your Windows, macOS, Linux, or Android version is still within the supported range.
  • Update method: Confirm whether the kernel is updated with the client or must be updated separately in settings.

Where popular GUI clients fit in the ecosystem

Clash Verge Rev, Clash Nyanpasu, and FlClash are primarily GUI clients. They typically use Mihomo or another compatible kernel to provide configuration management and system integration. Their main differences are not the fundamentals of proxy routing, but platform support, UI implementation, kernel management, TUN permission handling, configuration overrides, and release cadence.

Desktop clients generally provide system-proxy controls, node selection, connection history, subscription updates, and latency testing. On Windows and macOS, they also need to handle startup behavior, restoring system-proxy settings, administrator permissions, and system-tray integration. Linux has a wider range of desktop environments, so the way system-proxy settings are written and tray support works can vary by distribution. The same client may therefore behave differently across desktop environments.

Android clients usually take over traffic through the system VPN interface, which is different from checking “system proxy” on a desktop. Support for per-app routing, persistent background operation, IPv6, and Private DNS depends on both the client implementation and system restrictions. The fact that desktop and mobile clients both use Mihomo does not mean their UI features or network behavior are identical.

Clash for Windows, once widely used, was a desktop GUI client rather than the open-source Clash kernel, and it is no longer maintained. Instructions written around its interface—such as specific menu names, configuration-override locations, or service-mode installation steps—should not be applied directly to current clients. Nodes and rules may still be transferable, but interface settings must be checked again in the new client.

What to check when choosing a client

Start by identifying the platform rather than comparing interfaces. For desktop systems, check the operating-system version and processor architecture, such as Windows x64, Windows ARM64, Apple silicon macOS, or Intel macOS. If the installer architecture does not match, the program may fail to launch or may run only through a compatibility layer.

Kernel and configuration compatibility

If your configuration contains Mihomo extension fields, prioritize a client that explicitly uses Mihomo and keeps its kernel reasonably up to date. After importing it, check the startup log to confirm that parsing succeeded, then test proxy-group switching and DNS. Seeing a node list does not prove that the entire configuration is active: the client may ignore unrecognized override options or continue using a cached configuration.

Subscription compatibility also requires distinguishing between a “complete configuration subscription” and a “node subscription.” A complete configuration usually already contains proxy groups and rules and can be used directly after import. A node subscription provides only server information, so the client or a local configuration must supply the groups and rules. Even when both links import successfully, their final routing behavior may differ substantially.

System proxy and TUN mode

The system proxy mainly affects applications that follow the operating system’s proxy settings, including most browsers and desktop applications. Terminal tools, games, virtual machines, and applications with their own network stack may bypass it. TUN mode creates a virtual network interface and captures a broader range of traffic, but it usually requires administrator permissions or system VPN authorization and introduces routing, DNS, and firewall compatibility concerns.

Therefore, TUN support should not be understood as merely having a switch in the interface. Check whether the client can install its service correctly, restore network settings on exit, and obtain the permissions allowed by the current operating system. If the network stops working after enabling TUN, disable TUN first to restore basic connectivity, then check kernel logs, DNS listening conflicts, routing loops, and other VPN software instead of repeatedly switching nodes.

Configuration management and update behavior

For long-term use, configuration management matters more than whether a one-time import succeeds. Check whether the client can set a subscription update interval, preserve local overrides, switch between multiple configurations, and continue using the last valid configuration when an update fails. Some clients regenerate the configuration after a subscription update, which can overwrite direct local edits. Put rule changes in the client’s supported override, merge, or scripting mechanism instead.

Client updates and kernel updates should also be treated separately. A successful GUI update does not necessarily mean that the kernel was updated; conversely, replacing the kernel alone can cause compatibility issues if the client’s management API changes. The stable approach is to use the update channels supported by the client and record the current client version, kernel version, and working configuration before upgrading.

Migrating from an old Clash client to a Mihomo client

Before migrating, preserve the original subscription URL, the YAML file currently in use, manual rules, and proxy-group selections. Copying only the client’s installation directory is unreliable because different programs store configurations in different locations, filenames, and database formats. The most portable migration assets are the subscription URL and a readable YAML configuration.

  1. Record the current setup: Save the old client and kernel versions, and note the local listening ports, system-proxy status, TUN status, and current proxy-group selection.
  2. Export the configuration: Save the complete YAML and separately document manually added rules, DNS settings, and configuration overrides.
  3. Install the target client: Choose an installer for the operating system and processor architecture, and leave TUN disabled on the first launch.
  4. Import the subscription or file: First verify that the configuration loads, then check that the nodes, proxy groups, and rules all appear correctly.
  5. Test basic proxying: Enable the system proxy and confirm that browser access, DNS resolution, and proxy-group switching work normally.
  6. Enable TUN if needed: Once basic proxying is stable, grant the required permissions and test terminal tools, games, or other applications that do not follow the system proxy.
  7. Remove old settings: After confirming that the new client works, disable startup and background services for the old client so the two programs do not compete for the same port.

The most common post-migration conflict is a duplicate local port. If the old program is still listening on 7890, 7891, or another configured port in the background, the new kernel will fail to start. Another common issue is that the system proxy still points to the old port; even with the new client running, the browser cannot connect. Use the listening address shown in the new client’s log and rewrite the system-proxy settings accordingly.

If the old configuration uses classic Clash fields and the target client uses Mihomo, you can usually import it first and then resolve differences based on the log. Migration in the opposite direction requires more care: Mihomo extension fields may not be recognized by an older kernel. When an unknown field appears, determine what it controls and then use an equivalent form supported by the target kernel rather than deleting it mechanically.

Use logs to confirm what is actually running

A client may retain Clash in its name, but the startup log usually provides more direct evidence. During troubleshooting, look for the kernel name, version number, configuration-file path, local listening port, external control port, TUN initialization result, and configuration parsing errors. The client version in the log identifies the GUI program; the kernel version determines actual rule and protocol capabilities.

You can also inspect the process list to see which executable is actually running. Many clients start one GUI process and one kernel process; in service mode, the kernel may instead be managed by the operating system service manager. Do not manually start a second copy of the same kernel while the client is running, or you may create listening-port conflicts, configuration-file contention, or inconsistent system-proxy state.

When nodes connect but routing does not behave as expected, inspect the destination domain, matched rule, and final proxy group in the connection log. If the log shows only IP addresses, the cause may be the DNS resolution method or traffic-sniffing settings. If everything consistently matches MATCH, check rule order and rule-set loading. Rules are evaluated from top to bottom, and the first match wins; group names in the client interface only display the relationships defined by the configuration.

Project selection guide

Clash is the starting point of the ecosystem and the name of its configuration model. Mihomo is the actively maintained compatible kernel descended from Clash.Meta. Clash Verge Rev, Clash Nyanpasu, and FlClash are GUI clients that invoke a kernel and integrate with the operating system. Subscriptions, YAML configurations, GeoIP, GeoSite, and rule sets belong to the data layer. They can be used across clients, but compatibility depends on the kernel version and configuration extensions.

When choosing a project, confirm the platform and architecture, the client’s maintenance status, the kernel type, configuration compatibility, and system-proxy or TUN requirements in that order. When migrating from an older client, preserve the subscription and readable configuration, then use the logs to verify the kernel actually running. Separating the interface, kernel, and data layers prevents wrong downloads, incompatible configurations, and misguided troubleshooting caused by similar names.