Clash Nyanpasu: a Tauri GUI for Clash, Mihomo and Clash Rust

What Clash Nyanpasu is, and the problem it removes

Clash and its forks are rule-based tunnel kernels. They read a YAML configuration file that declares proxies, proxy groups and routing rules, then expose a local HTTP or SOCKS listener plus a control API. Editing that YAML by hand is workable for one profile and painful for five, and it gives you no way to see which node a request actually took.

Clash Nyanpasu is the desktop layer on top of that. The README describes it as "a Clash GUI based on Tauri", and it manages profiles, providers and rulesets through a local-first interface. The intended user is someone who already understands what a Clash config does and wants a window to switch between configurations, edit them with more than a text editor, and watch traffic without opening a terminal. It is not a way to avoid learning the config format; the profile still has to be valid YAML for the kernel to accept it.

The feature list is where the project draws its boundary. It supports four kernels: Clash Premium, Mihomo, Clash Rust and Meow. That is a wider kernel surface than most single-kernel GUIs offer, and it is the main reason to pick this over a thinner front end. It also means the GUI has to paper over four different control APIs and config dialects, which is a real source of edge cases.

The Tauri backend, the Rust front end and where profiles actually live

The repository is a pnpm monorepo. At the top level you find backend/, frontend/, manifest/, scripts/, tools/ and docs/, with package.json declaring the workspace as @nyanpasu/monorepo at version 2.0.0. Rust is the primary language, which matches the Tauri choice: the shell is a Rust process hosting a web view, not an Electron bundle.

The data flow the repository layout implies is straightforward. A profile is a YAML document, optionally post-processed. The README lists profile enhancement "by YAML, JavaScript & Lua" and links to a proxy-chain tutorial, so the enhancement step runs before the kernel sees the config. The backend then launches or talks to the selected kernel and exposes its state to the frontend. The frontend is a React application built from the @nyanpasu/nyanpasu package, using Material You components per the feature list.

Two details in the build scripts are worth reading closely. First, tauri:diff passes -f verge-dev deadlock-detection, which suggests a feature-flagged developer build with deadlock detection compiled in. Second, build:debug disables the updater with an inline config override setting tauri.updater.active to false. That tells you the updater is a real, switchable component rather than a link to a releases page.

The architecture ledger script is the unusual part. package.json defines lint:architecture-ledger, which runs scripts/architecture-ledger.ts in gate mode, and architecture-ledger for report mode. A project that gates CI on an architecture ledger is asserting something about module boundaries. The README does not explain what the ledger checks, so treat it as an internal invariant you inherit if you fork.

Installing Clash Nyanpasu from source and running the dev build

The README does not contain end-user install instructions. It points to https://nyanpasu.org/tutorial/install for that, and to the releases page for binaries. What the README does document is the development setup, which is the only install path you can follow from the repository alone.

Prerequisites are Rust, Node.js and pnpm, with a link to the Tauri v2 prerequisites page. Once those are present, install the workspace dependencies.

pnpm i

That resolves the monorepo packages, including @nyanpasu/interface and @nyanpasu/utils, which the build:packages script compiles separately.

Next, fetch the kernel binaries and other dependencies. This is the step that surprises people, because the GUI does not ship the kernel inside the repository.

pnpm prepare:check

The README notes you can force a refresh of that download with pnpm prepare:check --force. After it completes, start the development build.

pnpm dev

If an application instance is already running, the README offers pnpm dev:diff as the alternative. For a release build, the documented command is pnpm build, and build:release chains the package builds first. Expect the first Tauri compile to take a while; that is a property of Rust builds, not of this project specifically.

The kernel download is the sharpest limitation

The most consequential design decision is that pnpm prepare:check pulls the Clash-family kernel binary rather than vendoring it. The README does not document which version is fetched, where it is cached, how it is verified, or how to pin it. The .gitmodules entry at the repository root suggests at least one component arrives as a submodule, but the README does not say which one or what it contains.

That matters for two audiences. If you are evaluating the project for an environment with restricted outbound network access, the build will fail at prepare:check and the README gives you no offline path. If you care about supply-chain provenance, you are trusting a fetch you cannot audit from the documentation. Neither is fatal, but both are things a reviewer should confirm before adopting.

The second limitation is scope. The related searches around this project include "clash nyanpasu apk" and "clash nyanpasu android". The README lists Windows, macOS and Linux under the inherited Clash Verge description and says nothing about a mobile client. There is no Android artifact documented here. If you need a phone client, this is the wrong project.

The third is the release cadence. The repository is not archived, but the last push was on 2023-11-11. The releases listed alongside it include v1.6.0 and v1.6.1, whose dates are later than that push, and a dev pre-release sharing the push timestamp. Whatever the explanation, the README and the repository tree are not being updated in step with the releases, and the documentation you read may describe an older build than the one you install.

Clash Verge and Clash Verge Rev: the same lineage, different maintenance

Clash Nyanpasu descends from zzzgydi/clash-verge, and the README acknowledges that inheritance directly, along with patches taken from clash-verge-rev/clash-verge-rev. All three are Tauri-based Clash GUIs, so the difference is not the framework.

The practical difference is what each one optimizes for. Clash Verge Rev is described in the acknowledgement as another fork of Clash Verge with some patches included for bug fixes, which frames it as a continuation of the original line. Clash Nyanpasu instead went wide on kernels: Clash Premium, Mihomo, Clash Rust and Meow, plus profile enhancement in YAML, JavaScript and Lua. If your config targets Mihomo-specific features, kernel breadth is an argument for Nyanpasu. If you want the fork that the surrounding ecosystem keeps patching, the acknowledgement points at Clash Verge Rev.

There is also a kernel-level alternative worth naming: you can run Mihomo or Clash directly and manage the YAML yourself. You lose the GUI, the provider management view and the profile switcher, and you gain the ability to read exactly what is executing. For a single static config on a server, that is the better trade. The search questions about Clash Verge being free and what it is used for apply equally to this project: it is a desktop client for routing traffic through rule-based proxies, and it costs nothing to use.

Licence, upgrade cost and what a fork inherits

The project is GPL-3.0, stated in both the README and package.json. If you distribute a modified Clash Nyanpasu, the GPL obligations attach to the whole combined work, and because the GUI is Tauri rather than Electron, the Rust backend and the React frontend are one binary rather than separable processes. Check how that interacts with any redistribution plan you have; this is a description of the licence, not legal advice.

The upgrade cost is dominated by the kernel fetch. Every fresh checkout or CI run repeats pnpm prepare:check, and the README documents no cache key, checksum or version pin. A reproducible build therefore depends on whatever that script resolves at run time. If you vendor the kernel yourself, you are now maintaining a fork of a fetch script the README does not describe.

Forking also brings the architecture ledger with it. lint:architecture-ledger runs in gate mode and will fail a build that violates whatever invariant scripts/architecture-ledger.ts encodes. That is useful discipline and an undocumented constraint at the same time, since the README does not explain the rule set. Read the script before you restructure modules.

Editorial conclusion

Adopt Clash Nyanpasu if you want a Material You desktop front end that can drive several Clash-family kernels and you are comfortable reading the docs site rather than the README for setup. Skip it if you need a maintained release cadence, a mobile client, or a kernel you can audit line by line, since the GUI downloads the kernel binary through pnpm prepare:check. Before installing, verify three things: that a current release artifact exists for your platform, that your chosen kernel (Clash Premium, Mihomo, Clash Rust or Meow) is the one you actually want, and that GPL-3.0 fits how you plan to redistribute anything you build from the source tree. The last push to the repository was on 2023-11-11, so treat the project as a frozen snapshot rather than a moving target.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes