Clash Open-Source Ecosystem Explained: Original Clash, Meta, mihomo, and Client Relationships

Start by separating cores, clients, and configuration files

The most common misunderstanding in the Clash ecosystem is treating every application with “Clash” in its name as one project. In practice, there are at least three layers: the core that handles traffic forwarding, the client that provides a graphical interface, and the YAML configuration maintained by a subscription service or user. These layers can work together, but their maintainers, version numbers, and compatibility ranges differ.

The core handles the actual traffic processing

The core reads the configuration, listens on local proxy ports, performs DNS resolution, matches rules, selects policy groups, and opens outbound connections. A classic setup often uses 7890 as the mixed HTTP and SOCKS port, with the external control interface commonly set to 127.0.0.1:9090. System proxy settings, the TUN virtual interface, and rule-based routing are ultimately executed by the core.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090
secret: change-this-secret

The client is the core’s control interface

Names such as FlClash, Clash Verge Rev, and ClashX usually refer to graphical clients. Clients import subscriptions, start or stop the core, change system proxy settings, display connection logs, and may also manage system services and TUN permissions. A client launching successfully does not mean the core is listening correctly; when checking runtime status, inspect the core log, port usage, and control interface together.

A subscription is not a client installer

A subscription link usually returns node and policy configuration. It does not install a core or automatically grant network permissions to the system. The same base subscription can be imported into different clients, but configurations using rule-providers, sniffer, Hysteria2, TUIC, or mihomo-specific DNS fields may not parse in the classic Clash core.

Original Clash: the ecosystem’s configuration and API foundation

The original Clash was started by Dreamacro and written in Go. It established the basic model still used by many clients today: proxy nodes go in proxies, policy groups in proxy-groups, and traffic is matched top to bottom through rules. A RESTful external control interface gives graphical clients access to status, connections, and policy switching.

Classic fields remain a shared language across the ecosystem, including mode: rule, mixed-port, dns.enable, and external-controller. That is why a configuration can still look much like original Clash even when mihomo is running. This reflects compatibility over time, not a shared maintenance line between the two cores.

What the end of original Clash maintenance means

The original project stopped public maintenance in 2023, with v1.18.0 commonly cited as the final archived release. This means new protocols, rule features, operating-system networking changes, and security fixes no longer flow into the original core. Legacy configurations on older devices may continue to work, but the core is not a sensible default for new deployments.

• Configuration layer: Basic proxies, policy groups, and domain rules remain highly portable.
• Core layer: Do not expect the original core to gain new protocol support or TUN improvements.
• Client layer: Software that still carries the Clash name may already have switched to mihomo—or may still bundle the old core.
• Subscription layer: If a service generates configuration with mihomo extensions, importing it into the classic core may immediately produce unknown-field errors.

Clash.Meta to mihomo: a rename followed by continued development

Clash.Meta began as an enhanced fork compatible with the Clash configuration ecosystem. It retained commonly used configuration structures and control APIs while adding more proxy protocols, rule-set support, DNS behavior, traffic sniffing, and TUN capabilities. After the original Clash stopped being maintained, Clash.Meta became the core path adopted by many newer clients.

Later, Clash.Meta was renamed mihomo, with the project maintained by the MetaCubeX community. The rename primarily affected the project name, binary name, image name, and documentation entry points; it did not completely replace the configuration system. “Meta core” in older resources and “mihomo core” in newer ones usually refer to different stages of the same evolutionary line.

What mihomo adds beyond the classic core

• More outbound protocols: Alongside classic types such as Shadowsocks, VMess, and Trojan, support continues to expand for VLESS, TUIC, Hysteria2, WireGuard, and more.
• Rule sets: rule-providers can load rule collections from local files or remote URLs, making large domain and IP rule sets easier to update separately.
• TUN improvements: A virtual network interface can take over traffic from applications that ignore system proxy settings, using a network stack suited to each platform.
• Traffic sniffing: Where conditions allow, the target domain can be recovered from TLS SNI or the HTTP Host, giving connections that expose only a destination IP a chance to match domain rules.
• DNS extensions: Support includes fake-ip, redir-host, domain-based resolver selection, rule-following behavior, and more granular nameserver policies.

These capabilities do not become active automatically just because a client using mihomo has been installed. TUN still requires system permissions and correct routing; sniffing requires sniffer.enable: true; and remote rule sets need a valid download URL and update interval. The core provides the capability; configuration determines whether it is enabled.

How to verify that mihomo is running

The most direct method is to check the client’s “About,” “Core,” or “Version” page. If the client does not show it, request /version while the external control interface is enabled. The command below targets control port 9090 and uses the control key configured earlier:

curl -H "Authorization: Bearer change-this-secret" \
  http://127.0.0.1:9090/version

The response usually includes a version string and implementation identifier. If the interface connection is refused, first confirm that the core is running and check whether external-controller is bound only to the local address. A 401 Unauthorized response means the interface is reachable, but the key in the request does not match.

Where FlClash, Verge, and ClashX fit

The most important differences between clients are not just visual. They include the core maintenance line they follow, how they manage system proxy settings and TUN, and whether configurations can be migrated unchanged. The project families are outlined below.

FlClash: a Flutter client powered by mihomo

FlClash is a cross-platform graphical client built with Flutter, with mihomo as its execution core. It handles subscription management, policy switching, connection views, log display, and system proxy settings, while mihomo handles protocol parsing and rule execution. When asking whether FlClash supports a particular proxy protocol, check both the integrated core version and the configuration fields required by that protocol.

FlClash’s cross-platform interface helps keep workflows consistent, but permission models still differ across Windows, macOS, Linux, and Android. On desktop systems, system proxy settings mainly affect applications that honor them; TUN mode creates a virtual network interface. On Android, traffic is taken over through the system VPN authorization prompt, so desktop permission steps cannot simply be applied to mobile.

Clash Verge and Clash Verge Rev: similar names, different maintenance lines

The original Clash Verge was a desktop graphical client widely used on Windows, macOS, and Linux. After the original project stopped being maintained, the community continuation Clash Verge Rev became the active fork. Searches for “Verge download” often show the old release, repackaged builds, and Rev versions together, so verify the full project name, release date, and core information.

Clash Verge Rev follows the mihomo route and suits users who need a desktop tray, system proxy, TUN, subscription management, and connection views. Data from the old Clash Verge can serve as a migration source, but do not assume its database, service installation method, and application settings are fully compatible. The safer approach is to export the subscription URL and any custom YAML, then import them again in the new client.

ClashX: the classic macOS client family

ClashX was an early and widely used macOS menu-bar client, with historical releases centered on the classic Clash core. Its configuration structure is closely tied to original Clash, but its main maintenance line has stalled. Basic HTTP, SOCKS, and conventional policy groups may still work in an old ClashX installation, but mihomo-only fields and newer protocols should not be assumed to be compatible.

Related names such as ClashX Pro and ClashX.Meta have also appeared, but they are not sequential versions from one repository. ClashX.Meta in particular represents the approach of pairing a macOS graphical interface with the Meta core. When you see “ClashX,” confirm the specific fork, last release date, CPU architecture, and actual core.

Clash for Windows: a common desktop client that is no longer maintained

Clash for Windows, often abbreviated as CFW, once supported Windows, macOS, and Linux. It is a graphical client, not the original Clash core project, and the client itself was not the unified upstream for the entire Clash open-source ecosystem. CFW stopped being maintained in 2023, so its old interface and bundled core no longer receive routine updates.

When migrating from CFW, preserve the subscription URL, custom configurations, override rules, and policy preferences—not the entire application directory. Features such as parsers, scripts, or client-specific overrides may not be recognized directly by another client; rewrite them using the target client’s override format or standard mihomo YAML.

Other mihomo clients still commonly seen

• Clash Nyanpasu: A desktop graphical client following the mihomo core route, with configuration, proxy, and connection management.
• Mihomo Party: A desktop client built around mihomo, with its name directly reflecting its core relationship.
• OpenClash: An OpenWrt management and integration solution that runs Clash.Meta or mihomo as a router-side service and uses firewall rules to take over LAN traffic.
• mihomo on the command line: Without a graphical client, YAML, system services, and external control panels can be combined into a server or gateway setup.

Maintenance status is more than “it still opens”

A client launching successfully only shows that the current installer can temporarily run on the current system. To assess maintenance status, check release history, commit activity, core upgrade speed, and platform compatibility records. After major operating-system updates, TUN drivers, network extensions, system-service permissions, and code signing may all change.

Four checks are more reliable than the project name

1. Check recent releases: Note the latest stable release date, rather than looking only at the repository’s most recent documentation edit.
2. Check the core version: A client update does not necessarily update mihomo at the same time; check the actual version shown on the About page or in the core log.
3. Check platform support: Confirm that the installer supports the current CPU architecture, such as Apple Silicon or Intel on macOS and x64 or arm64 on Windows.
4. Check issue handling: See whether maintainers still address installation failures, TUN startup problems, subscription parsing errors, and similar issues.

As of July 28, 2026, original Clash, the original Clash Verge, the main ClashX line, and Clash for Windows should be treated as unmaintained projects. mihomo remains an active core line, while FlClash and Clash Verge Rev are independent clients built around mihomo. Maintenance status can change, so check the project’s latest official release before installing.

Configuration migration: compatible base fields do not mean universal compatibility

Moving from a classic Clash client to a mihomo client is usually smooth because basic nodes, policy groups, and rule syntax have been retained. The reverse direction is more likely to fail: the classic core cannot recognize protocols and fields added later by mihomo. Before migrating, separate standard base configuration, core extensions, and client-specific settings.

What can usually be migrated directly

• Subscription URLs and local YAML files.
• Common proxies, proxy-groups, and rules.
• Basic rules such as DOMAIN, DOMAIN-SUFFIX, IP-CIDR, GEOIP, and MATCH.
• Common ports, the LAN access switch, and basic DNS addresses.

What needs to be checked again

• Client-specific overrides, scripts, configuration merging, and subscription preprocessing.
• The TUN network stack, automatic routing, strict routing, and interface names.
• GeoData mode, rule-set formats, and remote resource update URLs.
• The fake-ip filter list, split DNS behavior, and system hosts handling.
• Extended protocol fields for VLESS, Reality, TUIC, Hysteria2, and similar protocols.

After migration, keep mode: rule at first and verify subscription updates, node connectivity, DNS resolution, rule matches, and system proxy settings in sequence. Enable TUN last to avoid changing too many variables at once. If the log shows field not found, unsupported proxy type, or a YAML parsing error, investigate field compatibility before reinstalling the client.

Choosing a client: select the maintenance line before the interface

For a new installation, prioritize a client using the actively maintained mihomo core, receiving regular releases, and clearly supporting your current system. If you want a similar workflow across Windows, macOS, Linux, and Android, consider FlClash. For a desktop tray and system-service management, compare FlClash, Clash Verge Rev, Clash Nyanpasu, and Mihomo Party. For centralized LAN traffic control on an OpenWrt router, evaluate OpenClash and mihomo on the command line.

Even when an old client still runs, first record the subscription URL, export custom rules, and confirm the current ports. Common ports such as 7890, 7891, and 9090 may be occupied by an old process, preventing the new client’s core from starting. During migration, let only one client control system proxy settings or TUN to reduce proxy loops and default-route conflicts.

The ecosystem can be summarized clearly: original Clash established the configuration and control-interface foundations; Clash.Meta extended them while preserving compatibility; Clash.Meta was later renamed mihomo and continues to be maintained; FlClash and Clash Verge Rev are graphical clients that call mihomo; ClashX, the original Clash Verge, and CFW belong to client projects from different historical periods. Once these layers are understood, similar names are no longer an obstacle to choosing a client.