mihomo, Clash Meta, and Clash GUI Clients Explained: A Guide to the Open-Source Ecosystem

Start with three layers: proxy core, interface, and system integration

mihomo is a proxy core, and Clash Meta was a name used by the project before it became mihomo. Clients such as Clash Verge Rev combine a core with a graphical interface and system integration in an installable package.So “using Clash” doesn’t tell you which core is running, or which protocols, configuration fields, or system features it supports.

When troubleshooting, first identify the layer where the problem occurs. An unrecognized proxy protocol usually points to core capabilities or configuration syntax. An error when adding a subscription may occur during the client’s download or parsing step. If a site opens in your browser but not in other apps, check system proxy settings, the virtual network adapter, and routing.

Name changes: Clash, Clash.Meta, and mihomo

Original Clash: the starting point for its configuration and rule engine

The original Clash established a configuration structure widely used by tools in this ecosystem: proxies describes proxy nodes, proxy-groups organizes policies, and rules determines where connections go. Many later clients adopted the same YAML conventions, so products with different interfaces often share some configuration compatibility.

Also distinguish the original open-source core from the historical Clash Premium. Premium was a separate release line that offered some advanced features; its feature list should not be treated as the feature list for the original open-source core. The original project stopped receiving public maintenance in November 2023. Older software may still launch, but that doesn’t mean it will remain compatible with newer proxy protocols or configuration fields.

Clash.Meta: extending capabilities while maintaining compatibility

Clash.Meta emerged as a fork in the Clash ecosystem, expanding protocol support, DNS, and routing while retaining configuration compatibility. Older documentation, subscription options, and client menus often refer to a “Meta core.” This usually means the project line, not a standalone graphical client.

mihomo: the project’s later name

Clash.Meta was later renamed mihomo and continues to be developed by the MetaCubeX community. So “Clash Meta vs. mihomo—which is better?” usually compares neither two parallel new projects nor two distinct cores; it mixes a historical name with the project’s later name. Meta may still appear in old filenames, compatibility fields, or logs without meaning the core predates the rename.

Original Clash open-source core
└─ Clash.Meta fork
   └─ mihomo (later project name)

Desktop and mobile clients
└─ Integrate a core release line and provide their own interface and system integration

This diagram shows how the core projects evolved and how clients integrate them. It does not mean that every product with Clash in its name comes from the same team or shares the same open-source license. To verify a project’s identity, check its repository, release notes, and license file.

Desktop clients: which use mihomo and which are historical forks

Desktop clients typically handle both configuration management and core startup. The table below outlines the technical positioning of popular projects. Check the client’s version information and release notes to confirm which core is included in a specific installer.

Clash Verge Rev is an independently maintained successor, not simply the original Clash Verge with a new version number. When migrating, review service installation, configuration directories, and startup items rather than assuming the old client’s system integration will carry over.

Watch for similar names. FlClashs, listed on this site’s download page, and upstream FlClash in the table above should not be assumed to use the same release channel just because their names look alike. For derivative clients, verify the source repository, integrated core, and installer source separately. The same applies to other clients.

Mobile clients: Android VPN service and iOS Network Extension

Android: treat Clash for Android and Meta forks as separate projects

The original Clash for Android is no longer maintained. Android forks with Meta in their names follow a separate maintenance line, so the original app’s version history doesn’t reflect their update status. Cross-platform clients such as FlClash use a different interface implementation, but can also integrate mihomo on Android.

Android clients typically use the system VpnService to route device traffic. The VPN permission prompt shown on first use allows the client to create a local virtual network interface; it doesn’t mean Android has connected to a remote VPN provider. The destination is still determined by your nodes, proxy groups, and rules.

Per-app routing, background operation, and LAN sharing also depend on the client and operating-system restrictions. Even when a phone uses the same subscription as a desktop, check its app exclusions, battery optimization settings, and DNS configuration separately.

iOS: a similar interface doesn’t prove the same core is running

iOS clients generally use system mechanisms such as Network Extension to handle network traffic, and are subject to extension-environment restrictions. Being able to import a Clash subscription only shows that the client accepts that format or can convert it; it doesn’t prove that it runs the same mihomo version in full.

When choosing an iOS app, check its public documentation for the core’s source, supported protocols, and configuration fields. In particular, don’t assume desktop instructions for scripts, rule sets, DNS, or TUN options apply to its menus.

Configuration compatibility: subscriptions, rules, and client overrides

A subscription URL isn’t the final runtime configuration

A subscription may return a complete YAML file, a list of proxy nodes, or another format that the client must convert. A full configuration typically includes proxies, proxy-groups, and rules. A node provider, by contrast, usually supplies only nodes; the main configuration defines the proxy groups and rules.

Graphical clients may also merge local overrides, scripts, and interface settings into subscription content. To troubleshoot why the same subscription behaves differently in two clients, compare the final configuration passed to the core—not just the original subscription. When migrating, import the base subscription first, then restore overrides one at a time to make differences easier to isolate.

Similar rule syntax? Check the policy names too

This snippet illustrates rule order; it is not a complete, runnable configuration. It requires a policy named PROXY to exist in a proxy group. Here, PROXY is a custom name, not a built-in outbound option you can use without defining it.

rules:
  - DOMAIN-SUFFIX,example.org,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

Rules are matched in order, and the final MATCH catches connections that didn’t match any earlier rule. If you rename a proxy group to “Select Proxy” during migration but the rules still refer to PROXY, the configuration may fail validation. Similarly, every rule set referenced by RULE-SET must be defined in rule-providers.

TUN and Fake-IP solve different problems

TUN determines how traffic reaches the core; Fake-IP is a DNS mode that uses virtual IP addresses to help recover domain information. They’re often used together, but they aren’t the same setting. Enabling TUN won’t fix an invalid proxy group or guarantee that all DNS requests reach the core as expected.

The configuration fields tun, dns, protocol-specific options, and rule-set formats may all require particular versions. A newer core may accept fields that an older Clash or Premium release doesn’t recognize. If you encounter an unknown field or unsupported proxy type, check the version requirements first rather than deleting the field that triggered the error and assuming the migration succeeded.

Identify the running core: version, process, and local control API

The most useful record is “client name and version + actual core version + final configuration.” Menu locations vary between clients and versions, so look for the full version string under About, in the core management screen, or in startup logs. When reporting an issue, include the exact string instead of just saying “latest version.”

1. Check the runtime logs: Stop the connection and restart the core. Review the startup output to confirm the core name and configuration load results.
2. Check the actual binary: Run mihomo -v with a mihomo binary from a verified source. Use mihomo -t -f config.yaml to validate a specific configuration. The binary you test must be the same one the client actually launches.
3. Check the control API: If the local REST API is enabled, query /version. The control port and proxy port serve different purposes.

The examples below use explicit demo settings: mixed proxy port 7890 and control API address 127.0.0.1:9090. These aren’t universal client defaults; check the runtime configuration for actual values.

mixed-port: 7890
external-controller: 127.0.0.1:9090
secret: "local-demo-token-change-before-use"

Use the local command below to query the API. Replace the example token with your own value first, and never post your actual token in a public report.

curl --header "Authorization: Bearer local-demo-token-change-before-use" \
  http://127.0.0.1:9090/version

In Windows PowerShell, you can use curl.exe and enter the command on one line. A connection refusal usually means the port is wrong or the API isn’t listening; a 401 response means you should check the authentication token. Don’t expose the control API on all network interfaces just to check the version: it can manage configuration and connections, so restrict its access.

Client selection and migration checklist: check capabilities, then configure system integration

Use the steps below to choose a client. Separating interface preferences from runtime capabilities also makes it easier to retrace your steps if something goes wrong after changing settings.

1. Check the platform and architecture: Windows, macOS, Linux, Android, and iOS use different permission models. For Apple Silicon and Intel, don’t choose an installer based on file size alone.
2. Check core requirements: Confirm the target core version supports the subscription’s protocols, provider format, and DNS fields.
3. Back up configuration sources: Save subscription URLs, local rules, overrides, and scripts separately. Don’t upload configurations containing credentials to public locations.
4. Run only one traffic-routing client at a time: During migration, first turn off the old client’s system proxy or VPN/TUN to avoid port conflicts and competing routes.
5. Test the basic connection first: Import the subscription, choose a proxy group, then make a request in a browser and check the matched rule and actual outbound route in the connection list.
6. Restore advanced features last: Enable TUN, DNS overrides, per-app routing, and startup launch one at a time. Check the logs after each change.

In short, Clash was the starting point for this configuration ecosystem; Clash.Meta and mihomo are earlier and later names for the same project line; and graphical clients integrate cores with different operating systems. Understanding these three layers helps pinpoint whether a problem calls for a core update, a configuration change, or adjusted system permissions in the client.

For more on configuration options, see the User Guide. If proxy groups, Fake-IP, or TUN are unfamiliar, start with the Glossary.