CLIENT SELECTION
Start by filtering out clients that do not match your operating system, then compare core architecture, routing controls, subscription management, and overall complexity. Choose v2rayN for desktop devices and v2rayNG for primary Android devices.
DIRECT ANSWER
These three clients are not interchangeable across the same platform. v2rayN targets desktop systems, while v2rayNG and v2flyNG target Android; the key difference between the latter two is their core ecosystem and configuration compatibility.
Works with Windows, macOS, and Linux. Subscription groups, server switching, routing rules, system proxy, and TUN settings are managed from one desktop interface. v2rayN is the more complete choice for multiple subscriptions, frequent routing changes, or long-term desktop use.
Choose a desktop download →Built on the Xray core, it suits Android users working mainly with VLESS, VMess, Trojan, or Shadowsocks configurations. Import via QR code, clipboard, or subscription, then decide which apps use the proxy for a streamlined daily workflow.
Choose an Android download →Built on the v2fly core, it offers another core option for Android. Test v2flyNG first when existing configurations depend on v2fly behavior or must match a v2fly server setup; most mobile users should still start with v2rayNG.
View v2flyNG downloads →COMPARISON MATRIX
“Supports a feature” does not mean the menus or parameters are identical across all three clients. When moving between devices, transfer the subscription URL or a standard share link rather than copying the entire local setup.
| Comparison criteria | v2rayN | v2rayNG | v2flyNG |
|---|---|---|---|
| Platform support | Windows、macOS、Linux | Android | Android |
| Primary core | Primarily uses Xray, with the Core type managed in the client settings | Xray | v2fly |
| Maintenance status | Actively maintained | Actively maintained | Maintained continuously |
| Learning curve | Moderate. Desktop settings are extensive, and you need to understand system proxy and routing modes | Low. Import a configuration, then connect through the system VPN entry | Low to moderate. The workflow resembles standard Android proxy clients, but verify the required core first |
| Subscription management | Well suited to multiple subscription groups, batch updates, and server organization | Supports subscription groups, updates, and configuration switching | Supports subscription imports, updates, and node selection |
| Routing rules interface | A comprehensive desktop interface for editing rule sets and preset modes | Offers mobile routing settings for domains, IPs, app scopes, and more | Provides basic routing configuration centered on the v2fly core |
| TUN and system traffic control | Supports system proxy configuration and TUN when needed | Uses the Android VPN service to handle traffic, with per-app controls | Uses the Android VPN service to establish connections; advanced features depend on the current client settings |
| Standout features | Subscription groups, routing rules interface, system proxy, TUN, and desktop tray controls | QR code import, clipboard import, per-app proxying, and mobile network switching | v2fly core, standard subscription imports, mobile routing, and connection management |
| Best for | Desktop users, people managing multiple subscriptions, and advanced users who need detailed routing | Everyday Android users, Xray configuration users, and anyone who needs per-app proxying | Android users who specifically need the v2fly core or already have compatible configurations |
CLIENT NOTES
v2rayN’s main value is bringing common desktop tasks into one management interface. Create subscription groups, update server lists, set the active server, then choose system proxy, routing mode, or TUN as needed. Quick-connect users can start after importing a subscription and selecting a server; users who need finer control can continue tuning routing rules, DNS, Core type, and logs.
Desktop settings are deeper than mobile settings, which adds a learning cost. During the first setup, avoid changing DNS, routing, Mux, and TUN all at once. Start with the defaults and confirm that the configuration connects, then add split-routing rules one by one. This makes it easier to tell whether a problem comes from the subscription, server, system proxy, or an extra parameter.
v2rayN is available in more than one desktop interface build. Windows users can choose between the newer desktop interface and the classic WPF interface; macOS and Linux use the cross-platform desktop version. The core tasks are the same, with differences mainly in system integration, implementation, and some workflows. Windows users with a stable setup do not need to migrate just for an interface change; for a new install, the cross-platform desktop version is a reasonable first choice.
v2rayNG offers a straightforward Android workflow: create a server entry from a subscription URL, clipboard content, QR code, or individual configuration, select it, and start the system VPN connection. Built on Xray, it suits common VMess, VLESS, Trojan, and Shadowsocks configurations, as well as server-provided combinations such as WebSocket, gRPC, TLS, and REALITY.
Per-app proxying is one of v2rayNG’s key mobile features. You can route selected apps through the proxy or exclude selected apps instead. Decide which rule direction you need before configuring it; “proxy only selected apps” and “bypass selected apps” are easy to confuse. For a first connection, leave per-app controls off, verify the basic connection, and add app rules afterward.
Android vendors’ background policies can directly affect persistent connections. Battery saving, background limits, sleep-time network policies, and automatic cleanup may all stop the VPN service. If the connection drops after the screen locks, first check v2rayNG’s battery and background permissions instead of immediately changing protocols. Reconnecting after switching between mobile data and Wi-Fi is also easier to troubleshoot than layering on experimental parameters.
v2flyNG’s distinguishing feature is its v2fly core, not its appearance. When the existing server configuration, routing behavior, or documentation is explicitly built around v2fly, staying within the same core ecosystem can reduce parameter mismatches. It retains familiar mobile features such as subscription import, configuration selection, connection controls, and routing settings, making it a compatibility-focused Android option.
Do not assume v2flyNG uses fewer resources simply because a device is older. Actual usage also depends on the protocol, encryption, transport layer, number of routing rules, DNS policy, and background behavior. For an older device, first confirm the CPU architecture and package type, then observe real-world performance with the same server and a comparable configuration. A universal package solves architecture coverage; it does not necessarily reduce runtime load.
If a subscription uses parameters specific to one core, switching clients may cause fields to be ignored, imports to fail, or connection behavior to change. Check the configuration requirements instead of repeatedly editing the server address. For ordinary Android use without a core restriction, v2rayNG is usually the more direct choice; v2flyNG is better suited to users with a specific requirement.
SCENARIO GUIDE
More features do not automatically make a client better for the device at hand. A reliable selection order is: platform match, core compatibility, successful import, and a working basic connection—then TUN, per-app routing, and custom rules.
DECISION PATH
Windows, macOS, and Linux go straight to the v2rayN shortlist; Android users then choose between v2rayNG and v2flyNG. If the platform does not match, further feature comparisons are irrelevant.
Check whether the subscription documentation specifies Xray, v2fly, or a core-specific capability. Without a clear requirement, use v2rayN on desktop and v2rayNG on Android; choose v2flyNG only when v2fly is explicitly required.
Import the subscription, select a server, and establish a basic connection first. Do not enable custom DNS, complex routing, and several experimental settings at the same time. The default state provides a troubleshooting baseline for separating configuration issues from local rule issues.
Configure TUN on a computer only when more traffic needs to be handled; enable per-app proxying on Android only when specific apps need routing. For split routing between domains in mainland China and outside China, add domain and IP rules gradually and monitor the logs.
KEY DIFFERENCES
The client handles the interface, subscriptions, configuration storage, and system connection entry point; the core parses protocols, establishes transport, and applies routing. v2rayNG uses Xray, v2flyNG uses v2fly, and v2rayN exposes Core type settings in its desktop interface. The same share link can usually be parsed by different cores, but core-specific fields still require a compatibility check.
A system proxy mainly affects programs that follow the operating system’s proxy settings, while TUN uses a virtual network interface to handle a broader range of traffic. Desktop games, command-line programs, and apps that ignore system proxy settings may need TUN, but enabling it adds permissions, DNS, and routing conflicts to the troubleshooting list. Start with the system proxy for ordinary web access.
A subscription usually provides server configurations and some parameters, but does not fully sync per-app lists, system proxy state, TUN settings, or local custom routes. When using one subscription across devices, configure local behavior separately on each device. Before updating, record manually edited entries so remote content does not overwrite them unexpectedly.
If one website connects directly, one app fails, or DNS returns unexpected results, common causes include mismatched routing priority, domain matching, IP rules, and DNS policy. Switch to a simple routing mode to verify the server, then inspect custom rules one by one; this is more effective than repeatedly switching between VMess, VLESS, and Trojan.
SELECTION FAQ
Not through the desktop installation method. v2rayN targets Windows, macOS, and Linux; on Android, choose between v2rayNG and v2flyNG. Both device types can import the same subscription, but local routing, system proxy, and per-app settings must be configured separately.
The main difference is the core ecosystem. v2rayNG uses Xray, while v2flyNG uses v2fly. If the subscription or server documentation specifies a core, follow that requirement; without one, v2rayNG is usually the first choice for everyday Android use.
Common standard subscriptions can usually be imported into each client, but compatibility ultimately depends on the protocols, transport layers, and core-specific fields they contain. A successful import does not guarantee that every configuration will connect. When one item fails, check its required core and transport parameters.
Start with the system proxy for basic verification. Configure TUN only when the target program ignores the system proxy or genuinely needs broader traffic coverage. After enabling TUN, also check permissions, the virtual network interface, DNS, and local security software policies.
Choose the core based on the subscription requirements first, then confirm the processor architecture and package type. Device age alone does not determine the client. Protocol, transport method, rule count, DNS policy, and background restrictions also affect resource usage.