Clash, mihomo, Verge Rev: How the Open-Source Project Family Fits Together

First-time users of the Clash ecosystem often get confused: searching "Clash download" turns up a dozen differently named apps, each with its own interface, scattered across different GitHub accounts. This mess isn't random — it has a clear historical timeline. After the original author archived the repository, the community stepped in to keep things going, which is how today's landscape took shape. Understanding this timeline explains why some clients ship frequent updates while others have stalled, and which one to pick on which platform.

The original Clash project was built by Dreamacro in Go, based on rule-driven traffic routing: the config file lists which domains or IP ranges should go through which proxy node, and the core matches traffic against those rules line by line and forwards it. Every later fork fully inherited this design — it's the foundation for understanding the whole ecosystem.

Around 2023, the original repository was archived for reasons outside the project's control, switching to read-only and no longer accepting new commits. That was a shock for every GUI client relying on the Clash core at the time — no more core updates meant no new protocol support, no new rule syntax, and no security fixes reaching the official build. The community split into two responses:

• Keep using the old core: some clients froze on the last pre-archive release and never adopted new features, eventually running into protocol incompatibilities the longer they were used.
• Switch to a community-maintained fork core: this is the path every active project takes today, and it's what this article focuses on — mihomo.

mihomo is the renamed continuation of the former Clash Meta project, maintained by a community team, and it's currently the most active, most frequently updated open-source core. Building on the original Clash's rule-based routing, it fills in and strengthens the following:

• TUN mode: creates a virtual network adapter at the system network layer for full traffic takeover, no longer relying on per-app manual proxy settings — this also works for apps that don't respect system proxy settings.
• Broader protocol support: VMess, VLESS, Trojan, Hysteria, Hysteria2, TUIC, and more have been added over time, at a pace clearly faster than the original core ever managed before it stopped updating.
• Extended rule sets: supports remote rule set formats like GEOSITE and GEOIP, making it easier for subscriptions to organize rules by region and service without a client having to list every domain by hand.
• Scripting and advanced policies: offers Script-type rules and more flexible nested policy groups for complex routing setups.

Worth stressing: mihomo itself is a headless core with no GUI. The clients people actually use day to day — Verge Rev, FlClash, Nyanpasu, and others — are all graphical shells built on top of mihomo, handling config management, node lists, subscription imports, traffic stats, and other interaction-layer features. The actual proxying and routing logic is still handled by the core itself.

Now that the core has consolidated, the differences between GUI clients mostly come down to development language, UI framework, and target platforms. Here's a breakdown by project to help you choose based on your use case.

Verge Rev (clash-verge-rev)

Built with the Tauri framework — a web-based frontend paired with a Rust backend — making it lighter than traditional Electron clients. It's one of the most consistently updated desktop clients across Windows, macOS, and Linux, with dual-mode config editing that switches between a visual editor and raw YAML, suiting both newcomers and users who prefer hand-editing configs. Policy groups, connection details, and log panels are all fairly thorough here too.

FlClash

Built with the Flutter framework, its standout feature is heavy cross-platform code reuse — the same UI codebase compiles into clients for Windows, macOS, Linux, and Android, all keeping a consistent look and feel. For anyone switching between multiple devices running different systems who wants a familiar interface each time, this kind of client cuts down on the relearning curve.

Nyanpasu (clash-nyanpasu)

Also built on Tauri, but its interface leans more into animation and theme customization, with visual config management and automatic subscription updates. It's technically close to Verge Rev, but takes a different path on visual style and some interaction details — a good fit for users who want a more personalized look.

Mobile and Other Platforms

On Android, besides FlClash, there are several standalone clients built on the mihomo core, most supporting global proxying under TUN mode as well as per-app routing. iOS options are more limited — most clients are distributed through the App Store, lean closer to native system design conventions, and put more emphasis on one-tap subscription link imports for config management.

Since every mainstream client ultimately calls mihomo or a compatible core to parse configs, YAML config files and subscription links are largely interchangeable across these clients. A standard config typically includes these core fields:

port: 7890
socks-port: 7891
mode: rule
log-level: info
proxies:
  - name: "Sample Node"
    type: vmess
    server: example.com
    port: 443
proxy-groups:
  - name: "Auto Select"
    type: url-test
    proxies: ["Sample Node"]
rules:
  - DOMAIN-SUFFIX,example.com,Auto Select
  - MATCH,DIRECT

This means moving from one client to another usually doesn't require reconfiguring your proxy nodes — just import your existing subscription link or local config file and you're set. The differences worth watching are client-specific interface settings, such as how the system proxy toggle works, where TUN mode gets enabled, and log retention policies — these are shell-layer features that don't automatically carry over when you switch cores.

1. Confirm your platform coverage

   Start by identifying which systems you need covered — just Windows, or Windows, macOS, and Android together. For multi-platform use, favor a single project's cross-platform build to avoid the hassle of converting config files between different clients.

2. Check the release cadence

   Check the timestamp of the latest release on the GitHub repo page. A client that opens fine but hasn't been updated in a long time may still fail to parse newer protocols or rule syntax because its core has fallen behind.

3. Verify TUN mode support

   If you need full system-wide traffic takeover rather than per-app proxying, confirm your target client explicitly supports TUN mode and grant the required system-level permissions (e.g. admin rights on Windows, network extension approval on macOS).

4. Keep your existing config

   Export or back up your current subscription link and local rules before switching clients, so you can import them straight into the new client without rebuilding your node list from scratch.

Putting it all together gives a clear line of reasoning: Clash established the rule-based routing architecture → mihomo, as the community-carried core, keeps delivering protocol and feature updates → GUI clients like Verge Rev, FlClash, and Nyanpasu each build their own interface and interaction experience on top of mihomo. Choosing a client essentially means choosing an interface shell — as long as the core is the same, config files stay portable, and switching between clients costs very little. What's actually worth spending time comparing is whether the interface fits your workflow, whether your target platform is well supported, and whether the project is still actively maintained.