v2rayN vs. v2rayNG vs. v2flyNG: Features and Platform Guide

At a glance

For desktop, start with v2rayN. For everyday Android use, try v2rayNG; choose v2flyNG when you need to stick with the V2Fly configuration ecosystem. This guide compares platforms, cores, subscriptions, and routing, then walks through setup on both desktop and Android. The key is not a similar-sounding name, but whether the client’s core fully supports the protocols, transport, and security settings your node requires.

How the three clients differ: start with your platform

v2rayN, v2rayNG, and v2flyNG are tools for managing configurations and connections, not node services. You still need valid node details or a subscription URL. The client stores configurations, starts the core, and controls how traffic enters; the server route, account validity, and network quality are determined elsewhere.

For desktop, start with v2rayN. It offers builds for Windows, macOS, and Linux, making it suitable for managing multiple subscription groups, switching nodes, and adjusting routing. On Android, choose between v2rayNG and v2flyNG. Don’t mix desktop and Android installers, and don’t infer protocol support from a client’s name alone.

Feature	v2rayN	v2rayNG	v2flyNG
Platforms	Windows、macOS、Linux	Android	Android
Core	Can manage different cores; depends on the one selected in the current configuration	Uses the Xray core	Uses the V2Fly core
Subscriptions	Manage and update nodes by group	Subscription groups and node updates	Subscription management and node updates
Traffic handling	Local and system proxy; TUN depends on version and permissions	Android VPN mode, with local proxy mode also available	Android VPN mode, with local proxy mode also available
Best for	Centralized desktop subscription and routing management	Everyday Android connections and Xray configurations	Using existing V2Fly configurations on Android

All three clients are free and open source, but a free client does not mean free server access. The client’s name also says nothing about connection speed: congestion on the same node can vary over time, often making a bigger difference than the interface or management features.

Core and protocol support: check VLESS and REALITY together

V2Ray is often used as an umbrella term for this type of tool, but V2Fly and Xray are separate core projects. VMess, VLESS, Trojan, and Shadowsocks are proxy protocols; WebSocket is a transport; TLS and REALITY are related to connection security. When importing a configuration, don’t just check for “VLESS” support—verify the transport, security mode, and flow control too.

v2rayNG uses the Xray core and suits configurations based on Xray settings provided by your server. v2flyNG uses the V2Fly core, so don’t apply Xray-specific REALITY or Vision settings to it. With v2rayN, check which core is actually selected. The default can vary by version, configuration type, and existing settings, so there’s no single answer that applies to every installation.

v2rayNG: best for everyday Android use

Recommended

Uses the Xray core. If your node requires VLESS, REALITY, or Vision, first check that your client and core versions support it, then enter the settings provided by your server.

Best for: Everyday Android connections and nodes that require Xray features

v2flyNG: keep using V2Fly configurations

Uses the V2Fly core. If you already have a working configuration such as VMess and want to stay within the same configuration ecosystem, first verify subscription parsing and connectivity.

Best for: Existing V2Fly configurations on Android and compatibility testing

v2rayN: centralized desktop management

Manage node settings, subscription groups, and routing from a desktop interface. Protocol support ultimately depends on the core selected by the current configuration and its version.

Best for: Desktop workflows, managing multiple subscriptions, and troubleshooting configuration differences

How to choose: check the complete node configuration first

For a VLESS node, also check whether it uses REALITY and whether the flow control is xtls-rprx-vision. If so, prioritize verifying Xray support rather than repeatedly switching clients in an attempt to make up for missing settings.

Subscriptions: share a URL across devices, but settings won’t sync automatically

A subscription URL is usually an HTTPS address used to retrieve a list of nodes. Share links such as vmess:// and vless:// describe individual nodes instead. Pasting a single-node link into a subscription URL field may cause updates to fail; importing a subscription as a single node won’t create an updatable group either.

In v2rayN, go to “Subscription Group” → “Subscription Group Settings” to add a group, then update the subscription. In v2rayNG, open “Subscription Group Settings” from the top-right menu, save, then select “Update Subscription.” Menu labels may vary by version, but the steps are the same: save the URL, request the list, then select a node to connect. In v2flyNG, make sure you use subscription management rather than the clipboard import option.

Using both platforms: share the subscription, manage local settings separately

Desktop: v2rayN

Create a subscription group named “Everyday routes” and save the full URL.
Run an update manually and note the number of nodes returned and the update time.
Select a working node, then set up the system proxy or configure TUN if needed.

Android: v2rayNG

Add the same subscription URL and confirm that your provider allows multiple devices.
After updating, check the target node’s address, port, and security settings.
Configure per-app proxying separately; desktop routing settings don’t sync to Android.

A shared subscription makes it easy to access nodes from the same source, but refresh timing, server response formats, and device limits can affect the list. Local routing and DNS settings won’t sync automatically.

Subscription URLs often contain access tokens, so store them like account credentials. When asking for help, share only the error type and client and core versions; redact the full URL, user ID, and password. If an update fails, first check for extra spaces in the URL, then determine whether the issue is a network timeout, authentication failure, or parsing error. Don’t start by deleting every group.

Routing and traffic handling: a system proxy doesn’t capture all traffic

Enabling the system proxy on desktop mainly affects apps that follow the system proxy settings. Some apps use their own proxy configuration, while others bypass the system proxy entirely. First check how the app connects instead of assuming the node is at fault. TUN can capture more traffic, but it adds routing, DNS, and permission settings. There’s no need to enable everything at once when getting started.

On Android, VPN mode routes traffic through a virtual network interface provided by the system; it doesn’t change the node’s protocol. Per-app proxy settings determine which apps enter that tunnel, while core routing determines whether traffic is sent direct, proxied, or blocked. These settings work at different levels: apps excluded from the VPN generally won’t be processed by core routing.

For browser traffic only: On desktop, start by testing the system proxy. If the browser has its own proxy settings, check whether they override the system settings.
For selected Android apps only: Check whether per-app mode is set to “Proxy selected apps only” or “Bypass selected apps,” then choose the apps.
For domain-based routing: Keep the default rules initially and change one at a time; rule order affects which rule matches.
If only certain domains fail: Check DNS and connection logs instead of relying only on node latency.

For example, if you add a browser to the “bypass” list, it uses your local network by design—that doesn’t mean the proxy is broken. Likewise, adding it to an “only proxy” list doesn’t mean all background apps are routed through the proxy. For more on setup, see the user guide. If you have connection issues, start with connection troubleshooting.

First connection checks: distinguish local and server ports

The server port in a node’s settings connects to the remote service; the local listening port in the client’s settings is for apps on your device. They don’t need to match. The numbers below are specific troubleshooting examples, not shared defaults for all three clients. Check the current settings and startup logs for the actual values.

10808

Example: local SOCKS listening port

10809

Example: local HTTP port enabled separately

443

Example: server port for the node; use the value from your provider

Record your environment. Open the client’s About or version information and note the client version and core version separately; they are not the same number.
Check listening ports. In v2rayN, go to “Settings” → “Parameter Settings” to check local listening options. Some versions use a mixed port instead of providing two separate ports.
Start a node. First check that the core starts successfully. If the log shows address already in use, check for a local port conflict.
Check the app’s proxy settings. If you enter the proxy manually, the address is usually 127.0.0.1. The port must match the actual listening port, and SOCKS and HTTP proxy types are not interchangeable.
Then check the remote connection. If the core is running but the handshake still fails, check the server address, port, user ID, SNI, and security settings.

Client FAQs: importing configurations, speed, and background connections

I already use v2rayN on my computer. Do I need the same client name on Android?

No. Start with v2rayNG on Android and import a subscription format supported by your server. Check that the protocol, transport, and security settings match for the same node. Desktop system proxy, routing, and DNS settings need to be checked separately on Android.

Can v2flyNG import nodes that use REALITY?

Don’t treat a successful import as proof of compatibility. REALITY is an Xray-related feature, so use a client and core that support it, and verify the public key, short ID, server name, and flow control. If any fields are missing, ask your node provider for the complete configuration.

Will switching to v2rayNG always make the connection faster than v2flyNG?

There’s no way to tell from the client alone. For a fair comparison, use the same server, network, and test resource, then run three downloads on each device and record throughput and disconnects. Results from different protocols or exit routes can’t be attributed directly to the client, and a single latency reading doesn’t represent download speed.

My connection drops when my Android screen locks. Should I reinstall the client?

First, check background restrictions under system “Settings” → “Apps” → the client → “Battery,” and allow background activity using the options available on your device. Then check whether the system is stopping the VPN service. Test with the screen both on and locked after making changes; don’t change the node and routing at the same time.

My subscription updates, but none of the nodes connect. What should I do?

A successful update only means the subscription request worked. Select a node and check the core startup log, then verify your device time and account status. If only nodes using REALITY fail, focus on core support and the relevant settings. If the error mentions a local listener, troubleshoot the port first.

To get started, install the version of v2rayN for your desktop platform and try v2rayNG for everyday Android use. Test v2flyNG only if you specifically need the V2Fly configuration ecosystem. Get one node, one app, and one traffic entry method working before adding routing rules, automatic updates, or multiple devices. This keeps troubleshooting manageable.