Choose v2rayN, v2rayNG, or v2flyNG for your device. Installers are organized by desktop interface, processor architecture, and distribution format; each client card explains the selection rules.
Your platform choice is preserved in the page URL, so reopening the link returns you to the same panel. Before downloading, confirm the operating system, processor architecture, and package format to avoid mistaking architecture differences for client problems.
Windows offers Desktop and WPF interface implementations. Desktop is the newer cross-platform UI, suited to fresh installations and consistent workflows across desktop platforms. WPF retains the classic Windows interface for users familiar with its menus and window layout.
v2rayN handles subscription management, node selection, the system proxy, TUN, and routing rules. For a first installation, start with Desktop; choose WPF if you need the classic interface or want to preserve an existing workflow. Both entries belong to the same client family; the main differences are the UI technology and interaction layout.
| Check | Recommendation | Details |
|---|---|---|
| Processor architecture | x64 | The Windows installers provided here target common 64-bit Intel and AMD processors. |
| Interface choice | Desktop first | Use Desktop for new installations; WPF is also available if you prefer the classic interface. |
| Post-install configuration | Import a subscription | The installer contains the client only. Node data must be imported through a subscription URL or an individual configuration. |
macOS installers are separated by processor platform. The Apple Silicon build is for Apple M-series chips, while the Intel build is for Intel processors. Both provide the same client features and configuration structure; the architecture choice only determines whether the app can run correctly.
The macOS version uses the same cross-platform interface as the Desktop series and manages subscription groups, nodes, routing, and the system proxy. Check only the chip type before downloading; after installation, subscription import is broadly the same as on other desktop platforms.
| Device information | Installer | Where to check |
|---|---|---|
| Apple M-series chip | Apple Silicon arm64 | System menu → About This Mac → Chip |
| Intel processor | Intel x64 | System menu → About This Mac → Processor |
| Configuration migration | Re-import the subscription | Use the subscription URL to restore groups and nodes, then set routing preferences again for the device. |
Android offers two client families: v2rayNG and v2flyNG. Start with v2rayNG, which uses the Xray core; choose v2flyNG when an existing configuration depends on V2Fly or you need that core ecosystem. Each family provides arm64 and universal installers.
v2rayNG is the primary choice for Android, supporting subscription groups, individual configuration imports, routing, and VPN traffic capture. Most mainstream phones released after 2015 use arm64, so download the arm64 build first; choose the universal version when the architecture is unknown.
v2flyNG uses the V2Fly core and is likewise designed for Android configuration management. It suits users who need V2Fly behavior, already have experience with a corresponding configuration, or want to test the same subscription with a different core implementation. For everyday selection, prioritize arm64 and use the universal build when the architecture is unknown.
| Check | Choose first | Additional notes |
|---|---|---|
| Client family | v2rayNG | For typical setups, use the Xray-core version; choose v2flyNG when V2Fly is explicitly required. |
| Device architecture | arm64 | Most mainstream phones released after 2015 use this architecture, though you can verify it with a device information tool. |
| Unknown architecture | Universal build | The universal package covers more devices and is the safer choice when the architecture is uncertain. |
For Linux, first choose deb or rpm based on the distribution family, then choose x64 or arm64 for the processor. Debian and Ubuntu systems generally use deb; Fedora, RHEL, and compatible distributions generally use rpm. Check the architecture in system settings or with a system information command in the terminal.
The Linux version uses a cross-platform desktop interface for graphical subscription management, node switching, and routing. The package format follows the distribution’s package manager, while the processor architecture determines whether to choose amd64, x86_64, or the arm64, aarch64 files.
ARM desktops, development boards, and server workstations should use the arm64 files. deb packages use the arm64 label, while rpm packages commonly use aarch64; both refer to the same 64-bit ARM architecture range.
| Distribution or architecture | Choose | Common labels |
|---|---|---|
| Debian and Ubuntu family | deb | amd64 or arm64 |
| Fedora and RHEL family | rpm | x86_64 or aarch64 |
| 64-bit Intel or AMD processor | x64 package | amd64、x86_64 |
| 64-bit ARM processor | arm64 package | arm64、aarch64 |
The client name, operating system, processor architecture, and package format answer different questions. Following a fixed order reduces repeat downloads and configuration migration during setup.
Use v2rayN on Windows, macOS, and Linux desktops. Android devices generally use v2rayNG; choose v2flyNG when the V2Fly core implementation is explicitly required. The client platform must match the device, while the same subscription URL can be imported separately on multiple devices.
Common desktop architectures are x64 and arm64. On macOS, check the chip in “About This Mac”; on Linux, check the system architecture; most newer Android devices use arm64. Architecture does not change subscription content, but it directly determines whether the system can load the installer.
Windows Desktop and WPF mainly differ in interface implementation; macOS uses dmg; Android uses an application installer; Linux requires a choice between deb and rpm. Linux users should follow their distribution’s package system rather than judging by filename or file size alone.
The client installer and node subscription are separate layers. After installation, add the URL in subscription settings, update the group, choose a node, and enable the system proxy or TUN according to the required app coverage. Protocol, security layer, transport, and flow parameters must match between the server and client.
Installation only prepares the client. A fully working setup also requires subscription import, node selection, traffic capture, and connection verification; check the client logs and system status at each step.
Obtain the subscription URL from your provider, then create a group in the client’s subscription settings. The group name is for local identification and can reflect its purpose. Save it, run an update, confirm that nodes appear in the server list, and check the logs for subscription parsing or network access errors.
After the subscription update completes, choose a target node from the server list. The subscription supplies the protocol, address, port, and security parameters. When editing a node manually, verify each VLESS, VMess, Trojan, REALITY, and related field to avoid inconsistent parameter combinations.
The system proxy suits desktop apps that follow system proxy settings, while TUN captures a broader range of network traffic. Android clients work through the system VPN interface. Choose one primary capture method first, then use routing rules to define direct and proxied traffic.
After starting, check the client status and logs first. If the connection fails, troubleshoot in this order: local time, subscription validity, node parameters, port usage, and system proxy status. A fixed sequence helps distinguish installation, configuration, and network-environment issues.
These questions cover version selection, architecture detection, and subscription import after installation. For more complete connection troubleshooting and protocol parameter guidance, continue to Troubleshooting and the full documentation.
Try Desktop first for its next-generation cross-platform interface, with menus and settings structured consistently across desktop systems. Choose WPF if you prefer the classic Windows interface and want to keep your existing workflow. Both manage desktop configuration and connections; subscription content can be imported again.
Open “About This Mac” from the system menu and check the Chip or Processor field. Choose Apple Silicon for an Apple M-series chip and Intel for an Intel processor. The deciding factor is processor architecture, not the macOS version or device appearance.
Most mainstream Android phones released after 2015 use arm64, so start with the arm64 build. If the architecture is unknown or the arm64 package is incompatible, use the universal version. Both installers provide the same client features; the main difference is processor coverage.
Android users should generally start with v2rayNG, which uses the Xray core. Choose v2flyNG when you need the V2Fly ecosystem or an existing configuration specifically requires it. When switching clients, re-add the subscription; routing preferences and app-level settings must be reviewed in the new client.
Use deb for Debian, Ubuntu, and derivatives; use rpm for Fedora, RHEL, and compatible distributions. After confirming the format, choose x64 or arm64 for the processor. amd64 and x86_64 usually indicate x64, while arm64 and aarch64 usually indicate 64-bit ARM.
Get the subscription URL from your provider, add it under the client’s subscription group or subscription settings, and update it. When nodes appear, choose one and enable the system proxy or TUN mode as needed. Android clients capture traffic through the system VPN interface.