New cross-platform interface
v2rayN Desktop
For 64-bit Windows devices that support the newer desktop interface. The download is a compressed archive; extract it, run the installer inside, and follow the system prompts to finish installation.
Choose by device and processor architecture
Use v2rayN on desktop devices, and choose between v2rayNG and v2flyNG on Android. Before downloading, confirm the operating system, processor architecture, and package format instead of repeatedly trying files based only on their names.
Switching platforms updates the anchor in the address bar. Copy the URL with its anchor to return directly to the selected platform.
Windows desktop client
v2rayN offers a newer cross-platform Desktop edition and a classic WPF edition. Both support subscription management, node selection, routing, DNS, the system proxy, and TUN configuration, but their interface technology and workflows differ. New users can start with Desktop; choose WPF if you already know the classic interface or want to keep using it.
New cross-platform interface
For 64-bit Windows devices that support the newer desktop interface. The download is a compressed archive; extract it, run the installer inside, and follow the system prompts to finish installation.
Classic Windows interface
The WPF edition keeps the classic layout and controls. It suits users familiar with the older menus and system tray workflow. Exit the running v2rayN before switching versions so both clients do not modify the system proxy at the same time.
| Check | Recommended | Common points of confusion |
|---|---|---|
| System architecture | Use a 64-bit Windows device. | x64 refers to the processor architecture, not the client version. |
| Interface edition | New users should start with Desktop; choose WPF if you prefer the classic layout. | Do not run Desktop and WPF at the same time. |
| Configuration readiness | Have a valid subscription URL or complete connection settings ready. | Finishing installation does not establish a connection. |
macOS desktop client
macOS packages are split between Apple Silicon and Intel. The same file extension does not mean the packages are interchangeable, so check the device chip or processor first. Choose arm64 for Apple M-series chips and x64 for Intel processors.
Apple M-series chip
For Macs identified as using an Apple chip in System Information. arm64 identifies the processor architecture; it is not directly related to the subscription protocol, node type, or proxy mode.
Intel processor
For Macs whose Processor entry in System Information shows Intel. If you are unsure, open System Information to check the hardware instead of guessing from the purchase year.
| Check | How to choose | After installation |
|---|---|---|
| Chip type | Choose arm64 for Apple M-series chips and x64 for Intel processors. | The chip type determines the installer, not the subscription content. |
| Installation format | Download the matching DMG file and open it using the system installation flow. | When launching for the first time, follow the system prompts to approve app permissions. |
| Proxy scope | Start with one interception method to verify the connection. | The system proxy and TUN cover different traffic scopes. |
Android graphical clients
v2rayNG is the recommended starting point on Android; choose v2flyNG when you specifically need the v2fly kernel path. Both clients provide arm64 and universal packages. Most mainstream phones released after 2015 should use arm64; choose universal if the architecture is unknown or the installer reports incompatibility.
Android first choice · Xray kernel
v2rayNG suits typical Android phones and tablets. Download the arm64 package first; use universal only when the architecture is unclear, arm64 cannot be installed, or broader architecture compatibility is required. After installation, import connection settings by scanning a QR code, reading the clipboard, or adding a subscription URL.
Suitable for most mainstream Android phones released after 2015.
v2rayNG arm64 APK
For devices with an unknown architecture or an incompatible arm64 package.
v2rayNG universal APK
Android alternative · v2fly kernel
v2flyNG uses the v2fly kernel and provides another Android client option. Check compatibility against the protocols and configuration requirements from the service provider instead of inferring connection speed from the client name. When switching clients, re-import the configuration and confirm VPN permissions and app split-tunneling settings.
Suitable for mainstream Android devices using a 64-bit ARM architecture.
v2flyNG arm64 APK
Use when the device architecture is unclear; the file is usually larger than a single-architecture package.
v2flyNG universal APK
| Check | Preferred choice | Keep in mind |
|---|---|---|
| Client | For typical use, start with v2rayNG. | v2flyNG is an alternative client using a different kernel path. |
| Processor architecture | Start with arm64 for mainstream phones released after 2015. | Use the universal version if the architecture is unknown or installation reports incompatibility. |
| Background operation | Allow the client to maintain the VPN connection when needed. | The system’s battery-saving policy may pause background connections. |
Linux desktop client
Linux downloads require checking both the package format and processor architecture. Debian, Ubuntu, and derivatives generally use deb; Fedora, RHEL-based systems, and distributions using RPM package management use rpm. Most PCs use x64, while ARM desktops and development boards should use arm64 according to the system architecture.
Mainstream desktop PC · x64
Choose deb or rpm based on the distribution’s package manager. Do not rely only on the desktop environment name: GNOME and KDE do not determine the package format. Use the distribution and its package manager as the deciding factors.
For Debian, Ubuntu, and their derivatives.
v2rayN x64 deb
For x64 distributions using RPM package management.
v2rayN x64 rpm
ARM desktop device · arm64
Choose this only when the system architecture is confirmed as arm64 or aarch64. The package format still depends on the distribution: choose deb for Debian-based package management and rpm for RPM-based systems.
| Check | Common choices | How to decide |
|---|---|---|
| Package format | Choose deb for Debian-based systems and rpm for RPM-based systems. | Use the distribution’s package management system as the deciding factor. |
| Processor architecture | Most PCs use x64; ARM devices use arm64. | Check the system report for x86_64, amd64, aarch64, or arm64. |
| Proxy settings | First confirm whether the desktop app reads the system proxy. | Proxy behavior may differ between desktop environments and applications. |
Narrow down the platform and architecture first, then choose the client or package format. Following the order below is usually faster than trying packages one by one.
For desktop devices, distinguish Windows, macOS, and Linux first; for Android, continue to the mobile client options. The platform determines the client range but not necessarily the final file, since one platform may offer multiple architectures or package formats.
This page provides x64 packages for Windows; Mac requires a choice between Apple Silicon and Intel; Android mainly offers arm64 and universal packages; Linux provides both x64 and arm64. A mismatched architecture usually prevents installation or launch.
On Windows, choose between Desktop and WPF; on Linux, choose between deb and rpm. This step concerns interface technology or package management, not the protocol parameters in the subscription URL, and it will not automatically improve node connectivity.
If a client is already installed, record the current subscription groups, routing, DNS, system proxy, and TUN settings first. After upgrading, verify that the existing configuration loads correctly before trying new settings one at a time. Changing several variables at once makes connection problems harder to isolate.
Installing the client is only the preparation stage. Usability depends on the subscription content, node parameters, proxy interception method, and local network conditions.
Use a subscription URL from a trusted source, add it to a subscription group in the client, and run an update. Updating the subscription only means that the client retrieved and parsed the configuration; it does not mean every node can establish a connection.
Confirm that the expected entries appear in the list and that the update completed without obvious network or parsing errors.
Select one node with complete parameters for a real connection test; do not modify routing and DNS in bulk at the same time. Connection testing is different from download speed testing, and its result cannot replace real access verification.
Confirm that the client logs show a normal connection process, then check whether the target app actually uses the proxy.
The system proxy suits browsers and desktop apps that follow the operating system’s proxy settings. Coverage depends on app behavior; enabling it does not mean every process will automatically use the client.
Use this first to verify browsers and typical desktop software. Apps with their own proxy settings must be checked separately.
TUN routes a broader range of traffic through a virtual network interface. It usually requires additional permissions and is affected by routing, DNS, and system network components. Verify separately first with the system proxy, then decide whether TUN is needed.
Useful for apps that do not read the system proxy. Preserve the original settings and prepare a rollback plan before enabling it.
Cross-check the client logs, real browser access, and the target app’s behavior. Testing one change at a time makes problems easier to locate than changing the node, DNS, routing, and proxy mode all at once.
Confirm that network settings return to their previous state after closing the client or clearing the system proxy.
This section covers package selection and first-configuration questions. Expand a question to read the recommended troubleshooting order.
Choose Desktop for the newer cross-platform interface; choose WPF if you know the classic Windows interface or want to keep the familiar workflow. Both target similar subscription and proxy configurations, but their layouts and some controls may differ.
Do not run both editions at once. Exit the current client before switching, and confirm whether the system proxy has been cleared or will be taken over by the new client. If an upgrade causes problems, first check whether the original subscription updates successfully, then check routing, DNS, and proxy mode. Do not mistake interface differences for a node failure.
Most mainstream Android phones released after 2015 should use arm64. A single-architecture package contains only the components needed for that architecture, making the choice more targeted. Use universal if you cannot confirm the processor architecture or the arm64 package is reported as incompatible.
The universal edition is not a feature-complete premium version; it mainly supports a wider range of device architectures. Package architecture does not change the subscription protocol or determine connection speed. After installation, import valid settings, grant VPN permission, and manage background restrictions as needed.
Choose Apple Silicon for devices with Apple M-series chips and Intel for devices with Intel processors. Check the Chip or Processor entry on the system device information page before downloading.
Both packages use the DMG format, but their internal program architectures differ. Do not decide based only on the file extension. On first launch, follow the system prompts for app permissions, then import the subscription and verify one proxy method.
Choose deb for Debian, Ubuntu, and derivatives; choose rpm for Fedora, RHEL-based systems, and distributions using RPM package management. The desktop environment name is not a reliable criterion; use the distribution’s package management system.
After confirming the format, check the processor architecture as well. Most desktop PCs use x64, while ARM desktops and development boards may use arm64. If system information shows aarch64, it generally corresponds to the arm64 package on this page.
The client package provides only the graphical interface and runtime components; it does not include a personal subscription or connection parameters. After installation, import a valid subscription or complete configuration, select an available node, and choose the system proxy or TUN according to the target apps.
During verification, first check whether the subscription updated successfully, then whether the client logs show a connection, and finally whether the browser and target app can access the network. A successful test does not mean every app is using the proxy, because apps read system proxy settings differently.