Clash, mihomo, and Verge Explained: A Guide to the Open-Source Ecosystem

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

The most effective way to understand the Clash ecosystem is not to memorize a list of similar names, but to break the software into three layers. The bottom layer is the proxy core, which reads YAML configuration, establishes proxy connections, matches rules, performs DNS lookups, and intercepts system traffic. The middle layer is the graphical client, which handles subscription management, tray menus, system proxy toggles, log viewing, and updates. The top layer is the configuration and subscription, containing proxies, proxy groups, rules, and DNS parameters.

The original Clash and mihomo belong to the core layer. Names such as Clash Verge, Clash Verge Rev, ClashX, and FlClash usually refer to graphical clients. A subscription link is a configuration source—not a core or a component of any particular client. The same base configuration may be loaded by multiple clients, but whether it runs fully depends on whether the underlying core supports all of its fields.

Proxy core

Parses configuration and forwards traffic. Common names include the original Clash, Clash.Meta, and its successor, mihomo.

Graphical client

Provides the core with a window, tray controls, subscription management, system proxy settings, and a TUN toggle; it is not itself a proxy protocol implementation.

Subscriptions and configuration

Provides proxies, proxy groups, rules, DNS settings, and traffic-interception parameters in YAML or subscription responses.

The project lineage from original Clash to mihomo

Original Clash: the starting point for the configuration syntax and rule model

Developed by Dreamacro, the original Clash established the configuration structure still widely used today: proxies defines proxies, proxy-groups organizes selection and health checks, and rules determines traffic destinations in order. Common rules such as DOMAIN-SUFFIX, IP-CIDR, GEOIP, and the final catch-all rule all come from this model.

The original open-source Clash is commonly identified by its final version, v1.18.0. Clash Premium was also released as a separate build, with the public version 2023.08.17. Although the original project stopped active maintenance in 2023, it remains important for configuration compatibility. It should no longer be treated as the sole reference for new protocols, rule capabilities, or platform fixes.

Clash.Meta: extending functionality while preserving compatibility

Clash.Meta can initially be understood as an extended core compatible with the Clash configuration model. It retains familiar proxy-group and rule syntax while adding broader TUN, DNS, rule-set, and protocol support. Fields such as rule-providers, fake-ip-filter, process matching, and more granular network-stack options generally receive more active maintenance in Meta-based cores.

“Compatible” does not mean interchangeable in every direction. A basic Clash configuration can usually be read by mihomo, but a configuration using mihomo extensions may produce “unrecognized field,” “unsupported proxy type,” or configuration-load errors in an older original Clash build. Treat migration compatibility as generally smoother from older syntax to a newer core, not as perfect bidirectional compatibility.

mihomo: the successor name for Clash.Meta

Clash.Meta was later renamed mihomo, and the project continues to be maintained by the MetaCubeX community. The name change did not turn it into a completely different configuration system: many clients, configuration converters, and log pages still use older names such as Meta, Clash Meta, or Meta Core. When you see these terms, check the specific version number instead of treating them as three unrelated cores.

The current lineage can therefore be summarized as follows: the original Clash provides the foundational configuration model; Clash.Meta extends it while preserving compatibility; and mihomo continues Clash.Meta development. When a client is labeled as using the “mihomo core,” it generally targets this actively updated branch.

What are Verge, ClashX, and Clash for Windows?

Clash Verge and Clash Verge Rev

Clash Verge is a cross-platform graphical client built with desktop web technologies. It handles subscriptions, proxy selection, system proxy settings, and configuration editing. After the original Clash Verge project became inactive, Clash Verge Rev continued with a similar workflow as a maintained fork. The names are similar, but their repositories, version series, and maintenance status differ, so do not identify a download solely by its app icon.

In Clash Verge Rev, users can usually open Settings → Clash Settings to view port, external controller, and core-related parameters, and Settings → System Settings to manage launch-at-login or service mode. Labels may vary slightly between versions, but the core version shown on the settings page says more about actual capabilities than the installer name. Enabling TUN on Windows often also requires installing and starting service mode; on macOS, system permission authorization is required.

ClashX: a macOS menu bar client

ClashX focuses on the macOS menu bar experience. It puts configuration switching, proxy-group selection, system proxy controls, and log access in the status-menu interface, making it suitable when system-proxy routing is the primary interception method. ClashX, ClashX Pro, and community-maintained continuations cannot be judged by name alone; check each one's core type, last update, and support for the current macOS release.

Older ClashX versions can read many classic Clash configurations, but may fail to load configurations fully when they use protocols, rule-set behavior, or DNS fields supported only by mihomo. If the subscription documentation explicitly requires the Meta or mihomo core, choose a client that clearly integrates the corresponding core instead of repeatedly removing fields just to make an old client start.

Clash for Windows: historically influential, but no longer updated

Clash for Windows, often abbreviated as CFW, was the first desktop client many users encountered. It provided Profiles, Proxies, Connections, Logs, and Settings pages, and popularized the desktop workflow of importing a subscription and switching proxy groups directly. Its final commonly seen release was 0.20.39; the project stopped receiving updates in 2023.

One clarification is important: Clash for Windows is not a fully open-source graphical client. The word Clash in its name does not make it the same project as the original open-source core. Continuing to use an old installer means accepting limitations in support for newer systems, core capabilities, and bug fixes. For a fresh installation, choose a client with a visible maintenance history and a clearly documented core.

Why the same subscription behaves differently across clients

Importing a subscription is only the first step. Once the client receives the subscription content, it must pass it to the core for parsing. Even when two interfaces both display “Clash configuration,” differences in core versions, override logic, DNS implementation, and traffic interception can produce different results. The most common differences fall into four areas.

Configuration fields and proxy protocol support

• Common fields such as mixed-port, proxies, proxy-groups, and rules have broad compatibility.
• New protocol parameters, rule-set behavior, and advanced DNS options typically require a newer mihomo core.
• A client may add local overrides on top of the subscription, such as changing the port, enabling LAN access, or inserting TUN settings.
• A proxy group with the same name may be generated by the subscription or modified by a client script. When troubleshooting, distinguish the remote source from the final runtime configuration.

System proxy and TUN cover different traffic

A system proxy generally writes the HTTP and SOCKS proxy addresses into the operating system settings. A common local mixed port is 127.0.0.1:7890. An application must read the system proxy or specify that port manually for its traffic to enter the core. Games, some command-line programs, and apps with their own network stacks may bypass the system proxy.

TUN mode uses a virtual network device to intercept more IP traffic. It depends more heavily on system permissions, routing tables, DNS hijacking, and network-stack settings. Even if two clients use the same mihomo version, TUN behavior will differ if one successfully installs the service component while the other lacks permission. When troubleshooting, first check the logs for successful TUN device creation, then inspect rule matches; do not mistake a permissions failure for a dead proxy node.

mixed-port: 7890
external-controller: 127.0.0.1:9090
secret: "change-this-controller-secret"

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

The 7890 port above is the proxy entry point, while 9090 is the external control interface; they serve different purposes. The external control interface lets the client query connections and switch proxy groups, and should not be used by a browser as an HTTP proxy port. If the client has generated a control secret automatically, keep the generated value to prevent the interface from losing contact with the core.

DNS policies can change rule-matching results

Clash-family cores determine routing based on domain names, IP addresses, and rule order. In fake-ip mode, the core first returns a reserved address to the application, then maintains a domain mapping for subsequent rule matching. If a client changes enhanced-mode, nameserver, or fake-ip-filter, identical rules may produce different results.

For troubleshooting, set the level to info on the client's Logs page, then visit one mainland-China domain, one domain that requires a proxy, and one raw IP address. Observe them continuously for at least 30 seconds and verify that each request matches the expected policy. If domain rules work but raw IP traffic bypasses the proxy, check TUN or system-proxy coverage first. If everything falls into the catch-all policy, inspect rule order and DNS mappings.

How to tell whether a project is still worth using

A project name only indicates its origin; it does not directly reflect its current status. When choosing a client, check release activity, core provenance, operating-system support, and configuration compatibility together. An interface that still opens does not necessarily handle every field in a current subscription correctly.

1. Check recent releases. Confirm the release date, notes, and supported systems for official versions; do not judge activity solely by whether the repository remains accessible.
2. Confirm the core name and version. Prefer clients that clearly display the mihomo version under Settings → About or Settings → Clash Settings.
3. Check the operating-system architecture. Windows commonly offers x64 and ARM64 builds; macOS requires distinguishing Apple Silicon from Intel; on Linux, also confirm whether deployment uses AppImage, deb, rpm, or the command line.
4. Review the permission model. If you need TUN, confirm that the client provides service mode, administrator-permission guidance, or the macOS Network Extension authorization flow.
5. Verify subscription requirements. If the configuration provider specifies mihomo, Meta, or support for a particular protocol, do not choose a client that integrates only an old original Clash core.
6. Keep a rollback configuration. Export the currently working configuration before updating the client or core, and record the system proxy port, overrides, and DNS settings.

Migrating from an old client to a mihomo client

When migrating from Clash for Windows, an older ClashX, or an early Verge release, the safest approach is to handle the subscription and local settings separately. Import the original subscription into the new client first and confirm that basic proxying works; then restore overrides, TUN, LAN access, and custom rules one by one. Copying the entire old configuration directory can also bring along caches, obsolete core paths, and expired controller settings.

Record these five parameters before migrating

• The current subscription URL and refresh time; also confirm that the subscription still refreshes successfully.
• The proxy entry port, commonly the mixed port 7890; HTTP 7890 and SOCKS 7891 may also be configured separately.
• Whether the current mode is Rule, Global, or Direct, along with the default proxy-group selection.
• Whether TUN, LAN connections, IPv6, and custom DNS are enabled.
• Locally added rules, scripts, or configuration overrides, which are usually not included in the remote subscription.

Confirm the migration in three rounds

1. Round one: enable system proxy only. Turn off TUN, select Rule mode, and open one mainland-China site and one site that requires a proxy. Confirm that the logs show the expected rules and proxy groups.
2. Round two: test subscription refresh. Update the configuration manually once, wait for the page to show the refresh time, and confirm that the proxy-group selection was not reset unexpectedly.
3. Round three: enable TUN. Start service mode or complete system authorization, then test a command-line program that does not read the system proxy. You can use curl --connect-timeout 10 https://example.com to limit the connection timeout to 10 seconds and compare the result with the client's connection list.

If the first round succeeds but the third fails, the issue is usually related to TUN permissions, routing, or DNS; there is no need to replace the subscription immediately. If import already reports an error, inspect the first parsing error and confirm whether the specific field requires mihomo. If only individual nodes fail, compare their protocol parameters and the server status.

Remember the ecosystem with one relationship map

The Clash ecosystem is not “one piece of software with many names,” but a group of projects that share configuration ideas while being maintained by different teams. The original Clash is the foundational core; Clash.Meta extends its configuration model; and Clash.Meta continues development under the name mihomo. Projects such as Clash Verge Rev and ClashX sit at the graphical-client layer and perform proxy work by integrating a core. Subscriptions belong to the configuration layer and can be migrated between compatible clients.

Subscriptions and YAML configuration
        │
        ▼
Graphical client
Clash Verge Rev / ClashX / other clients
        │
        ▼
Proxy core
mihomo (formerly Clash.Meta)
        │
        ▼
Rule matching / DNS / system proxy / TUN / connection forwarding

Reduce the choice to three questions: Is the client still maintained? Which core does it integrate? Does the current subscription depend on extensions provided by that core? Once these are answered, the confusion caused by similar names largely disappears. For a new installation, prioritize clients with recent releases, explicit mihomo integration, and support for the permission model of the current operating system. For a stable existing setup, record the configuration and ports first, then migrate in stages.