Clash Core and GUI Projects: How the Original Core, Meta, mihomo, and Desktop Clients Fit Together

How the core, client, and configuration fit together

When choosing a Clash desktop client, distinguish three components: the core that handles connections, the GUI client that provides controls, and the configuration file that defines proxies and rules. Sharing the Clash name does not mean clients use the same core or support exactly the same configuration.

The core listens on proxy ports, parses configuration, matches rules, establishes outbound connections, and handles network functions such as DNS. The GUI client manages subscription imports, proxy group selection, system proxy settings, background services, and logs. The configuration file supplies the core with proxy nodes, groups, rules, and DNS settings to apply.

Layer	Examples	Primary role
Network core	Original Clash, mihomo	Parse YAML, match rules, and handle network connections
GUI client	Clash Verge Rev	Manage configuration, start the core, and provide desktop controls
Configuration	`config.yaml`, subscription response	Define proxies, proxy groups, DNS, and rules
Control interface	`external-controller`	Provide the GUI with proxy selection, connection history, logs, and other features

How the original Clash, Meta, and mihomo are related

Original Clash: where the ecosystem began

The original Clash generally refers to the open-source core from Dreamacro/Clash. Written in Go, it established a widely used YAML configuration format and control interface. The original project stopped public development in November 2023. Existing releases and configurations remain available, but old builds should not be mistaken for actively maintained versions that continue to receive fixes.

Historical Clash Premium is a separate distinction to keep in mind. It is not a blanket term for all open-source Clash cores, nor an older name for mihomo. Some features in older guides required Premium, so a configuration field alone does not prove that the original open-source core supports it.

Clash Meta: an extension of the original

Clash Meta developed from the original Clash codebase, adding capabilities for protocols, DNS, routing, and more. References in older documentation to the “Meta core” or “Clash.Meta” usually mean this project lineage, not a separate subscription format. When a subscription says “requires Meta,” it often means the configuration uses features not implemented in the older original core.

mihomo: the Meta project's successor name

Clash Meta was later renamed mihomo. Its commonly used repository path is MetaCubeX/mihomo. Meta and mihomo are therefore not unrelated cores that must be started in sequence. The old name may still appear in client menus, subscription notes, filenames, or guides; check the repository and version output to identify the project.

Core project evolution (simplified)
Dreamacro/Clash
└─ Clash.Meta (extension branch)
   └─ mihomo (successor name, MetaCubeX/mihomo)

Invocation relationship (not code inheritance)
GUI clients such as Clash Verge Rev
├─ Manage subscriptions and local configuration
├─ Start, stop, or reload mihomo
└─ Read status and switch proxies through the control interface

This diagram shows project evolution and how the components work together; it does not mean every feature maps directly across branches. To determine whether a configuration will work, check the fields and protocols supported by the current core version—not just whether the client name includes “Clash.”

How GUI clients such as Verge Rev use the core

Clash Verge Rev is a desktop GUI client built with Tauri and is a separate project from mihomo. Installers typically bundle a core. The client generates the runtime configuration, starts the core process, and uses the control interface to display proxy groups, connection history, and logs. Client and core versions have separate numbering, so upgrading one does not necessarily upgrade the other.

Import configuration: The client saves a subscription URL or local YAML file and reads its contents.
Prepare runtime settings: The client may adjust ports, DNS, and rules by applying overrides, merging configuration, or running scripts.
Start the core: The core reads the generated configuration, opens local listeners, and loads the rules.
Control from the GUI: The client uses the control interface to switch proxies, reload configuration, and display logs.
Integrate with the system: The client can set the system proxy or support TUN through services and permission management.

A GUI, a web dashboard, and a core are different things

A web control panel typically manages a running core through its control interface. It usually does not handle full desktop installation, startup on boot, or privileged services. Having a dashboard open does not mean a proxy core is running on the device. Conversely, a core can run from the command line without a desktop window.

Legacy clients also need to be evaluated separately. Clash for Windows, the original Clash Verge, and Clash Verge Rev are not three versions of the same project. Similar names do not imply the same maintainers, and using an open-source core does not automatically mean every part of the GUI client uses the same license.

Configuration compatibility: check these four areas

Most configurations use top-level structures such as proxies, proxy-groups, and rules, but being able to parse YAML does not mean a core can run every configuration. An older core may reject newer protocols, different rule syntax, or added DNS fields—or behave differently than expected.

Proxy types: Check the specific mihomo version for support for protocols such as VLESS, Hysteria2, and TUIC. Do not assume the original legacy core supports them.
Rules and rule providers: The format, behavior type, and file contents of rule-providers must match. A domain list cannot be used as a complete rule list as-is.
DNS settings: Check settings such as fake-ip, upstream resolvers, and routing against the current core documentation. Avoid copying entire sections from old guides.
Client overrides: If edits to the original subscription do not take effect, the final runtime configuration may be overriding them—or a subscription update may have replaced your changes.

Port example: do not confuse proxy and control ports

This configuration snippet illustrates the purpose of each setting. It is not a complete, standalone configuration or a guarantee of any client's default values. Here, 7890 is used for HTTP and SOCKS proxies, while 9090 is used for the control interface; they serve different purposes.

mixed-port: 7890
allow-lan: false
mode: rule
external-controller: 127.0.0.1:9090

Browsers and command-line tools should connect to the proxy port—not use 9090 as an internet proxy. Keep the control interface restricted to localhost. If remote access is required, configure authentication and access controls separately. Do not expose the interface to your LAN or the public internet just to make the GUI connect.

System proxy and TUN: check the client and core separately

The system proxy setting typically points the operating system to a local listening port. Browsers and apps that honor this setting send requests through the proxy, but not every app uses the system proxy. Rule mode determines how connections that reach the core are routed; it does not force every application to use it.

TUN captures traffic through a virtual network interface and routing, and also involves DNS, permissions, and the system's network environment. mihomo provides the core functionality; the client manages toggles, service installation, and permissions. A TUN button in the GUI alone does not confirm that the service, routes, and DNS are working correctly.

Symptom	Check first	Likely cause
Window opens, but the proxy port is not listening	Core startup logs, port conflicts	A running GUI process does not mean the core is running correctly
Browser works, but an app does not use the proxy	App proxy settings, connection history	The app may not honor the system proxy
Domain access fails after enabling TUN	DNS configuration, routing, service permissions	Do not assume the proxy node is at fault
Rules behave differently after switching clients	Core version, final configuration, override order	The same subscription may produce different runtime configurations

For your first test, use the system proxy. Confirm the subscription, proxy groups, and proxy port are working, then enable TUN if your apps require it. This separates connection issues from system-level traffic capture and avoids changing several variables at once.

How to choose a client and check its version

Record both versions before comparing features

In Clash Verge Rev, for example, check the client version under Settings → About. Then look in the core section of Settings or the startup logs to confirm the core name and version. The exact location varies by release; if there is no dedicated core version screen, check the logs and project documentation for that release. Record the full version numbers rather than simply writing “latest.”

If you have located the core executable actually in use, you can check its version in a terminal. The example below uses Windows PowerShell. Use the filename from the installed package; do not mistake the GUI client's main executable for the core.

# Run this from the directory containing the core executable
.\mihomo.exe -v

# Validate the YAML configuration you plan to use
.\mihomo.exe -t -f .\config.yaml

Configuration validation can catch syntax and some field errors, but it does not prove that a proxy node is reachable or that the system proxy or TUN is capturing traffic. If the configuration depends on relative paths, external rule providers, or provider files, validate it with the correct working directory and accompanying files.

Choose in order of use case

Everyday desktop use: Check your operating system and processor architecture first, then choose a maintained GUI client that clearly reports core status.
Using newer protocols: Confirm the mihomo version you need, then check which version the client actually bundles. Do not compare GUI features alone.
Need TUN: Check service installation, administrator permissions, and known network compatibility issues for your operating system. Make sure you can recover with TUN disabled.
Servers or automation: Run the core directly and manage configuration, processes, and the control interface independently. A full desktop GUI is not required.
Migrating a legacy configuration: First verify configuration parsing, proxy selection, and DNS in the new client; then migrate startup and system traffic capture settings.

When checking open-source information, review the licenses for the core and client repositories separately. mihomo is licensed under GPL-3.0; that does not replace checking the license for a specific GUI client, bundled components, or release notes. Match the project name, repository, client version, and core version.

A minimal post-migration checklist

After installing or switching clients, start with a small test using a configuration known to work. Do not immediately enable the system proxy, TUN, complex overrides, and automatic switching all at once. Add one setting at a time to make logs easier to interpret.

Confirm the core is running and that its listening port matches the one configured in the app—for example, 127.0.0.1:7890.
Confirm the subscription parsed successfully, the proxy group contains the expected node names, and no removed proxies are still referenced.
In rule mode, make a test request and check the matched rule and final outbound route in the connection history.
Check that local rules and overrides are present in the final runtime configuration. Then update the subscription and confirm your changes are still applied as expected.
Finally, check that settings persist after restarting the client and that the system proxy or TUN works when enabled.

For step-by-step installation and configuration import instructions, see the user guide. For port, subscription, or system traffic capture issues, visit the Help Center. If terms such as proxy groups and rule providers are unfamiliar, start with the glossary.