v2rayN: a desktop GUI for Xray and sing-box on Windows, Linux and macOS

What v2rayN is and who it is built for

v2rayN is a GUI client for Windows, Linux and macOS that supports Xray and sing-box and, according to the README, other cores listed in a Wiki page. The project is written in C# and licensed under GPL-3.0. Its audience is people who want a proxy client with a window, menus and a tray icon rather than a command-line core configured by hand.

The README draws one boundary immediately: v2rayN is the desktop version, and readers who want the mobile equivalent are pointed to v2rayNG. That matters because search traffic around this project mixes the two names constantly, and the two are separate repositories. If your target is an Android phone, this repository is not it.

The platform table in the README is the practical starting point. Windows is listed for x64, x86 and arm64. Linux is listed for x64, arm64, riscv64 and loong64. macOS is listed for x64 and arm64. The README links a Wiki page for minimum OS requirements rather than stating versions inline, so the exact floor for each platform lives outside the repository front page.

How the GUI, the cores and the release archives fit together

The architecture implied by the repository is a shell plus pluggable cores. v2rayN itself is the C# application in the v2rayN/ directory; the proxy engines it drives are external projects, Xray and sing-box among them, and the README links a Wiki list of supported cores. The GUI does not implement the proxy protocols. It manages configuration, starts and stops a core process, and exposes the result in a window.

The packaging scripts at the repository root show how releases are assembled per platform family: package-debian.sh, package-rhel.sh and package-osx.sh for the mainstream targets, plus package-debian-riscv.sh, package-debian-loong.sh, package-rhel-riscv.sh and package-rhel-loong.sh for the RISC-V and LoongArch variants. That layout tells you the Linux builds are produced as distribution packages rather than a single universal binary, and that the exotic architectures are handled by separate scripts.

The README also states that release files are signed with GPG to verify authenticity and integrity, with the stated goal of preventing tampering by mirrors, ISPs or CDNs. The fingerprint is published in the README as a 40-character block. That is a deliberate answer to a real problem: proxy clients are exactly the kind of download that gets repackaged by third-party mirrors, and a signature check is the only way to tell a genuine archive from a modified one.

Installing v2rayN and running it the first time

The README does not give a package-manager command. It says to download the latest release from the GitHub releases page, and it links a Wiki page titled Release files introduction for minimum OS requirements. So the install path is: pick the archive matching your platform and architecture from the platform table, download it, and verify it against the GPG fingerprint before running anything.

The README publishes the fingerprint in a text block, and the command it names for checking release files is GPG verification. The fingerprint appears in the README as a 40-character hex string, reproduced here exactly as printed:

7694 5E9F 3E9A 168F 8070 F195 805D 661C
134D FAF6 8903 C199 463C 31E5 AE90 3AE0

Note that the README does not spell out the gpg invocation, the exact archive naming, or the checksum file format. It states only that release files are signed and gives the fingerprint, so treat any specific command you find elsewhere as unverified against this repository.

After extraction, launch the v2rayN executable for your platform. The README does not document the first-run screen, the default listening ports or the initial configuration file, so those details have to come from the Wiki. What the README does establish is that you need a core present for the client to do anything useful, since the proxy work is done by Xray, sing-box or another supported core rather than by the GUI.

When you add a server, the workflow the README implies is configuration first, then start. The README itself gives no example of a share link, a subscription URL or a routing rule, so treat any specific field name you see in a tutorial elsewhere as unverified against this repository.

Where v2rayN stops being the right tool

The clearest limitation is stated by the project itself: this is the desktop version. There is no server component here, no daemon for a headless box, and no mobile build. If you are provisioning a remote Linux machine, the packaging scripts tell you a desktop package exists, but the README does not describe a service unit, a systemd integration or a remote-management interface. Running a GUI on a server you reach over SSH is a poor fit regardless of what the packages contain.

A second constraint is the documentation split. The README is short and largely points elsewhere: the Wiki for usage guides and configuration details, a Wiki page for minimum OS requirements, a Wiki page for the list of supported cores. That is fine for a project of this age, but it means the repository front page cannot answer basic questions such as which core version a given release bundles, what the default inbound configuration is, or how to migrate settings between major versions. The README does not document rollback or downgrade either.

A third issue is distribution. There is no Homebrew formula, no winget identifier, no apt repository and no Flatpak mentioned in the README. Updates mean returning to the releases page and repeating the download and verification. For a tool that sits between your machine and the network, that manual loop is the cost of the design, and it is worth knowing before you commit.

How v2rayN differs from a core-only setup

The obvious alternative is running Xray or sing-box directly, without v2rayN. The difference is not capability in the proxy sense: the same cores do the same work either way. The difference is where configuration lives and who manages the process lifecycle.

With a bare core, you write a JSON configuration, start the binary yourself, and manage restarts, logs and routing rules by hand or through your own scripts. That is reproducible and scriptable, and it is the right shape for servers and for anyone who wants configuration under version control. With v2rayN, the C# application owns that layer: it holds the server list, writes the configuration the core consumes, and starts and stops the process. You trade scriptability for a window you can click.

The practical consequence is that v2rayN is a desktop convenience layer, not a replacement for the core. If your workflow already generates configuration files programmatically, adding a GUI in front of it creates a second source of truth. If your workflow is a person clicking a tray icon to switch servers, the GUI is doing exactly the job it was built for.

Maintenance, licensing and the upgrade path

The repository is not archived, and the last push was on 2026-08-29. Release 7.24.9 is dated 2026-08-29, 7.24.8 is dated 2026-08-22, and 7.24.7 is dated 2026-08-15, so the cadence visible in the release list is roughly weekly. That is a fast-moving project, and the practical cost is that you should expect to re-download archives rather than receive updates through a system package manager, because the README describes no such channel.

The licence is GPL-3.0. For end users running the client on their own machines, that is a familiar copyleft arrangement. For anyone considering embedding v2rayN in a product, or shipping a modified build, the GPL-3.0 obligations around source distribution apply, and the repository's LICENSE file is the authoritative text. This is not legal advice; if the distribution question matters to your organisation, have someone qualified read the licence alongside your intended use.

The GPG fingerprint in the README is also a maintenance surface. Key rotation or a change of signing key would need to be communicated through the README or the release notes, and the README gives no secondary channel for confirming a fingerprint. Check the fingerprint against a second source you trust before relying on a signature check.

Editorial conclusion

v2rayN suits desktop users on Windows, Linux or macOS who want a graphical front end for Xray or sing-box and are willing to read the Wiki for configuration details. It is the wrong choice if you need a headless server component, since the project is explicitly the desktop edition and points mobile users to v2rayNG. Before adopting it, verify the release archive for your architecture against the platform table in the README, and check the GPG signature against the published fingerprint, because the README gives no package-manager or auto-update path.

Frequently asked questions

Official sources

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