Clash Nyanpasu 2.0: a Tauri desktop manager for four Clash cores, with per-process traffic analysis

Four proxy cores behind one Tauri window

Clash Nyanpasu is a desktop application for Windows, macOS and Linux built with Rust and Tauri on the backend and React with TypeScript on the frontend. It does not implement a proxy itself. Instead it manages a proxy core, and four are offered: Mihomo, Clash Rust, Meow and Clash Premium. Mihomo, Clash Rust and Meow each come with a separate stable choice and an Alpha choice; Clash Premium is listed without that split.

Around the core, the app handles everything you would otherwise do by editing files: organizing local profiles and subscriptions, managing proxy providers and rule providers, switching proxy groups, and inspecting what is going through the proxy. The interface follows Material You, with configurable themes, light and dark modes and animated navigation, and the home dashboard is built from widgets for traffic, connections, proxy shortcuts, profiles and providers that you arrange yourself. The project is distributed under GPL-3.0 and acknowledges Clash Verge and Clash Verge Rev as work it builds on.

The selected core, not the app, decides what works

Because the app is a manager for interchangeable cores, its capabilities are not fixed. Core capabilities vary, and the core you select determines which protocols and runtime features are available. Picking a core is therefore picking a feature set, and the app does not paper over the differences between them.

The consequence for a new user is that the order of the setup steps matters. The getting-started flow is: download a package for your platform, import a local profile or add a subscription, then select a compatible core, and only after that choose a proxy group and enable system proxy or TUN mode. If a connection fails after import, the first thing to check is whether the core you picked understands everything in that profile, before suspecting the subscription itself. Switching to an Alpha core to get a feature means accepting a less settled build of the component that carries all your traffic.

Rewriting profiles with YAML, JavaScript and Lua

Subscriptions from a provider are often not exactly what you want: extra rules, a missing proxy group, a chain you would like to add. Clash Nyanpasu handles this through configuration enhancement, which merges and transforms profiles using YAML, JavaScript or Lua. You pick the language that suits the change: declarative YAML, or a script in JavaScript or Lua.

The profile enhancement guide on nyanpasu.org, under tutorial/proxy-chain, covers how to set these up. The practical benefit is that you can keep a provider's subscription untouched and layer your own changes on top, instead of hand-editing a downloaded file that the next update would overwrite. The cost is that a script error now sits between the subscription and the running core, so a broken transform is one more place to look when a profile stops loading.

Connections broken down by process, rule and exit

The inspection side of the app goes further than a live connection list. Connection inspection shows both active and closed connections, with the originating process, the destination and the routing information for each. Traffic analysis then aggregates history and usage by process, target, rule and exit, and presents it as rankings, connection paths and geographic views.

This answers questions that are hard to answer from a core's log alone: which application is responsible for most of the traffic through a given exit, which rule is catching a destination you expected to go direct, or where a particular process is actually connecting. For anyone debugging a rule set, being able to see closed connections alongside the rule that matched them is the most direct way to confirm whether routing behaves as intended.

System proxy and TUN mode from the same toggle area

Clash Nyanpasu manages both ways of sending traffic into the core from inside the application: setting the operating system proxy, and TUN mode. You choose a proxy group and then enable system proxy or TUN mode as needed, without editing OS network settings by hand.

Both modes are controlled from the app, but what the selected core supports at runtime still applies here, as it does to protocols. Per-platform setup details are in the installation guide at nyanpasu.org/tutorial/install, and the FAQ at nyanpasu.org/others/faq is the next stop when a mode does not behave as expected. If something is not going through the proxy, the per-process view in connection inspection is where you can confirm whether that program's traffic reaches the core at all.

Version 2.0 landed with a point release four days later

The current line is new. Clash Nyanpasu v2.0.0 was released on 2026-10-27 and v2.0.1 followed on 2026-10-31, and the monorepo package.json now reports version 2.0.1. The last push to the repository was on 2026-10-31, so the project is under active development.

For users, a major version followed so quickly by a fix release means it is worth reading the release notes before upgrading a working setup, and keeping the previous installer until the new one behaves. Development builds are published separately under the pre-release tag on GitHub, labeled Clash Nyanpasu Dev, for those who want changes before they reach a tagged release. Issues go through the repository's issue templates, and the project asks reporters to search existing issues first and to include the steps and logs needed to reproduce the problem.

Building from source needs submodules and a pnpm workspace

Platform prerequisites are listed in CONTRIBUTING.md, and the development standards in docs/development/README.md are meant to be read before changing code. Once the prerequisites are installed, the sequence is:

git submodule update --init --recursive
pnpm install
pnpm run prepare:check
pnpm dev

The submodule step comes before any install. `pnpm dev` runs `tauri dev` against backend/tauri/tauri.conf.json. Other scripts in package.json show the build variants: `build:nightly` uses tauri.nightly.conf.json, `build:debug` enables the verge-dev and deadlock-detection features and turns the updater off, and `build:profiling` builds without bundling under a profiling profile. The repository also pins its Rust toolchain in rust-toolchain.toml and keeps backend/ and frontend/ as separate top-level trees.

nyanpasu-core is being split out of the desktop app

The desktop app is not the end state of the architecture. Shared backend capabilities are being extracted into nyanpasu-core so that additional frontends can use them, and the architecture guide in docs/development/architecture.md tracks the current separation work. A lint step, `lint:architecture-ledger`, runs a gate script over that ledger.

For contributors this means the boundary between backend and frontend code is moving. A change that touches shared logic should follow where that logic is supposed to live after the split, which is what the architecture guide and the ledger check are there for. For end users, the product today is the Tauri desktop client; additional frontends are the goal of the separation work, so do not choose Clash Nyanpasu on the expectation of one.

Editorial conclusion

Clash Nyanpasu fits desktop users who already have Clash profiles or subscriptions and want one app that switches cores, rewrites configs with scripts and shows which process sent traffic where. It fits less well if you want a fixed, long-settled release, since v2.0.0 and v2.0.1 landed four days apart, or if you need a feature without knowing which core provides it. Before relying on it, confirm that the core you select supports the protocols in your profile, and read the installation guide on nyanpasu.org for your platform.

Frequently asked questions

Official sources

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