Supports Windows, macOS, and Linux with centralized controls for subscriptions, system proxy settings, routing rules, and TUN mode.
Three clients
Four desktop and mobile platforms
Xray and V2Fly cores
Choosing a client
v2rayN, v2rayNG, or v2flyNG: which should you choose?
Start by ruling out clients that do not support your operating system, then compare the core, routing controls, and traffic-capture method. For desktop devices, start with v2rayN; for Android, v2rayNG is usually the default. Choose v2flyNG only when V2Fly core compatibility is a specific requirement.
Uses the Xray core and offers a straightforward subscription import and connection flow, making it the default choice for Android devices.
Choose it only when an existing configuration clearly depends on V2Fly core behavior; do not install two Android clients simply because their names look similar.
Side-by-side comparison
Check the platform first, then compare configuration features
Platform support is the first filter. v2rayN targets desktop systems, while v2rayNG and v2flyNG target Android devices. Once the platform is clear, compare the core, routing controls, traffic-capture method, and compatibility with your existing configuration.
| Comparison criteria | v2rayN | v2rayNG | v2flyNG |
|---|---|---|---|
| Platform support | Windows、macOS、Linux | Android | Android |
| Primary core | Can work with cores such as Xray and V2Fly; check the current client settings and configuration for specifics | Xray | V2Fly |
| Maintenance status | Actively maintained | Actively maintained | Actively maintained |
| Ease of use | Moderate. There are more options, but subscription, proxy, and routing settings are centralized in the GUI | Low. Import a subscription, choose a node, and start the connection for basic use | Moderate. The basic flow is straightforward, but confirm your core requirements before choosing it |
| Subscription management | Well suited to managing multiple subscription sources, with separate node groups and updates | Supports subscription import and updates for everyday switching on mobile devices | Supports subscription import, with an emphasis on V2Fly configuration compatibility |
| Routing controls | Offers more complete controls for routing modes, custom rules, and system proxy settings | Provides mobile routing and per-app controls in a more compact interface | Provides basic routing controls; rule behavior is handled by the V2Fly core |
| TUN and traffic capture | Supports TUN mode and system-proxy-only operation; understand the permission and routing impact before enabling it | Uses the Android VPN service to capture traffic from the device or selected apps | Uses the Android VPN service to capture traffic; actual behavior depends on the configuration and system permissions |
| Who it is for | Desktop users, people managing multiple subscriptions, and advanced users who need split tunneling or TUN mode | Most Android users and anyone configuring a mobile client for the first time | Android users with existing V2Fly configurations or specific core-compatibility requirements |
Client-by-client review
Real-world differences between the three clients
Similar names do not mean identical roles. The sections below cover initial setup, everyday maintenance, and configuration boundaries to watch.
Top desktop pick
Windows · macOS · Linux
v2rayN: centralized desktop management and routing
v2rayN’s advantage is not one isolated switch, but the way it brings common desktop tasks into one interface. After importing a subscription, you can review subscription groups, update the node list, switch the active node, and enable the system proxy as needed. For finer traffic control, you can also open the routing rules and TUN mode without constantly switching between tools.
For first-time setup, start with the standard system proxy to confirm connectivity. Once browsers and other system-proxy-aware apps work normally, decide whether TUN is necessary. This separates “is the node configuration usable?” from “is system-wide traffic capture working correctly?”, making troubleshooting easier. Users with multiple subscriptions should also give each group a recognizable name and confirm the active subscription source before updating.
v2rayN is also a good fit for desktop users who need custom split tunneling. The GUI helps you confirm the current routing mode, but rule order still needs careful review: a broad rule placed first may capture domains or addresses that should have been handled by later rules. After configuration, test direct-connection targets, proxied targets, and local network access separately instead of treating one successful webpage load as complete verification.
Top Android pick
Android · Xray
v2rayNG: the default choice for Android devices
v2rayNG suits most Android users. The basic flow comes down to four actions: add a subscription, update it, choose a node, and start the connection. The client uses the system VPN service to capture traffic, so Android will show a permission request the first time it starts. Granting permission only allows the client to establish the device-side traffic tunnel; it does not confirm that the subscription is correct. If access still fails after startup, check the node parameters and subscription update result.
Mobile screens leave less room, so routing and per-app controls are more compact than on desktop. For everyday connections, keeping the default routing settings usually makes troubleshooting easier. If some apps should connect directly or specific apps should be excluded, open the per-app settings and adjust them individually. After changing these settings, fully stop the current connection and restart it so the new capture scope takes effect.
Recent mainstream devices usually use the arm64 package. If you cannot confirm the processor architecture, use the universal build. Architecture only determines whether the package matches the device; it does not change the subscription protocol or node quality. If installation fails, first check the Android version, device architecture, and installation source rather than repeatedly changing the subscription to solve an installation problem.
Core compatibility option
Android · V2Fly
v2flyNG: choose it when you specifically need the V2Fly core
v2flyNG and v2rayNG target the same platform, but the deciding factor is core requirements rather than interface preference. When an existing configuration, routing behavior, or server-side parameter has been tested specifically with V2Fly, v2flyNG provides a more direct match. Without that requirement, most Android users will have an easier start with v2rayNG and avoid configuration confusion from keeping both clients installed.
When migrating from another client, do not compare node names alone. Check the address, port, transport, TLS settings, user identifier, and routing rules one by one. A successful subscription import only means the data format was recognized; it does not prove that every parameter suits the current core. If a node imports but will not connect, inspect its protocol and transport parameters before deciding that the issue is a core difference.
If both Android clients remain on the same device, make sure the previous connection has fully stopped before testing, because the system allows only one such service to capture traffic at a time. Keep a brief test record: which client was used, which node was selected, which routing settings were applied, and at what step the error appeared. Only then can you tell whether a change after switching cores came from the client, configuration, or network path.
Choose by use case
Which client fits each usage pattern?
These recommendations cover client selection only and do not replace checking node parameters. If a subscription cannot be parsed, a node times out, or the local network is unstable, troubleshoot the underlying cause before considering a client change.
Four-step decision
Answer these four questions to choose a client
Separating platform, core, and feature requirements prevents choosing the wrong package because client names look similar, and reduces repeated configuration migrations after installation.
-
Which operating system does the device run?
Use v2rayN on desktop systems; on Android, choose between v2rayNG and v2flyNG. If the platform does not match, stop comparing other features.
-
Does the configuration require a specific core?
Without an explicit requirement, Android users should start with v2rayNG; choose v2flyNG when V2Fly behavior is required. On desktop, continue checking the core and settings within v2rayN.
-
Do you need advanced traffic capture?
Choose v2rayN for TUN or complex routing on desktop, and test the standard system proxy first. On Android, adjust the system VPN and per-app settings according to the apps that need to be captured.
-
Do you need to maintain multiple subscription groups over time?
v2rayN is better suited to managing multiple desktop subscriptions. On Android, keep only the subscriptions you need, use clear names for their sources, and check the node list after each update to confirm the expected changes.
Commonly confused concepts
The client, core, and subscription are different layers
A common selection mistake is treating the GUI client, the core that handles connections, and the subscription that supplies node data as the same thing. They handle interface operations, protocol processing, and configuration distribution respectively.
Provides the controls
The client provides controls for subscription updates, node selection, system proxy settings, device VPN, routing, and log viewing. A status showing that the connection has started only means the local service is running; you still need to verify that target traffic is being handled as expected.
Parses and executes the configuration
Xray and V2Fly are related but distinct core implementations. The same protocol name does not guarantee identical extension parameters or routing behavior, so check the complete configuration when migrating clients instead of looking only at the node name.
Delivers nodes in batches
A subscription link usually contains a set of nodes or configurations. After a successful update, check the node list, protocol parameters, and update time. If the list is empty, first investigate the link integrity, response format, and network access rather than blaming the client immediately.