Choose a package by operating system and processor architecture. Use v2rayN on desktop platforms; on Android, choose between v2rayNG and v2flyNG.
After switching platforms, only the matching client, processor architecture, and package format are shown. Version labels and download URLs update from the same release list.
Both packages are for 64-bit Windows. Desktop uses a modern cross-platform UI and suits first-time installations or anyone who wants a consistent desktop interface. WPF retains the classic Windows interface for users familiar with its original menus and workflow.
A Windows desktop graphical client with subscription management, system proxy, routing rules, TUN, and other common features. Start with Desktop for a first installation; choose the classic version if you already prefer WPF.
| Item | Recommendation | How to decide |
|---|---|---|
| Processor architecture | x64 | Open “Settings → System → About” and check the system type. |
| Interface version | Desktop is preferred for first-time installs | Choose Desktop for the modern cross-platform interface; choose WPF to keep the classic menus. |
| Installation permissions | Allow the current user to install apps | If the system requests permission, verify the filename and selected version before continuing. |
Apple Silicon and Intel packages are not interchangeable. Open “About This Mac” from the system menu and check the “Chip” or “Processor” field. Use the arm64 package for M-series chips and the x64 package for Intel processors.
The macOS desktop client uses the DMG format. Both packages provide the same features; only the processor architecture differs. Choosing the correct build helps avoid compatibility issues during installation.
| About This Mac shows | Processor architecture | Matching package |
|---|---|---|
| Apple M-series chip | arm64 | Apple Silicon DMG |
| Intel processor | x64 | Intel DMG |
| Device managed by an organization | Choose based on the device’s actual chip | Also confirm the organization’s app installation policy and network settings permissions. |
v2rayNG is the recommended choice. It uses the Xray core and provides common subscription, routing, and connection settings. Choose v2flyNG when the v2fly core is required. Both clients offer arm64 and universal packages.
An Android graphical client powered by the Xray core. It supports QR-code scanning, importing shared links from the clipboard, adding subscription URLs, choosing routing modes, and viewing connection logs. Most mainstream phones released after 2015 can use the arm64 build directly.
An Android graphical client using the v2fly core, suited to users who specifically need V2Fly ecosystem configurations and behavior. The basic process for importing subscriptions, choosing nodes, and enabling a connection is similar to other Android clients.
| Device profile | Preferred choice | Additional notes |
|---|---|---|
| Mainstream phones released after 2015 | arm64 | Most modern mobile processors use a 64-bit ARM architecture. |
| Unknown device architecture | Universal | The universal package supports more architectures but is usually larger. |
| The arm64 build reports incompatibility | Switch to the universal build | Delete the incomplete installation task first, then reopen the universal package. |
Choose DEB or RPM based on the distribution, then choose x64 or arm64 based on the processor. Ubuntu, Debian, and derivatives usually use DEB; Fedora, RHEL, Rocky Linux, AlmaLinux, and similar distributions usually use RPM.
A Linux desktop graphical client. The main download links provide x64 DEB and RPM packages; ARM64 devices can use the small links for the matching architecture. Before installing, confirm both the distribution’s package format and the processor architecture.
| Distribution or device | Package format | Architecture choice |
|---|---|---|
| Debian, Ubuntu, and derivatives | DEB | Typical desktop computers use x64; choose arm64 for ARM devices. |
| Fedora and RHEL-based distributions | RPM | x86_64 corresponds to x64; aarch64 corresponds to arm64. |
| Unknown processor architecture | Check system information first | Run uname -m in a terminal, then choose the architecture matching the output. |
Download or installation failures usually result from choosing the wrong platform, processor architecture, or package format. Check these three levels in order to avoid repeatedly downloading different files.
Choose v2rayN for Windows, macOS, and Linux. Use v2rayNG on Android by default, and choose v2flyNG when the v2fly core is required. The client name determines the available platforms and package list; do not choose based only on the file extension.
All three clients are graphical tools for importing subscriptions, managing nodes, and configuring system proxies and routing. After installation, you still need to add a valid configuration; installation status and connection status are separate.
x64 is common on Windows PCs, Intel Macs, and most traditional Linux desktop devices. arm64 is common on Apple M-series chips, modern Android phones, and some ARM Linux devices. With a mismatched architecture, the installer may refuse to run.
When Android users cannot identify the architecture, the universal build is an option. Linux users can run uname -m: x86_64 corresponds to x64, and aarch64 corresponds to arm64.
Windows uses the installer inside the archive, macOS uses DMG, and Android uses APK. Linux also requires DEB or RPM based on the distribution; the package format follows the distribution’s software management system.
If you are unsure which Linux format to use, first check the distribution name and its package system. Ubuntu and Debian-based systems generally use DEB; Fedora and RHEL-based systems generally use RPM. After choosing the format, distinguish between x64 and arm64.
The client is only a configuration and connection tool. After installation, continue in this order: import a subscription, choose a server, select a proxy mode, and verify the connection.
View the full usage guide →Complete setup using the installation method for your system. On first launch, watch for system prompts related to network access, the system proxy, or a VPN connection. Confirm that the prompt comes from the current client before continuing.
Copy a valid subscription URL, add a group in the client’s subscription manager, and update it. For a single-node sharing link, use clipboard import or scan its QR code. After importing, the corresponding entries should appear in the server list.
Select a configuration entry as the active server. For ordinary desktop use, start with system proxy and rule mode; on Android, enable the client according to system connection requests. Read the TUN and routing split-tunneling guidance when more application traffic needs to be captured.
After starting the connection, check the client status and logs. For timeouts, configuration field errors, or failed subscription updates, separately inspect the local network, subscription URL, system time, and current server configuration instead of repeatedly reinstalling the client.
Client updates usually do not change the subscription itself, but the interface, core behavior, and default settings may change. Keeping a record of key settings narrows the troubleshooting scope after an upgrade.
Record the client name, proxy mode, routing rules, and active subscription group. If you use manual nodes, custom DNS, TUN parameters, or custom routing rules, save a copy through the client’s configuration management feature first.
Saving only the subscription URL does not preserve every personalized setting. A subscription usually provides the server list; custom routing, app bypass rules, listening ports, and system proxy preferences may be stored in the local configuration.
After launching the new client, first confirm that the subscription groups and server list are present. Then check the active server, routing mode, and system proxy status. Run a subscription update and use the logs to confirm that the configuration loads correctly.
If the new interface moves a menu, find the corresponding entry by function name instead of deleting all configuration. Narrow the issue to installation, subscription, connection, or routing to make the cause easier to locate.
These questions cover versions, chip architecture, package formats, and post-install configuration. For connection and routing issues, continue to the usage documentation and advanced guide.
Try Desktop first: it uses a modern cross-platform interface. Choose WPF if you prefer the classic Windows interface or want to keep your existing workflow. Both are v2rayN, with essentially the same configuration and subscription features.
If you have used a WPF configuration for a long time, record the subscription groups, custom routing, and system proxy mode before upgrading. After switching to Desktop, carefully check setting names and locations; do not assume every interface option is identical.
Open “About This Mac” from the system menu and check the chip or processor field. Download the Apple Silicon build for an Apple M-series chip, or the Intel build for an Intel processor.
The two DMG packages offer the same features; the difference is their compiled architecture. Choosing the wrong architecture may cause the system to report that the app cannot run or requires additional compatibility handling, so check before downloading.
Most mainstream Android phones released after 2015 use arm64, so start with the arm64 build. Use the universal build if the device architecture is unknown, installation reports incompatibility, or broader architecture support is needed.
The universal build supports more architectures, so its installation file may be larger. Both packages belong to the same client version, and subscription management, routing, and connection features are not changed by package architecture during normal use.
Debian, Ubuntu, and derivatives usually use DEB; Fedora, RHEL, Rocky Linux, AlmaLinux, and similar distributions usually use RPM. Choose x64 or arm64 based on the processor as well.
Run uname -m to check the architecture. Choose x64 for x86_64 and arm64 for aarch64. During installation, let the distribution’s software installer or package manager handle dependencies.
The client manages configuration and connections. First import a valid subscription URL or node details, then choose a server, enable the appropriate proxy mode, and test the connection. The installer does not include subscriptions or nodes.
If the list is empty after importing, check that the subscription URL is complete and run an update manually. If the list exists but the connection fails, check the client logs, system time, local network, and current node configuration.