Start by separating cores, clients, and configuration

The Clash ecosystem is easy to misunderstand because several project names include Clash, even though they operate at different layers. The original Clash, Clash.Meta, and mihomo are primarily proxy cores; Clash Verge Rev, Clash Nyanpasu, and ClashX are graphical clients; subscription links, YAML files, and rule sets are data read by the core. When evaluating a project, identifying its layer is more useful than comparing screenshots.

The core handles network processing

The core listens on local proxy ports, connects to proxy servers, and uses rules to determine where traffic goes. Typical tasks include parsing YAML configuration, managing proxy groups, matching domain and IP rules, applying DNS policies, exposing a REST API, and handling TUN traffic on supported platforms. Here is a typical core configuration:

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

external-controller: 127.0.0.1:9090
secret: "change-this-controller-secret"

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

Here, 7890 is the mixed port shared by HTTP and SOCKS5, 9090 is the control interface port, and 1053 is an example DNS listening port. Graphical clients typically use the control interface to read proxy nodes, switch proxy groups, and view connection records. The UI action “select a node” ultimately becomes an API call to the core.

The graphical client manages lifecycle and system integration

  • Download, update, and switch subscription configurations.
  • Start, stop, and monitor the core process.
  • Configure the system proxy or create a virtual TUN interface.
  • Provide interfaces for proxy groups, rules, connections, logs, and traffic statistics.
  • Save client-specific settings such as launch-at-login, tray behavior, and the core path.

As a result, the same subscription can behave differently in two clients without the subscription itself having changed. Differences may come from the core version, default DNS settings, TUN implementation, fields added by the client, or configuration options that the client does not display.

The lineage of the original Clash, Clash.Meta, and mihomo

The original Clash established the configuration and API model

The original Clash, maintained by Dreamacro and written in Go, established the ecosystem’s most important compatibility foundation: YAML configuration, proxy groups, sequential rule matching, HTTP and SOCKS listening ports, and an external control API. Many clients were initially built around these interfaces. The original repository stopped receiving maintenance and was archived in 2023. Continuing to rely on the original core means no further upstream protocol support, platform compatibility updates, or network-stack fixes.

Clash Premium was a separate historical distribution with additional features, including rule sets, scripts, and more complete TUN support. It is not an active open-source line to follow when choosing a new client today. Fields such as rule-providers, tun, and script found in older guides must be evaluated against the actual core; the words “Clash configuration” alone do not establish compatibility.

Clash.Meta expanded the original capabilities

Clash.Meta was maintained by the MetaCubeX community. It began with compatibility for Clash configuration and control APIs, then expanded protocol, DNS, rule, listener, and TUN capabilities. Many configuration providers once labeled the corresponding subscriptions “Clash Meta.” Such subscriptions may contain proxy types or fields unknown to the original Clash. Importing them directly into an older ClashX, an older Clash for Windows, or the original Clash core can therefore cause parsing failures or silently ignored options.

mihomo is the successor name for Clash.Meta

Clash.Meta was later renamed mihomo. The name change did not discard the configuration model: common structures such as proxies, proxy-groups, rules, proxy-providers, and rule-providers remain in use. The important migration questions are whether the client uses an actively maintained mihomo core, whether its version meets the configuration requirements, and whether the client modifies the configuration before startup.

mihomo versions are typically released in the form v1.x.x. When troubleshooting, record the full version number rather than simply writing “Meta core.” This information is usually available under the client’s “Settings” → “Core” or “Settings” → “Version” page; menu names vary slightly by project. Startup logs commonly print the version, Go runtime, and target architecture, such as linux-amd64, windows-amd64, or darwin-arm64.

What desktop client forks are designed to solve

Clash Verge and Clash Verge Rev

Clash Verge is a cross-platform desktop client built with Tauri, with the UI layer separated from the proxy core. After the original project stopped being maintained, Clash Verge Rev continued the community fork and ongoing mihomo support. The names are similar, but their maintenance status and core update sources differ. For a new installation, confirm that the project is explicitly identified as Rev, then check the loaded mihomo version under “Settings” → “Core Settings.”

Clash Verge Rev suits users who want a similar workflow across Windows, macOS, and Linux. A common flow is “Subscriptions” → “New” to add a subscription URL, selecting a strategy group on the “Proxies” page after updating, then enabling the system proxy or TUN mode under “Settings.” The system proxy mainly handles applications that follow the operating system proxy settings; TUN mode uses a virtual network interface to handle more types of traffic and usually requires administrator privileges plus correct routing and DNS settings.

Clash Nyanpasu

Clash Nyanpasu is also a cross-platform graphical client, focused on configuration management, core management, and desktop interaction. It is not a replacement for mihomo; it downloads or invokes the core, generates the runtime configuration, and displays core status. When using it, check the “client version” and “core version” separately: updating the UI does not necessarily update the proxy core.

Nyanpasu suits users who manage multiple configurations, overrides, and proxy groups. If behavior changes after a subscription update, check the active item under “Configuration,” overrides, core selection, and runtime logs in that order. If a configuration starts successfully in mihomo from the command line but fails in Nyanpasu, focus on the final configuration after client-side merging rather than only the original subscription file.

ClashX, ClashX Pro, and ClashX.Meta

ClashX is an early macOS menu bar client whose controls are concentrated in the status bar icon. Its classic version was designed around the original Clash core and helps explain the menu structure found in many older macOS guides, including “Set as System Proxy,” “Outbound Mode,” and proxy group selection. Because the original core has been archived, classic ClashX is not suitable for configurations that depend on newer protocols, modern rule-set capabilities, or changes in newer macOS networking.

ClashX Pro was a historical enhanced distribution; the word Pro alone does not prove that it uses mihomo. ClashX.Meta was a fork created for Meta core compatibility. Their icons and menus may look similar, but their core sources differ. Before importing a configuration, open “Help” → “About” or inspect the startup log to confirm the core name and version. Comparing application filenames cannot determine whether a particular proxy type is supported.

Clash for Windows

Clash for Windows was once a widely used desktop client, but it was not open source and stopped being maintained in 2023. Many older guides still use its “Profiles,” “Proxies,” “General,” and “Connections” pages as examples. These guides can explain the configuration concepts, but their navigation paths should not be applied directly to Verge Rev or Nyanpasu.

When migrating from Clash for Windows, prioritize the subscription URL or original YAML rather than copying the entire application directory. The old directory may also contain client-generated merged configuration, cached rule sets, and local overrides. Re-import the subscription into the new client, then rebuild the port, LAN access, TUN, and DNS settings one by one to make differences easier to isolate.

Where mobile clients, routers, and web panels fit

Mobile clients are separate implementations

Even when Android and iOS apps support the Clash format, they do not necessarily run the same core binary as the desktop client. Mobile operating systems impose separate restrictions on background processes, VPN interfaces, DNS, and battery management. Android clients generally create a TUN through the system VPN API; iOS clients rely on Network Extension. The desktop “system proxy” switch has no exact equivalent on phones.

Clash Meta for Android was once a common Meta-based mobile client, but whether to continue using it should be judged by the repository’s archived status and recent release history. Projects such as FlClash can also use mihomo capabilities, but their UI settings, configuration storage, and system integration are client-specific. For cross-device configuration reuse, share the subscription base while keeping platform-specific TUN, DNS listening addresses, and LAN parameters local to each device.

OpenClash is an OpenWrt plugin layer

OpenClash runs in an OpenWrt environment and handles core deployment, configuration conversion, rule updates, firewall and DNS integration. It is neither a desktop client nor a standalone proxy protocol. Router traffic interception involves nftables or iptables, policy routing, DNS hijacking, and LAN address ranges, making it more complex than a desktop system-proxy switch.

For example, the desktop setting mixed-port: 7890 provides a proxy entry for local applications; transparent interception on a router must also handle forwarded traffic from LAN devices. Enabling allow-lan: true only allows other devices to connect to the proxy listening port. It does not automatically configure gateway forwarding, DNS interception, or firewall access.

Yacd and MetaCubeXD are dashboards

Projects such as Yacd and MetaCubeXD are external control panels. They connect to the core’s REST API and WebSocket to display proxy groups, active connections, rule matches, and traffic data. The panel itself does not process proxy traffic and cannot replace mihomo. If the core control address is 127.0.0.1:9090, only the local machine can access it directly. For LAN administration, adjust the listening address carefully and use a sufficiently strong secret plus firewall rules.

How subscriptions, configurations, and rule sets move between projects

A subscription URL usually returns a YAML configuration, though it may also return an encoded list of nodes. The client downloads the content, applies conversion or overrides when necessary, and then passes the final configuration to the core. “Supports Clash subscriptions” covers at least three layers: recognizing the file format, recognizing the proxy protocols inside it, and correctly executing its DNS and rule fields.

Complete configurations and provider configurations

A complete configuration puts nodes, proxy groups, and rules in one file. A provider-based setup splits nodes or rules into remote resources that the core updates periodically. The structure below refreshes the proxy provider every 3600 seconds and uses the specified URL for health checks:

proxy-providers:
  airport:
    type: http
    url: "https://example.invalid/subscription.yaml"
    path: ./providers/airport.yaml
    interval: 3600
    health-check:
      enable: true
      interval: 600
      url: "https://www.gstatic.com/generate_204"

proxy-groups:
  - name: PROXY
    type: select
    use:
      - airport

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

interval: 3600 controls the subscription refresh interval, while health-check.interval: 600 controls the health-check interval; they are separate settings. The response time from the test URL only reflects the request latency to that target, not download bandwidth. Rules are matched in order, so MATCH should be placed last as the fallback.

Client overrides change the final result

  • Port override: the client may change the subscription’s mixed-port to a locally specified port.
  • DNS override: when TUN is enabled, the client may insert dns-hijack, Fake IP, or nameserver settings.
  • Rule override: scripts or merged configuration may add direct, reject, or process-based rules before the existing rules.
  • Proxy-group override: the client may preserve a local selection, so after a subscription update it still points to the previous node name.

When troubleshooting compatibility, the most useful artifact is the final YAML that the client actually passes to the core. If the client offers “Configuration” → “View Runtime Configuration” or “Settings” → “Open Configuration Directory,” export that file and compare it with the original subscription. The configuration path recorded in the logs can also help locate the generated file.

TUN, system proxy, and core differences

The system proxy only covers applications that actively read proxy settings

After the system proxy is enabled, the client typically points the operating system’s HTTP and HTTPS proxy to 127.0.0.1:7890. Browsers and most desktop applications read this setting, but games, some command-line programs, virtual machines, and software with its own network stack may bypass it. A running core and a working browser therefore do not prove that every process is using the proxy.

TUN uses a virtual network interface to handle IP traffic

mihomo’s TUN mode creates a virtual network interface and receives traffic through routing and DNS settings. A typical example looks like this:

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

stack: mixed selects the mixed network-stack strategy supported by the core, auto-route requests automatic route setup, and auto-detect-interface identifies the default interface. Administrator privileges, network drivers, and firewall requirements differ by operating system. If Windows loses all connectivity after switching to TUN, first check that the client is running with the required permissions, then inspect routes created by other VPNs, Hyper-V, WSL, or security software.

Differences in TUN behavior between clients often come from startup order, route cleanup, DNS injection, and sleep/wake handling rather than mihomo itself. When comparing two clients, use the same configuration, core version, and network environment. Record startup time, the first DNS response, default-route changes, and connection state after wake-up instead of comparing only the memory number shown in the UI.

How to assess maintenance status

Continuation of a project name does not mean continued maintenance. When choosing a client, check the code repository, release page, and bundled core together rather than relying only on the version string shown on a download page. The original Clash, Clash for Windows, classic ClashX, and various community forks do not share the same status.

Four verifiable signals

  1. Recent releases: Check the release date, change log, and whether installers for all platforms were generated together.
  2. Core source: Confirm whether the client uses the original Clash, mihomo, or another bundled compatibility core.
  3. Issue handling: Check whether issues related to current Windows, macOS, and Linux versions are categorized and fixed.
  4. Upgrade path: Confirm whether a client upgrade also updates the core and whether you can manually roll back after a failure.

Version numbers cannot be compared directly across projects. Clash Verge Rev 2.x, Nyanpasu 2.x, and mihomo v1.x.x are different software products, so their numbers have no shared lineage. When reporting a failure, include the full client version, full mihomo version, operating system version, CPU architecture, current mode, and key logs. “Windows 11 24H2, x64, client 2.x, mihomo v1.x.x, TUN mixed stack” is much easier to diagnose than “the latest version does not work.”

Do not infer architecture from the application name

macOS installers may offer both x64 and arm64; Apple silicon devices should generally use the arm64 build. Windows devices commonly use x64, while some newer devices use arm64. Linux also requires distinguishing AppImage, deb, and rpm packages and their system-library requirements. With a mismatched architecture, the application may launch through translation while the TUN helper or core binary still fails.

Choose a project by use case

Consistent workflows across Windows, macOS, and Linux

If you need similar configuration management across the three desktop platforms, start by evaluating Clash Verge Rev or Clash Nyanpasu. Compare TUN support on your current system, configuration override capabilities, core update mechanisms, and log access. For browser-only proxying, system-proxy stability matters more than advanced TUN options.

Lightweight macOS menu bar control

If you prefer menu bar interaction, consider a macOS client that is actively maintained and explicitly uses mihomo. If you continue using classic ClashX, understand its core limitations and avoid importing configurations containing mihomo-specific fields. Before upgrading macOS, confirm that the client supports the new system’s network permissions and background-launch behavior.

Route all household devices through the router

When TVs, game consoles, and IoT devices cannot install a client, OpenWrt with OpenClash is a common solution. Before deployment, check the router’s CPU architecture, available memory, flash storage, and firewall framework. Large rule sets, high connection counts, or complex DNS settings can require substantially more resources than a simple local-port proxy.

When you only need the core and a remote panel

A server or minimal Linux environment can run mihomo directly, manage the process with systemd, and connect to its control port through a dashboard such as MetaCubeXD. This setup requires you to handle the configuration directory, file permissions, log rotation, and upgrades yourself. The control interface should not be exposed directly to untrusted networks; restrict remote access with firewall rules, reverse-proxy authentication, or a secure tunnel.

Migration sequence for an old client

  1. Record current settings: Save the subscription URL, current proxy-group selection, local overrides, listening port, and LAN settings.
  2. Export the original configuration: Save the subscription YAML first; do not treat caches, logs, or the client database as portable configuration.
  3. Install the new client: Confirm the system architecture, then check the mihomo version under “Settings” → “Core.”
  4. Test the system proxy first: Use the default 7890 or the actual port shown by the client, and confirm that basic rules and DNS work correctly.
  5. Enable TUN afterward: Record routing and DNS changes before and after enabling it so you can quickly roll back if connectivity fails.
  6. Rebuild overrides: Add rules, DNS, and LAN settings one at a time, reloading and checking the logs after each change.

If the old configuration contains script mode, Premium-only fields, or obsolete proxy types, first determine the corresponding implementation in mihomo. Do not copy the entire merged configuration from the old client at once; it may contain absolute paths, old ports, outdated interface names, and platform-specific fields.

After migration, run three checks: access a site in a browser through the system proxy; use the command line with explicit http://127.0.0.1:7890; and, with TUN enabled, test an application that does not read system proxy settings. These results distinguish subscription issues from system-proxy and TUN-routing issues.