Find installation links for v2rayN, v2rayNG, and v2flyNG, then follow the steps for importing subscriptions, testing connections, and configuring traffic routing. The guides cover desktop and Android clients without requiring an understanding of complex core settings.
Platform links take you to the relevant installation section. The download page further separates processor architectures, desktop interface types, and package formats, while explaining which clients suit each use case. If you are unsure about your system architecture, open the platform page first to review the selection notes before choosing a file.
For desktop use, start with v2rayN. The download page lists both the newer cross-platform desktop interface and the classic WPF interface, making it suitable for users who need subscription groups, system proxy settings, routing rules, and TUN mode.
Go to downloadsOn macOS, use the cross-platform desktop interface of v2rayN. Before installing, determine whether the device uses Apple Silicon or an Intel processor. The download page provides separate links for both architectures and explains how to check the chip type in System Information.
Go to downloadsOn Android, v2rayNG with the Xray core is the usual choice; depending on the service configuration, v2flyNG with the V2Fly core is also available. The download page provides separate arm64 and universal installation links and explains how to choose for common devices.
Go to downloadsLinux desktops can use v2rayN. The download page organizes common deb and rpm packages and lists both x64 and arm64 builds, making it easier to choose according to the distribution's package system.
Go to downloadsv2rayN, v2rayNG, and v2flyNG are all graphical clients, but their platform focus, default cores, and workflows differ. The sections below use three familiar interfaces—subscription lists, automatic updates, and core information—to explain which problems each client is best suited to solve.
v2rayN targets Windows, macOS, and Linux desktops, bringing subscription groups, server selection, system proxy settings, routing rules, and TUN mode into one graphical interface. For a first setup, you typically only need to add a subscription URL, update the group, select an available entry, and enable the system proxy. For finer control, add routing rules by domain or IP. Unlike lightweight tools that offer little more than a toggle, v2rayN suits desktop users who manage multiple subscriptions over time, switch between routing policies, and review runtime logs.
View v2rayN on the download pagev2rayNG uses the Xray core and is suited to managing subscriptions and establishing VPN connections on Android devices. After importing a subscription, the client organizes remote configurations into selectable entries. You can update the current group, test the connection, set an automatic refresh interval, and enable per-app proxying or routing rules as needed. Unlike desktop clients, it hands traffic over to the system VPN interface rather than relying on desktop system proxy settings. For configurations using VLESS, VMess, Trojan, or REALITY parameters, first confirm that the subscription matches the capabilities of the active core.
View v2rayNG on the download pageSupported platform: Android
v2flyNG also targets Android, but uses the V2Fly core. It suits users who specifically need V2Fly ecosystem behavior or already work with compatible configurations. The basic workflow remains the same: import a subscription, select a configuration, start the connection, and review logs, with a learning curve similar to v2rayNG. Look beyond interface appearance when choosing; check the protocols, transport methods, and extensions required by the service configuration. If the subscription provider recommends a specific core, follow that guidance first. Without special requirements, v2rayNG is usually the easier starting point for common newer protocol parameters.
View v2flyNG on the download pageSupported platform: Android
A subscription URL is used to fetch and update configurations in bulk; it is not a server that can be connected to directly. The correct process is to create a group in the subscription settings, paste and save the complete URL, run an update, and then select an entry from the generated list as the active configuration. If the update fails, check in order whether the URL is complete, whether the subscription requires the current proxy to access, whether the system clock is accurate, and whether the client log reports a timeout or parsing error. Automatic updates are useful for long-term maintenance, but after the first import, refresh manually once to confirm that the group name and entry count are as expected. For the full procedure, continue with Getting Started.
Traffic routing belongs to the client or core configuration layer. It selects an outbound route based on conditions such as domain, IP, port, or network type. A common starting point is to keep LAN traffic direct so printers, router admin pages, and local shared devices remain accessible, then add domain categories as needed. Rule order matters: more specific matches should generally come before broader rules, or an earlier condition may capture the request first. GeoIP and GeoSite data provide the basis for classification, but they do not replace judgment about the actual requirements. After making changes, save and reload the configuration, then test both direct and proxied destinations separately.
Do not diagnose connection failures by repeatedly switching entries alone. First confirm that the client started its local inbound port successfully, then check whether the request matched the expected route, and finally look for outbound timeouts, authentication failures, or unreachable destinations. If a browser works but the command line does not, they are usually using different proxy entry points. Enabling the system proxy also does not mean every terminal program will read it automatically. If multiple configurations fail, check local port conflicts, system time, network conditions, and subscription update status first. If only one configuration fails, inspect its address, port, protocol, and transport parameters one by one.
Clients, cores, and subscription services operate at different layers. Understanding their boundaries makes it easier to choose suitable software and quickly determine whether a connection problem lies in the interface settings, core capabilities, or remote configuration.
Project V established an open-source technology stack around proxy protocols, transport methods, routing, and DNS configuration. As the community evolved, V2Fly and Xray became two widely used core families. They retain many related configuration concepts, including inbound and outbound sections, routing rules, and DNS modules, so foundational knowledge transfers between them. Their extension capabilities, parameter details, and release schedules are not identical, however.
A graphical client is not the same thing as a core. v2rayN organizes subscription management, server lists, system proxy settings, and log viewing into a desktop interface, and can call the appropriate core for a configuration. v2rayNG integrates Xray core capabilities with Android's VPN service, while v2flyNG provides a mobile entry point built around the V2Fly core. When a protocol parameter is not recognized, first confirm which core the client is actually using rather than comparing client names alone.
V2Fly Core is commonly released under the MIT license, while Xray-core uses MPL 2.0; graphical clients are released under their own public licenses. These licenses define the boundaries for using, modifying, and redistributing code. Public development also allows the community to discuss and review protocol implementations, configuration changes, and fixes. Open source provides an inspectable engineering foundation, but it does not replace the user's judgment about configuration sources and operating conditions.
The client interface, bundled core, and GeoIP and GeoSite data files may follow different update schedules. Interface updates generally fix workflows and platform compatibility; core updates affect protocol implementations, transport capabilities, and error handling; geographic data updates affect domain and IP classification. When troubleshooting, record which layer changed. This helps avoid mistaking outdated data files for an invalid subscription or blaming the protocol for an interface setting issue.
A subscription URL usually returns a set of encoded or structured connection parameters. The client parses and stores them, then passes them to the core for operation. Whether the subscription refreshes, whether the configuration is recognized, and whether the remote service connects are three separate checks. Choosing a trusted configuration source, storing the subscription URL securely, and regularly removing expired groups will do more to keep configurations clear than frequently changing clients.
Most first-time configuration problems involve platform selection, subscription imports, the scope of proxy interception, and core compatibility. Clarifying these concepts first can reduce repeated installations and aimless configuration changes.
View troubleshooting guidesFor Windows, macOS, and Linux, v2rayN is the usual first choice. It combines subscription management, system proxy settings, routing rules, logs, and TUN mode in one interface. Each platform requires the appropriate architecture and package format; see the installation package page for details.
Adding a subscription only saves its URL; you must run an update once. If the list is still empty afterward, check that the URL is complete, contains no accidental spaces, and has not expired, and confirm whether the update needs to use the current proxy. Network errors in the runtime log often provide further clues.
A system proxy mainly affects applications that actively read the operating system's proxy settings. TUN mode uses a virtual network interface to capture a broader range of traffic, including programs that ignore system proxy settings. Do not combine them casually without understanding the traffic path; start with the system proxy to verify basic connectivity.
Both run on Android; the main difference is their core family. For common newer protocol parameters, start with v2rayNG using the Xray core. If you already have V2Fly configurations or specifically need V2Fly behavior, choose v2flyNG. The required capabilities of the subscription configuration should decide the final choice.
These articles focus on reproducible configuration problems, explaining the order of checks, the relevant client entry points, and ways to verify changes. When an error occurs, start with the topic closest to the symptom, then record log output and configuration changes step by step.
An expired subscription URL, a proxy port conflict, or a subscription that must be updated through the proxy are the first things to check when refreshes fail. The article also explains automatic update intervals in v2rayN and v2rayNG.
Read the full articleGeoIP and GeoSite determine how domains and IP addresses are classified. This article explains what each data source does, where to update it in the clients, and which routing mistakes outdated data can cause.
Read the full articleTUN mode captures traffic at the system layer through a virtual network interface. The article compares its boundaries with system proxy mode and explains common ways to enable it in desktop and Android clients.
Read the full article