Clash, mihomo, and Clash Verge Rev Explained: Kernels, Clients, and Project History

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

Search for a Clash desktop client and you’ll often see Clash, Clash Meta, mihomo, Clash Verge Rev, and Clash for Windows in the results. These names don’t all refer to the same thing: some are cores that handle network connections, some are clients with windows and tray menus, and others describe configuration formats. Knowing the difference helps you choose what to download and where to look when something goes wrong.

• Core: Reads the configuration, listens on local proxy ports, and handles DNS resolution, rule matching, policy-based routing, and protocol connections. It can run from the command line without a graphical interface.
• Graphical client: Handles subscription imports, configuration switching, system proxy settings, core process management, and log display, as well as some system integrations that require elevated permissions.
• Configuration and subscriptions: Provide the core with proxies, policy groups, routing rules, and DNS settings. A subscription is one way to obtain configuration or proxy data; it is neither a client nor an indication of which core is in use.

For example, when a browser sends a request to 127.0.0.1:7890, the core receives it and routes it according to the rules. Clicking the “System Proxy” toggle in the app changes the operating system’s proxy settings. 7890 is just a common example; check the settings of the client you’re actually running for the correct port.

Project history: original Clash, Clash Meta, and mihomo

Original Clash and Clash Premium

Original Clash usually refers to the Go-based proxy core from the Dreamacro/Clash project. Its ecosystem popularized YAML configuration, policy groups, rule lists, and a control API. Many clients that support these interfaces are commonly called Clash clients. The original project stopped receiving public maintenance in November 2023, so its old version numbers shouldn’t be mistaken for a product line that’s still being updated.

Clash Premium also existed as a separate edition, with a feature set that differed from the open-source version. Premium once offered additional capabilities such as TUN and rule providers. When reading older guides, treat claims like “Premium only” in the context of the core version at the time. They don’t prove that current mihomo lacks the feature, nor that older Clash versions support it.

Clash Meta continued under the name mihomo

Clash Meta is a core fork that extended the Clash codebase and later continued under the name mihomo. Its repository is MetaCubeX/mihomo. In many guides, “Meta core” and “mihomo core” refer to the same development line—not two proxy programs you need to install side by side.

mihomo retains many Clash configuration conventions while adding and changing support for protocols, DNS, rules, and TUN. Compatibility isn’t a guarantee that every configuration works across cores: older cores may not recognize newer fields, and some protocols or rule behaviors may only be supported in certain versions. Check the target core’s documentation, release notes, and startup logs rather than relying on whether the filename contains “Clash.”

Original Clash ── fork and extension ── Clash Meta → mihomo
                                                  ↑
                                      Used by Clash Verge Rev

Original Clash Verge ── client fork ── Clash Verge Rev

This diagram shows the separate code and feature lineages. Clash Verge Rev’s client lineage comes from Clash Verge; it isn’t mihomo renamed and wrapped in a window. mihomo and the client also have separate version numbers and release schedules.

Clash Verge Rev, Clash for Windows, and other clients compared

Clash Verge Rev continues the Clash Verge client line and uses mihomo to handle proxy traffic. Its main advantage is desktop management: core settings, policy group selection, and system integration are brought together in one window. Being free, open source, and cross-platform are project attributes, but you should still check operating system versions, processor architecture, and the specific features you need.

Clash for Windows is a legacy client that is no longer maintained. Despite Windows in its name, its historical releases weren’t limited to Windows; more importantly, it isn’t a generic name for every Clash desktop client. In older guides, the General, Profiles, and Proxies pages roughly correspond to general settings, configuration management, and proxy policies. Other clients don’t have to use the same menus.

The client version isn’t the core version

When troubleshooting, record at least three things: the client name and version, the core name and version, and your operating system and architecture. Look under Settings for About or version information, then check the core settings or startup logs; menu labels vary by release. “Clash is updated” isn’t enough to tell whether the update changed the interface, the core, or just refreshed a subscription.

Do subscriptions work across clients? Check the configuration passed to the core

A “Clash subscription” might return a complete YAML configuration, just a list of proxies, or even a login page if the link has expired. Saving a link in a client doesn’t mean the core has accepted its contents. A complete configuration usually includes fields such as proxies, proxy-groups, and rules. Files referenced through proxy-providers don’t need to contain the full configuration structure.

1. First, identify the subscription format. If your provider offers multiple formats, choose one compatible with the target core. If the browser displays Base64 text or an HTML page, don’t treat it as a complete YAML configuration.
2. Next, check protocols and fields. Older cores may fail to parse a subscription that uses newer protocols, DNS fields, or mihomo-specific rules—or may only fail when connecting.
3. Finally, inspect the client’s merged configuration. Overrides, configuration merges, or scripts can change ports, DNS settings, and rules. A valid original subscription doesn’t guarantee the final running configuration is unchanged.

For errors like unsupported proxy type, first check the proxy type and whether the core supports it. For YAML parsing errors, check indentation and file format. Switching clients blindly may just hand the same invalid configuration to a different interface.

Who handles ports, the system proxy, and TUN?

Understand the local proxy endpoint with a minimal configuration

This minimal configuration illustrates how the fields work together. It has no remote proxies, so all matching traffic goes directly to its destination. It isn’t a proxy setup to use instead of a subscription, and you shouldn’t overwrite a configuration you’re already using with it.

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

rules:
  - MATCH,DIRECT

• mixed-port: 7890: Lets the core accept both HTTP and SOCKS proxy connections on the same port. The address is usually 127.0.0.1:7890.
• allow-lan: false: Keeps other devices on your local network from using this proxy endpoint. This is separate from allowing apps on your own device to use the proxy.
• mode: rule: Chooses a policy based on matching rules. Changing the mode doesn’t create remote proxies.
• MATCH,DIRECT: Sends traffic that doesn’t match another rule directly to its destination. Real-world subscriptions usually route some requests through policy groups, which then select a proxy.

The system proxy setting won’t route every app

When you enable “System Proxy,” the client usually points the operating system’s HTTP proxy setting to the core’s local endpoint. Only apps that follow the system proxy setting use it; programs that manage their own network connections, some games, and certain UDP traffic may not. A listening port, an enabled system proxy, and a particular app using the proxy are three separate things to verify.

TUN mode routes traffic into the core through a virtual network interface and routing settings; the client manages permissions, services, and the toggle. It may require administrator privileges or an installed service component. TUN isn’t another name for “Global mode”: TUN determines how traffic enters the core, while Rule and Global modes determine how it’s routed afterward. You can configure them separately.

When TUN isn’t working, check the client’s service status, core startup logs, DNS, and routing settings. Replacing a core file with another one that has the same name may not fix a permissions or virtual network adapter problem—and could break compatibility between the client and core.

Choose or migrate a client: four checks

1. Start with your operating system and architecture. Windows commonly comes in x64 and ARM64 versions; for macOS, check whether your Mac has Apple silicon or an Intel processor. Confirm this in system information before choosing an installer. Don’t download based only on Windows or macOS in the filename.
2. Then choose how you’ll use it. Choose a graphical client for a system tray, configuration management, and a system proxy toggle. Run mihomo directly only if you’re using a server or an environment with existing process management.
3. Check maintenance and dependencies. Review the client’s recent release notes and bundled core information. Make sure it supports the protocols, TUN, and DNS features you need. A newer client doesn’t guarantee its bundled core will always be up to date.
4. Enable only one client at a time during migration. Back up your existing configuration, quit the old client, and turn off its system proxy and TUN before launching the new one. This helps prevent port and routing conflicts.

After importing, verify the connection path

Enable the intended configuration on the configuration page, confirm the selected policy group on the proxies page, and check the logs for port conflicts or parsing errors. If the mixed port is 7890, you can explicitly set the HTTP proxy endpoint in a Windows terminal with this command:

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com

This command doesn’t depend on whether your browser reads the system proxy setting, but the destination site must still be reachable. Response headers only show that this request went through the specified endpoint; they don’t prove it used a remote proxy. Check the client’s connections page for the destination domain, matched rule, and selected policy chain. If it can’t connect to the local port, check the port and core status before replacing the subscription.

The choice boils down to two points: for everyday desktop use, focus on the client’s system integration and maintenance status; for configuration features and network behavior, check the core that’s actually running. Track the interface name separately from the core’s capabilities to make guides, upgrades, and troubleshooting easier to follow. For configuration details, see our Advanced Configuration guide. If you’re new, follow the Getting Started guide to import a configuration and set up the system proxy.