v2rayN vs. v2rayNG vs. v2flyNG: Which V2Ray Client Should You Choose?

At a glance

For desktop, start with v2rayN; for everyday Android use, start with v2rayNG. Consider v2flyNG if you specifically need the v2fly core. This guide compares platform support, cores, subscription formats, and traffic routing to help you choose whether you’re installing a client for the first time or moving a setup between your computer and phone. You’ll learn where to download it, how to import your settings, and what to check after connecting.

Platform support: desktop or Android?

Start on the client downloads page. Choose the option for your operating system, then check your processor architecture. v2rayN is for desktop and has release options for Windows, macOS, and Linux; available installers and features vary by package. v2rayNG and v2flyNG are for Android, not desktop systems.

All three are free, open-source clients, but similar names don’t mean they serve the same purpose. The client manages nodes, subscription updates, and the user interface; the core parses connection settings, establishes connections, and applies routing. First check that the client runs on your device, then make sure its core supports your configuration.

Comparison	v2rayN	v2rayNG	v2flyNG
Platforms	Windows, macOS, and Linux desktop	Android	Android
Core	Supports multiple cores; actual support depends on the package, node, and settings	Xray core	v2fly core
Typical traffic routing	Local proxy ports and system proxy; Tun can be configured if needed	Android VPN service and per-app proxy	Android VPN service; settings vary by version
What to check first	Know the difference between node, system proxy, and routing status	Grant VPN permission and check background restrictions	Confirm the configuration targets v2fly and check supported fields

On Android, find your system details under Settings → About phone, then check the download page to confirm your device architecture. The phone’s brand alone won’t tell you which package to install. Desktop users should check processor architecture too—not just the operating system. If your current client works reliably, there’s no need to switch just because another client has a similar name.

Cores and protocols: choose based on your configuration

Check the Protocol, Transport, and TLS fields in your node settings before choosing a core. VMess and VLESS are connection protocols; WebSocket is a transport, while TLS and REALITY are separate security options. They operate at different layers and can’t be substituted for one another by simply toggling a setting.

v2rayNG: a solid starting point for Android

Recommended

Designed for everyday Android use and powered by the Xray core. If your subscription uses VLESS with REALITY, first check that the client and core version support all the required settings.

Best for: your primary Android device or setups with Xray configuration instructions from your provider

v2rayN: desktop configuration management

A good fit for managing subscriptions and routing from your desktop. After importing, confirm which core each node uses. Support for multiple cores doesn’t mean every configuration is automatically compatible.

Best for: everyday desktop use and setups where you need to check local ports and system proxy settings

v2flyNG: for specific v2fly requirements

A good fit if you already have a working v2fly configuration and its maintenance instructions. For settings specific to Xray, check support first; changing the protocol name won’t convert the configuration.

Best for: Android devices with an existing v2fly configuration that need to stay in the same core family

Bottom line: check the full configuration before switching clients

Check the protocol, transport, security options, and current core version together. Change the client or core only if you find a specific unsupported field. The VMess or VLESS label alone doesn’t tell you whether a connection is compatible.

Core families aren’t a speed ranking. Performance on the same server can vary with network conditions, transport settings, server load, and your local connection. Without testing under the same conditions, don’t attribute a single speed-test result to the client’s name.

Importing subscriptions: shared links, separate settings

In v2rayN, add a subscription URL under Subscription group → Subscription group settings, then use the subscription update option to fetch nodes. In v2rayNG, add the URL under Subscription group settings in the side menu, then return to the main screen and update subscriptions from the menu. Menus may vary by version, so look for the same feature name. In v2flyNG, use the subscription management option in the current interface.

The same URL may not return the same results in all three clients. A subscription service may generate different formats based on the requesting client, or require you to choose an output format in its control panel. If import fails, first check that the response is a supported node list—not a login page, error message, or a different configuration format.

Create a separate group first. Keep the original group when migrating, and import into a new test group so you don’t overwrite nodes that still work.
Spot-check a node. Verify the address, port, user ID, transport, and security settings. Matching node counts don’t guarantee that all fields were imported.
Select a node again after updating. Entries removed or renamed by the provider may invalidate your previous selection.
Migrate local settings separately. Routing rules, DNS, system proxy settings, and per-app lists usually aren’t included in a standard node subscription.

If the import looks fine but connections still fail, check the individual fields in the node editor instead of repeatedly updating. Some client-specific configurations include local inbound and routing structures, so they can’t be used as universal node links across devices. Keep the original configuration and re-import it in a format supported by the target client.

Routing and ports: distinguish traffic entry from routing rules

On desktop, first check the system proxy status in v2rayN, then go to Settings → Parameter settings to verify the local listening ports. The system proxy affects only apps that use that setting; it doesn’t route traffic from every program. Tun is a separate way to route traffic and requires additional permission and routing checks. On Android, grant VPN permission first, then review the client’s routing settings.

The ports below are examples to help explain manual setup, not defaults for every version. If your client uses a mixed port, HTTP and SOCKS can share one listening port. Use the values shown in the interface or active configuration; don’t change settings just to match these examples.

10808

Example: local SOCKS listening port

10809

Example: local HTTP listening port

Local proxy address: If the program and client run on the same computer, use 127.0.0.1 and the port configured for the local listener.
Remote node port: For example, use 443 if the server specifies it. Enter this in the node settings; don’t use it in place of the local proxy port.
Rule order: Specific direct or proxy rules usually go before fallback rules. After making changes, reconnect and check the logs.
DNS and domain rules: Traffic routing depends on the DNS resolution path, whether apps preserve domain information, and whether the required rule resources are available. Copying a single domain rule doesn’t guarantee a complete setup.

In v2rayNG, configure per-app proxy under Settings → Per-app proxy. Check whether the current mode sends only selected apps through the VPN or bypasses the VPN for selected apps, then choose the apps. The per-app list determines which apps enter the VPN route; routing rules may still send their traffic direct. These are separate settings.

Desktop and Android: configure traffic routing separately

Your computer and phone can use the same subscription, but your provider decides whether simultaneous connections are allowed. A shared subscription doesn’t sync connection status, routing, or per-app lists in real time. The simplest approach is to use the same node source while saving network settings separately on each device.

Setup plan: one subscription, separate checks

Desktop: v2rayN

Import the subscription and confirm the active node and core.
Test your browser with the system proxy first, then check whether other apps need separate settings.
Note the actual local ports and configure routing as needed; don’t enable Tun unless you need it.

Android: v2rayNG

Import the same subscription and grant the system VPN permission.
Check the default traffic routing first, then add per-app rules as needed.
Check background restrictions in your system’s battery settings, then test whether the connection recovers after locking the screen.

After each subscription update, test a node on each device. A working connection on one device only confirms that its current configuration and network route work.

On Android, battery settings are usually under Settings → Apps → v2rayNG → Battery, though some manufacturers put them under background management or auto-start settings. Change only the background permissions you need, then check whether the connection drops after the screen locks. v2flyNG users should also check background restrictions for that app; changing cores won’t override system battery settings.

Common questions after choosing a client

It works on my computer, but the same subscription fails to import on Android. Should I switch clients?

First, check that the subscription URL is complete in the Android subscription group, then review the update log. If parsing fails, check the output format in your provider’s control panel. If nodes import but won’t connect, spot-check the transport and security fields. Switch clients only after confirming that the configuration requires a feature the current core doesn’t support.

v2rayN shows the node as available, so why is one app connecting directly?

First, make sure the system proxy is enabled and check whether the app uses it. If the app has its own proxy settings, enter the current local address and port. If there’s no such setting, consider Tun. A successful node test doesn’t mean the app’s traffic is being routed through the proxy.

I enabled per-app proxy in v2rayNG, but only the selected apps can’t connect. Why?

Go to Settings → Per-app proxy and check whether the app list is for VPN inclusion or VPN bypass. Temporarily disable per-app filtering and reconnect to confirm the basic connection works, then add apps one at a time. Don’t change DNS and routing at the same time, so you can tell what caused the issue.

I already use v2flyNG. Do I have to switch to v2rayNG?

No. There’s no need to switch just because of the name or recommendation order. First confirm that your existing nodes, routing, and background connection all work. If a new configuration specifically requires an Xray feature, keep your existing setup and test it separately in v2rayNG. Android generally allows only one standard VPN service to be active at a time, so stop the other client before testing.

Check these in order: platform and architecture, configuration fields, core support, traffic routing method, matched routing rules, and background status. Change one thing at a time, reconnect, and observe the result. If you still can’t identify the issue, follow the symptoms in Troubleshooting; use the tutorial below if you need a step-by-step walkthrough.