Start with the three layers: core, GUI client and config file

Search for “Clash download” and you’ll often find core binaries, desktop installers and mobile apps mixed together. They’re not the same thing. Once you separate these three layers, it’s much easier to troubleshoot version choices, config errors and migrations.

  • Core: Handles incoming connections, DNS lookups, rule matching and outbound connections. mihomo belongs to this layer and can run on its own, without a GUI.
  • GUI client: Handles subscription imports, proxy selection, logs and platform features such as system proxy settings and background services. Clash Verge Rev and FlClash are GUI clients and typically bundle a ready-to-use core.
  • Config file: Tells the core which ports to listen on, which proxies to use and how to route traffic. A client may also merge, override or generate config before launching the core.

For example, the “System Proxy” button usually changes your operating system’s proxy settings, while mixed-port: 7890 makes the core listen for both HTTP and SOCKS proxy connections. Even with the button enabled, apps that ignore system proxy settings may not send traffic through that port. These are two separate switches.

How the core evolved: Clash → Clash Meta → mihomo

Original Clash: the starting point for rule-based proxying

Original Clash is a Go-based rule proxy that established the YAML config structure common across this ecosystem, including proxies, proxy-groups and rules. Many later clients adopted these concepts, but sharing a config format doesn’t mean they come from the same development team.

Clash Premium also existed as a closed-source core branch that added features to the original Clash ecosystem. It should not be confused with the original open-source core. Older guides that say “Premium required” reflect a specific point in time; they’re not a reason to seek out an old Premium binary today.

Clash Meta: a core fork, not a GUI theme

Clash Meta is a core fork developed from Clash, with expanded support for protocols, DNS and rule processing. When older configs, subscription services or client settings refer to the “Meta core,” they usually mean this line of development—not a graphical theme called Meta.

mihomo: the project name that carries on the Meta lineage

Around late 2023, the Clash ecosystem saw the original project repository go offline, clients stop receiving updates and the community take up maintenance. Clash Meta was later renamed mihomo, and the project now lives under the MetaCubeX organization. In short, Clash Meta is the former name for this core lineage; mihomo is the name of its successor project.

A continued name doesn’t mean the binaries are interchangeable forever. Meta cores from years ago and current mihomo releases may differ in fields, protocols and defaults. When troubleshooting, note the exact version number instead of just saying “Meta.” And don’t describe mihomo as a new release from the original Clash team.

Client lineages: distinguish Clash Verge from Verge Rev

The table below describes project relationships, not the core version bundled with any specific installer. Publishers may update the core, add build options or change platform support. Check the release notes and runtime details for the version you installed.

Project Role and core lineage What to check
mihomo A proxy core in its own right, continuing the Clash Meta lineage Operating system, processor architecture, core version and config support
Clash Verge Original desktop GUI client. Historical releases offered Clash and Clash Meta core options; the original project is archived. Don’t treat an old feature list as current documentation for Verge Rev.
Clash Verge Rev Community-maintained continuation of the desktop client, using the mihomo core Background services, TUN permissions, subscription overrides and core update method
FlClash Cross-platform GUI client built with Flutter, using the mihomo core Platform support, VPN permissions on mobile and differences between builds
Clash for Windows Discontinued historical GUI client. Common later releases used Clash Premium. A name containing Clash doesn’t guarantee support for current mihomo fields.

Similar names? Check the repository and publisher

Clash Verge and Clash Verge Rev are separate release projects; the suffix matters. Make sure the installer filename, app name and project repository line up. If a site or package uses a name derived from FlClash, check whether it’s the upstream release, a repack or a modified fork. Similar icons aren’t proof.

If you need to use the same config on desktop and mobile, first check which core features both platforms support, then compare the interfaces. See the client comparison to choose a platform; go to the download page for installers. Don’t stick with a discontinued client just to follow an old guide.

Config compatibility: the same YAML doesn’t guarantee the same behavior

The running core determines which protocols and fields are supported

YAML is just a data format. A file that parses successfully may still contain unsupported proxy protocols or options. For example, a node with type: hysteria2 needs a core that supports that protocol. The fact that a client can import YAML doesn’t mean an old version of Clash or Premium can connect to it.

Even basic fields depend on their meaning and how they work together. mode: rule selects rule mode; rules are checked in order, and MATCH is typically the catch-all at the end. If a client override switches the mode to global, the subscription’s rules may remain in the config but won’t route traffic as intended.

A client may generate a separate runtime config

The original subscription, the content shown in the client’s editor and the config actually passed to the core may be three different files. Overrides, config merges and GUI switches can all change the result. If a YAML change has no effect, check whether the client provides a “runtime config,” “active config” or config-folder view. Names vary by client and version, so don’t assume another app uses the same menu.

This mihomo snippet illustrates a few config concepts; it isn’t a complete subscription. If your existing config already has any of these top-level fields, edit the existing field rather than pasting in a duplicate at the end.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

tun:
  enable: false
  • 7890 is an example port, not a fixed port for every client. Set your browser, terminal and system settings to the port the core actually listens on.
  • allow-lan: false means LAN proxy access isn’t enabled by this setting; it doesn’t replace your system firewall configuration.
  • tun.enable: false disables TUN in this config. If the client overrides the setting, check the effective value in the runtime config.
  • This snippet has no proxies, proxy groups or rules, so it can’t tell you whether a subscription will work.

Licensing: check the core and GUI separately

The original Clash open-source code, mihomo, Clash Verge Rev and FlClash are all associated with the GPL-3.0 license. That doesn’t make them one project, nor does it mean every third-party build has met its distribution obligations. Check the LICENSE file for the specific version to see which terms apply, including whether later license versions are permitted.

Personal use and redistribution have different requirements

  • Personal installation and use: You generally don’t need to publish your personal subscriptions, rules or proxy passwords just to run a client. Software licenses and personal config files are separate matters.
  • Modifying and redistributing: Follow the applicable license by providing the required source code, license text and notices. Keeping only the project name isn’t enough.
  • Bundling third-party components: Check the GUI, core, libraries and platform components separately. Closed-source Clash Premium doesn’t become GPL-licensed open-source code just because an open-source GUI launches it.

When reviewing a release, start by finding the source repository linked in the app’s About section or project documentation. Confirm the release tag, then read the license file at that tag. Brand authorization, trademark use and source-code licensing are separate issues, too. Commercial redistribution calls for a compliance review based on how the software is actually packaged.

Migration checklist: preserve current behavior before enabling new features

When moving from an older Clash client to a mihomo client, don’t change subscriptions, enable TUN, switch DNS modes and add overrides all at once. Too many variables make problems hard to isolate. Follow these steps to make it easier to roll back.

  1. Record your current setup. Note the client name and version, core name and version, OS version, and whether system proxy and TUN are enabled. Before exporting a config, check whether it contains a subscription token.
  2. Back up a working config. Keep the original subscription URL and local edits, and record any overrides separately. Copying only the client’s program folder may not be enough; user config can live elsewhere.
  3. Quit the old client. Make sure its process and background services no longer hold the proxy port. Two processes listening on 127.0.0.1:7890 will conflict, potentially causing startup failures or an unavailable proxy.
  4. Import, then check. Enable the target config in the new client and check the logs for unknown fields, unsupported proxy types or references to missing proxy groups.
  5. Test the explicit proxy first. Leave TUN off for now. Set apps to use the port configured in the new client, then test web access, DNS resolution and rule matching.
  6. Enable system-wide routing last. Turn on system proxy or TUN as needed, grant the required permissions, then test local network access, wake-from-sleep behavior and per-app routing. Change one thing at a time.

If the logs show address already in use, check for a port conflict first. For config parsing errors, check field names and indentation. If only one app is affected, check whether it uses the system proxy, its own DNS or a separate network stack. Don’t switch proxies just because a connection failed.

FAQ: core updates, subscription compatibility and what to choose first

Does updating the client automatically update mihomo?

Not always. A client may bundle its core with the installer or let you download a core separately. The app version shown in the interface isn’t the core version. After updating, check the core’s runtime information and, if needed, the startup logs. A “you’re up to date” message alone doesn’t confirm that the core was updated.

Can I use a subscription labeled Clash with mihomo?

Many common Clash YAML configs are a good starting point for migration, but check protocols, extended fields and client overrides. A subscription service may also return different content depending on the client identifier in the request. If the original URL returns a list of proxy URIs rather than a complete YAML file, make sure the new client supports that import format. Not every “subscription link” points to the same kind of file.

Why does the same mihomo core work on desktop but not on mobile?

Compare the runtime configs first, not just the subscription URLs. On mobile, check VPN authorization, per-app routing lists, background restrictions and conflicts with other VPNs. On desktop, check system proxy settings, firewall rules and service permissions. Matching protocol support rules out one kind of difference, not every difference along the network path.

So, should I choose a core or a client first?

List the protocols, platforms and traffic-routing method you need, then find a maintained client that supports them. For a GUI, choose one suited to your platform; for server deployment or automation, consider running mihomo directly. Check the actual core version, then import your config. Follow the setup guide for the full walkthrough, or see the troubleshooting guide to diagnose problems.