Clash, Clash Meta, and mihomo: Open-Source Cores and Client Ecosystem Explained

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

Search for Clash and you’ll often find core repositories, desktop installers, mobile apps, and subscription guides side by side. They’re not the same thing. To make sense of the ecosystem, first understand what each project does—not just whether its name includes Clash.

The core processes network requests. The client provides buttons, lists, and settings screens. The configuration tells the core how to handle connections. Installing a client usually includes its bundled core, but that doesn’t make the client and core the same thing—or give them the same name.

How Clash, Clash Meta, and mihomo are related

Clash: the original project and a general term

Strictly speaking, Clash refers to the rule-based proxy core started by Dreamacro. It uses YAML configuration for proxy nodes, policy groups, DNS, and routing rules. GUI clients can use its control interface to show connections and switch policies. In everyday usage, “Clash” also refers broadly to this family of clients and configuration formats. So a tutorial that says “install Clash” may not mean running the original core directly.

The original open-source Clash core and the historical Clash Premium branch are also distinct. Premium was a separate historical release with a different feature set from the original open-source core. For older guides covering TUN, scripts, or rule providers, check which branch and version they refer to. A feature in one release shouldn’t be assumed to exist in every app called Clash.

Clash Meta: a core derived from Clash

Clash Meta is a community-developed fork of Clash. It retains much of the existing configuration structure while adding support for protocols, DNS, routing, and TUN features. Meta is the name of a core project—not a client edition you need to buy, or a sign that every app with “Meta” in its name comes from the same team.

mihomo: the name adopted by Clash Meta

Clash Meta was later renamed mihomo, and development has continued under the mihomo project. Older documentation, configuration comments, and some client interfaces may still say “Meta core.” If you see “Clash Meta support” and “uses mihomo,” check the actual core version. They usually refer to the same project lineage, not two services you need to install side by side.

• Project lineage: Original Clash → community fork Clash Meta → later renamed mihomo.
• Client relationship: Different GUI projects can bundle the same core while maintaining their own installers and user interfaces.
• Compatibility: Names can help identify a project, but support for specific fields depends on the core version actually running.

After changes to public maintenance of the original project and some clients in 2023, new community forks continued development. That doesn’t mean every Clash client stopped receiving updates, nor does it make a newer client the official successor under a renamed project. To verify who maintains a project, check its repository, release history, and maintainer notes.

Where Verge, Verge Rev, and FlClash fit

Clash Verge, Clash Verge Rev, and FlClash are all GUI clients. They let you import configurations, switch policies, and view logs, while the core they launch handles the actual proxy traffic.

Platform names in app titles don’t tell the whole story. For example, historical releases of Clash for Windows weren’t limited to Windows, while a desktop client may not offer an Android installer. Always check the operating systems and architectures listed for the specific project release you’re downloading.

Why do clients look different if they use the same mihomo core?

Because clients implement subscription storage, tray menus, launch-at-login, service installation, and configuration overrides themselves. Even with the same core version, two clients may use different config directories and subscription update methods. A path like “Settings” → “Update subscriptions” in one app won’t necessarily exist in another. If you can’t find the same menu, look for “Configuration,” “Profiles,” or the equivalent entry in that client’s documentation.

Will a configuration work across clients? Check the fields, then how it’s loaded

mihomo continues to use YAML structures common across the Clash ecosystem, but being able to import a configuration doesn’t mean every field will work. Basic proxy groups and domain rules are usually easier to migrate; newer protocols, DNS extensions, and TUN settings are more version-dependent. Older cores may reject newer configurations or ignore fields they don’t recognize. Check the logs to see what’s happening.

Identify the configuration structure by its basic fields

The example below shows only general settings and rules; it contains no usable proxy nodes. It sets the local mixed-proxy port to 7890 and restricts access to the local machine. This is not a default used by every client.

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

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

mixed-port provides a combined HTTP and SOCKS proxy listener; mode: rule routes traffic according to rules. The final rule in this example is a direct-connection fallback, so it won’t create a proxy connection on its own. If a real configuration references a policy group named Proxy, that group must also be defined in the configuration, with the exact same name and capitalization.

A full subscription and a proxy provider are different inputs

• Full configuration subscription: May include proxies, proxy-groups, rules, and DNS settings. It’s typically imported into the client’s configuration list.
• Proxy provider: Usually referenced by proxy-providers for use in an existing policy group. It may not be a complete, runnable configuration on its own.
• Single proxy link: Requires a client that can parse or convert it. Don’t paste an arbitrary share link directly at the top level of a YAML file.

If the same subscription works in client A but not B, first check whether B accepts the same input format, then compare core versions. A link downloading in a browser doesn’t prove it’s a complete configuration that the client can load directly.

System proxy and TUN: ways to route traffic into the core, not different cores

System proxy and TUN determine how app traffic reaches the core. Rule mode determines how the core handles it once it arrives. They’re separate settings: you can still use rule mode with TUN enabled, and you still need working nodes, DNS, and routing settings.

System proxy: direct apps that follow system settings to a local port

On Windows 11, for example, check proxy status under Settings → Network & internet → Proxy. If your client’s active mixed port is 7890, the system proxy should point to the matching local address and port—not to 7897 or another port left over from an older client. These are just example ports found in different configurations; don’t assume your current value based on a tutorial screenshot.

Not every app follows the system proxy. If a browser works but a command-line tool doesn’t, check that tool’s own proxy settings or environment variables before assuming the core has failed.

TUN: route traffic through a virtual network interface

TUN can capture more traffic, including from apps that ignore the system proxy, but it depends on system permissions, routing, DNS handling, and the existing network environment. A desktop client may require a service installation or elevated permissions. Android typically uses the system VPN interface and requires the user to approve access. Permission steps vary by platform and shouldn’t be copied from one to another.

• Before switching to TUN, make sure the regular proxy listener and node connection work. That way, you won’t have to troubleshoot two sets of problems at once.
• Note the status of other VPNs, virtual network adapters, and security software to help identify routing conflicts.
• UDP availability also depends on the node protocol, server, and outbound route. Enabling TUN doesn’t automatically add UDP support.

Choosing a client or migrating: five things to check

1. Check your platform and architecture. Confirm whether you’re using Windows, macOS, Linux, or Android, then check installer labels such as x64 or ARM64. On macOS, open the Apple menu → About This Mac to check your chip.
2. Verify the project. Check its full name, repository ownership, and release history. In particular, distinguish Clash Verge from Clash Verge Rev, and original mobile projects from community forks.
3. Record the client and core versions separately. Look in About, the core management screen, or startup logs; the location depends on the version. Updating a client doesn’t necessarily update its core.
4. Import the configuration, then test a single node. Confirm that the configuration loads, then check logs for unknown fields, missing policy groups, or port conflicts before testing an actual webpage.
5. Move automation settings last. Once the connection is stable, set up automatic updates, launch at startup, overrides, and TUN. Changing too many things at once makes issues harder to isolate.

If you run the core independently, use the command below in a terminal to check its version. The relevant binary must be in the current directory. GUI client users don’t need to install another copy of the core just to check its version.

# Linux / macOS: run from the directory containing the core binary
./mihomo -v

# Windows PowerShell: run from the directory containing the core binary
.\mihomo.exe -v

When troubleshooting, record the actual output instead of just writing “latest version.” Also note your OS version, configuration source type, connection method, and exact error. Before sharing logs, remove tokens from subscription URLs, node passwords, and control interface secrets.

FAQ: how to tell apart similar names

Do I need a client if I’ve installed mihomo?

Not necessarily. If you’re comfortable with the command line and configuration files, you can run the core directly and manage startup and system integration yourself. A GUI client is more convenient for importing subscriptions, switching policies, and viewing connections. These are two ways to use the core—not two steps you must install together.

If I switch to mihomo, will my old configuration definitely work?

Project lineage alone can’t guarantee compatibility. Check field support, relative file paths, rule file formats, client overrides, and permissions. After migrating, review the load logs and confirm that rules match as expected. A configuration appearing in a list doesn’t mean it loaded successfully.

If I see the old name “Meta,” do I need a new subscription?

The name change alone doesn’t require a new subscription. You only need to change the subscription output or configuration if its format, protocol, or fields aren’t compatible with your current core. Check the specific error first, and avoid exposing subscription credentials during unnecessary conversions.

How can I avoid confusing the client with the core?

Keep a short record of the client’s full name and version, the core name and version, configuration type, local proxy port, and whether system proxy or TUN is enabled. These five details make it easier to separate interface, configuration, and network integration issues when switching apps or checking logs.

For more background, use the glossary to look up terms like proxy groups and Fake-IP, or check specific parameters in the configuration reference. Choose a client based on platform support and maintenance status; troubleshoot compatibility by checking the core and actual configuration. Keeping those two questions separate makes the ecosystem much easier to navigate.