Clash Core, mihomo, and Clash Clients: The Open-Source Ecosystem Explained

Start with the three layers: core, client, and configuration

Clash isn't a single product name that describes every installer. The original Clash is a proxy core; mihomo is a core project that evolved from Clash Meta; and Clash Verge Rev and FlClash are GUI clients built around a core. To determine whether a feature is available, check the client version, the core actually running, and the configuration it loads.

The easiest way to tell them apart is by what each one does: the core parses YAML, handles connections, and applies DNS and routing rules; the client manages subscriptions, displays proxy groups, toggles the system proxy, and starts the core process or service; and the subscription provider supplies node parameters or a complete configuration. These components work together, but they aren't maintained by the same project.

Layer	Examples	Main responsibilities
Proxy core	Clash、mihomo	Listen on ports, parse configuration, match rules, and connect upstream
GUI client	Clash Verge Rev、FlClash	Import configuration, select policies, integrate with the system, and display logs
Configuration and subscription	YAML files, subscription URLs	Provide nodes, proxy groups, rules, and update access

How the projects evolved: original Clash, Clash Meta, and mihomo

The original core being discontinued doesn't mean the entire ecosystem stopped

The original Clash project stopped public maintenance around November 2023. The ecosystem also had Clash Premium, a closed-source branch whose feature set differed from the open-source original. Older guides that say “Clash supports TUN” often leave out the specific branch and platform requirements, so don't assume the instructions apply to every older core.

When maintenance ends, you can no longer count on the original project to deliver ongoing protocol support, system compatibility updates, or bug fixes. Older software may still run, but “starts successfully” and “suitable for everyday use as a network component” are not the same thing. When migrating, focus on current maintenance status rather than whether the installer name looks familiar.

Clash Meta is the former name of mihomo

Clash Meta began as a fork in the Clash ecosystem and was later renamed mihomo. “Meta core” in older documentation and “mihomo core” in newer documentation generally refer to the same project lineage, not two components you need to install side by side. The rename also doesn't mean every legacy field, binary name, and client label changed at once.

mihomo retains Clash-style YAML configuration and a control interface, while expanding protocol and routing support. The term “successor” describes the ecosystem's continued maintenance and development; it does not mean an official handoff from the original team, nor does it imply complete compatibility between old and new configurations.

Project evolution:
Original Clash ── forked development ── Clash Meta ── renamed ── mihomo

Integration:
Clash Verge Rev ── manages and invokes ── mihomo
FlClash         ── integrates and invokes ── mihomo

Configuration input:
Subscription or local YAML ── client processing ── runtime configuration ── loaded by core

This diagram shows how projects and components relate; it doesn't mean the clients share the same interface code. Even when two clients use similar cores, they may handle configuration merging, service management, and platform integration differently.

What clients do: the roles of Verge Rev and FlClash

Clash Verge Rev: desktop interface and system integration

Clash Verge Rev is a desktop client for Windows, macOS, and Linux that uses the mihomo core. Subscription lists, tray menus, proxy group selection, and connection history belong to the client interface; the running core determines which proxy a connection uses and whether a rule matches.

A client's “service mode” typically lets a background component manage the core or network features with the required permissions. It isn't a proxy protocol, and enabling it doesn't automatically send all traffic through the proxy. Traffic handling also depends on the system proxy, TUN, routing, and how each application connects.

FlClash: cross-platform interface and mobile integration

FlClash is a client project built with Flutter and powered by the mihomo core, with desktop and Android support. On Android, it routes traffic through the system VPN interface—a different approach from changing the system proxy on desktop. The start buttons may look similar, but each platform requires different system permissions.

If you see similar names such as FlClash and FlClashs, check each project's source, maintainers, and release history rather than assuming they're the same project. Verify platform support against that project's release list, too; don't assume a similarly named fork has the same features.

An old client name doesn't tell you which core it uses

Clash for Windows: No longer maintained. Historical installers may include different cores, so don't treat it as equivalent to a current mihomo client.
Clash for Android: The original project is no longer maintained. Android VPN permission only allows traffic to be routed into the app; it can't add protocol support missing from an outdated core.
Other desktop wrappers: Check the project's documentation for the core type, then verify which core version the current installer actually includes. A name containing Clash isn't enough.

Start with the client comparison, then go to the download page for your operating system. You need all three: a client that runs on your platform, a core that supports your configuration, and the right kind of system integration.

How YAML gets from a subscription to the core

A subscription URL is a configuration source, not a proxy protocol. It may return a complete YAML file, a list of nodes, or another format. Whether a client can import it directly depends on its supported input formats; whether the core can load it depends on whether the generated configuration uses supported fields and protocols.

Get the data: The client downloads a subscription or reads a local YAML file.
Process the configuration: The client may apply overrides, merges, scripts, or global settings to generate the runtime file.
Load the core: The core reads the final configuration, starts listeners, and initializes proxies, DNS, and rules.
Route traffic in: Applications connect to a proxy port, or an entry point such as TUN sends traffic to the core.
Apply routing rules: In rule mode, the core checks rules in order and handles each connection according to its target policy.

The minimal configuration below illustrates which component owns each field; it has no remote proxy nodes. All regular traffic ultimately goes direct, so it can't demonstrate that a remote proxy works. Ports 7890 and 9090 are examples, not fixed defaults for every client.

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

external-controller: 127.0.0.1:9090
secret: "local-doc-demo-rotate-before-use"

proxy-groups:
  - name: Route
    type: select
    proxies:
      - DIRECT
      - REJECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,Route

mixed-port is a combined HTTP and SOCKS proxy listener. Applications can send traffic into the core through this port.
external-controller is the listening address for the control API, used to query status and change selections. It is not a proxy port to enter in your browser settings.
proxy-groups defines proxy groups. The client displays the choices, while the core stores and applies the current selection.
rules defines the order in which rules are checked. The final MATCH rule handles connections that weren't matched earlier.

If the subscription specifies port 7890 but the client listens on a different port, check the client's global settings or overrides first. Troubleshoot the runtime configuration instead of repeatedly editing a subscription file that may be overwritten at the next update. See the YAML reference for field details.

What determines system proxy, TUN, and protocol support?

The system proxy is an application entry point, not a core upgrade

When the system proxy is enabled, only applications that honor the system proxy settings send requests to the specified port. Programs that connect directly, command-line tools that ignore the system proxy, and some game traffic may bypass it. Changing the GUI theme or importing the same subscription again usually won't change how an application connects.

TUN depends on core support, the client, and system permissions

TUN routes IP traffic through a virtual network interface. The core must support the feature; the client must also create the interface correctly, manage permissions and routes, and coordinate DNS. Windows service permissions, Linux network management privileges, and Android VPN approval are all platform requirements in this chain.

TUN doesn't mean “all connections use a remote node.” Once traffic enters the core, rules may still route it through DIRECT, and route exclusions or per-app routing settings can affect it too. Check both the traffic being captured and the resulting rule matches—not just whether the TUN toggle is on.

New protocols usually depend on the core; configuration options also depend on the client

Whether a node type works depends first on core support and correct node parameters. An older core may reject a newer protocol as an unsupported proxy type or fail to load the configuration. Updating the GUI client may also update its core, but client and core versions use separate numbering schemes.

Conversely, core support for a field doesn't guarantee that the client has added a corresponding option to its editor. Some features require editing YAML or adding an override. If the interface rewrites the configuration when saving, make sure it won't remove custom fields.

Choose and troubleshoot clients by checking each layer

If the same subscription works in another client, don't immediately blame the node provider. The clients may use different cores, overrides, or DNS settings—or may not even use the same traffic entry point. Compare them in this order to pinpoint the difference.

Note both versions: Record the client version and core version separately. Check the About screen, core management interface, or startup logs; menu names vary by release.
Check the load result: Look for configuration parse errors, unknown proxy types, or missing policy names first. Testing your exit IP is pointless until the configuration loads successfully.
Check the entry point: Confirm whether you're using the system proxy or TUN. For an explicit proxy test, use the actual listening port—not one copied from a guide.
Check the policy: Review the matched rule, proxy group, and final node in the connection logs. If a rule selects direct access, seeing your local IP as the exit address is expected.
Then compare DNS and network settings: Differences in DNS results, IPv6 routing, or upstream networks can affect access even when the configuration is identical.

For example, if the actual mixed port is 7890, specify the proxy explicitly in a terminal to rule out whether the application follows system proxy settings. On Windows, if curl resolves to a different command, use curl.exe.

curl --proxy http://127.0.0.1:7890 --head --max-time 15 https://example.com

This command checks only the result of one request sent through the specified HTTP proxy. It doesn't show that TUN is capturing other applications, nor does it prove that the request used a remote node. Check the core's connection logs as well; if the rule matched DIRECT, the request still went straight to its destination over your local network.

Migrate an old configuration: keep what you need and restore features step by step

When moving from an unmaintained client to a mihomo client, back up the original configuration and custom rules first, then use a valid subscription to establish a minimal working connection. Don't overwrite the new client's entire runtime directory or mix old service files with a new core binary.

Check protocol compatibility first: Make sure the subscription output targets the current core and that node names match the references in proxy groups.
Then migrate rules: Restore a few straightforward rules, check which ones match, then add rule sets and more complex routing.
Migrate DNS and TUN last: Both depend heavily on the operating system and local network, so don't copy the old settings blindly.
Avoid running two traffic handlers: Exit the old client while testing the new one, and make sure its service isn't still occupying proxy ports or managing a virtual interface.

Choosing within the ecosystem isn't about finding a replacement with exactly the same name. Separate the responsibilities: use core capabilities to assess protocol and configuration compatibility, client features to assess platform integration, and runtime configurations and logs to verify actual behavior. Once you understand these three layers, project renames, client forks, and configuration migrations all fit into the same troubleshooting process.