Clash Ecosystem Guide: The mihomo Core and GUI Clients

The three layers: core, client, and configuration

The names in the Clash ecosystem refer to different layers: mihomo is the core that handles network traffic; Clash Verge Rev and FlClash are clients that provide a user interface; and YAML is the configuration format for defining proxies, groups, and rules. Before choosing software, identify which layer a feature belongs to so you know whether to check the core documentation or the client settings.

A core can run without a desktop window—for example, it can read a YAML file and expose a local proxy port on a server. A client wraps tasks such as importing a config, starting the process, and changing system settings in buttons. Because the two are often installed together, users may mistake the client’s version number for the core’s.

From the original Clash to Clash Meta and mihomo

In November 2023, public repositories for the original Clash and several related projects were deleted, archived, or otherwise changed, disrupting the upstream maintenance chain. References to open-source Clash, Clash Premium, and GUI clients describe different releases: Clash Premium was a closed-source core branch with additional features, while Clash for Windows was a client.

Clash Meta was an open-source fork developed from Clash and later renamed mihomo. So the “Meta core” in older guides and the “mihomo core” in newer docs are part of the same project lineage, not unrelated configuration systems. Some app names, repository names, and subscription entry points still use Meta; an unchanged name does not tell you which core version is used internally.

Check configuration compatibility field by field

• Base structure: Fields such as proxies, proxy-groups, and rules retain the Clash-style structure, but that doesn’t mean every version supports every field within them.
• Newer protocols: Types such as type: vless or type: hysteria2 require support in the core actually in use. A client name containing Clash is no guarantee.
• Extended features: Sniffing, DNS policies, and TUN-related fields can change between versions. Check the documentation for the core you’re running.
• Other ecosystems: sing-box JSON is not Clash YAML. A similar-looking client interface does not mean the configuration files are interchangeable.

Calling mihomo a “successor” describes continuity in community use and feature development; it does not mean it is an official upgrade released by the original project. Switching a subscription URL also won’t give a legacy client support for protocols provided by a newer core.

What Verge Rev, FlClash, and Android clients do

This comparison focuses on each project’s role rather than presenting a static version number as a measure of its current release status. Check the project’s release notes to confirm whether an installable build is available for your platform and which core it includes. Different distribution channels for the same project may also update on different schedules.

Desktop clients: system integration makes the difference

Even with similar mihomo versions, Verge Rev and FlClash can behave differently. Startup on boot, tray menus, restoring the system proxy, service installation, config overrides, and error messages are mostly client-level features. Compare concrete behaviors—such as whether the proxy is restored when you quit or local rules survive a subscription update—not just the layout of the proxy list.

Android clients: VPN routing and background limits

Apps such as Clash Meta for Android typically route traffic through Android’s VPN interface, which requires user permission. This interface describes how the system routes traffic; it does not mean the subscription service uses a traditional VPN protocol. Android generally allows only one regular VPN service to be active at a time, so it may conflict with another VPN-based firewall or filtering app.

Android’s battery restrictions, background process management, and per-app routing also matter when choosing a client. A YAML config that works on desktop may need changes to its listen address, ports, or routing settings on a phone. Cross-platform support does not guarantee identical system behavior.

Traffic flow: system proxy, control API, and TUN

Understanding the traffic path is more useful for troubleshooting than memorizing app icons. A typical system proxy path is “app follows system proxy settings → local proxy listener → core matches rules → proxy or direct connection.” An app that ignores system proxy settings may never enter this path.

Three interfaces that serve different purposes

• Proxy listener: Accepts proxy requests from browsers, command-line tools, and other apps, for example at 127.0.0.1:7890.
• Control API: Lets a client or dashboard check status and switch policies, for example at 127.0.0.1:9090. It is not a proxy port for browser traffic.
• TUN virtual interface: Receives routed traffic at the system network layer. Its actual coverage depends on routing, exclusions, DNS, and permissions.

The snippet below illustrates the difference between proxy ports and the control interface; it is not a complete configuration and contains no proxies. Port numbers are examples, not defaults for every client. A GUI client may also rewrite these fields at startup.

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

mixed-port accepts both HTTP and SOCKS proxy requests on the same listener. mode: rule means traffic is handled according to rules; it does not make every program on the system use the proxy automatically. The control API provides administrative access, so keep it within a trusted network. If remote access is necessary, configure authentication and restrict network access.

From subscription to runtime config: what the client does

A successful subscription download only means the client retrieved remote content. It still needs to parse the format, apply local merges or overrides, generate a runtime config, and pass it to the core. The source subscription, the file shown in the client’s editor, and the file ultimately loaded by the core may differ.

Two kinds of remote updates to distinguish

1. Full configuration subscription: Remote YAML can include proxies, groups, and rules. How local changes are preserved during updates depends on the client’s config management.
2. Proxy providers: Remote resources referenced by proxy-providers mainly supply proxies. The outer config still needs to define groups and how to use those proxies.
3. Rule providers: rule-providers supply rule sets; they do not replace proxy subscriptions. Rules must also reference the rule sets.

For example, a group may refer to a proxy named work-exit, but if that name disappears after a subscription update, the config may fail to load or the selection may behave unexpectedly. That’s a broken config reference, not a rendering bug in the client window. Check the generated config and the core’s error log instead of repeatedly reinstalling the app.

When switching clients, prioritize saving your subscription URLs, local rules, and override logic—not just copying the app’s internal database. Script overrides in particular may work differently because clients expose different objects and execution flows. A script that runs in one client should not be assumed to work as a general mihomo core feature. See the YAML Configuration Handbook for field details.

Client selection and migration checklist

Start by considering your operating system, required protocols, and traffic-routing method. Desktop users who only need browser proxying can first test the system proxy path; for broader app coverage, check TUN and service permissions. Android users should first confirm that VPN permission, background operation, and per-app routing fit their needs.

1. Check your platform and architecture. Identify whether you’re using Windows, macOS, Linux, or Android, then match the installer to your architecture, such as x64 or ARM64. For Macs, distinguish Apple Silicon from Intel rather than choosing any file labeled macOS.
2. Record both versions. Check the client’s About screen, core settings, or startup logs to record the client version and mihomo version separately. Menu locations vary by client version, so use the interface you actually have.
3. Import first, then check the logs. Confirm that the YAML parses and that the proxies and groups are present before enabling the system proxy or TUN. This helps distinguish config errors from network issues.
4. Run only one routing setup at a time. During migration, turn off the old client’s system proxy, TUN, and background services before starting the new client to avoid port conflicts and routing issues.
5. Test real traffic. Check the connection view for the process, destination address, matched rule, and outbound policy. A successful proxy latency test only confirms that the test request worked; it doesn’t prove that every app’s traffic path is working.
6. Check what happens after an update. Update the subscription manually and confirm that local rules remain, group references are valid, and the runtime config uses the expected listener port.

If two clients use the same 7890 listener port, the one started later may report that the address is already in use. If the old client exits but the system still points to 127.0.0.1:7890, the browser may fail to connect. Neither issue directly indicates whether the remote proxy is online.

Common misconception: similar names don’t mean identical features

Do you need a GUI client if you have mihomo installed?

Not necessarily. Users comfortable with the command line, service management, and config files can run the core on its own. A GUI client is more convenient for tray controls, subscription management, and system settings integration. When both approaches use the same core, protocol support mainly depends on the core version, while system integration depends on the client.

Can you use an old Clash YAML file in a new client?

Many basic configs can be reused, but validate them before use. Check protocol types, external resource paths, rule target names, and any DNS or TUN settings injected by the client. A legacy file may parse successfully and still have network policies unsuitable for your current device.

Should you choose the interface or the core?

Start with the core to determine your protocol and rule requirements, then choose a client based on how you want to manage them. For a closer look at platform support, config overrides, background services, and update mechanisms, read the Client Comparison. If you’re new, follow the Quick Start Guide to import and test a config. Track the core, client, and configuration separately to make future upgrades and troubleshooting clearer.