Compare the three clients
Use this table to shortlist clients, not to rank performance by feature count. Scroll horizontally on narrow screens to see all columns.
| Category | v2rayN | v2rayNG | v2flyNG |
|---|---|---|---|
| Platform support | Windows、macOS、Linux | Android | Android |
| Core | Can be configured with cores such as Xray and v2fly; support depends on the build and required components | Xray core | v2fly core |
| Maintenance | An actively maintained desktop client; check release notes for your platform before downloading | An actively maintained Android client; features evolve with core and app updates | An alternative for the v2fly ecosystem; check release notes for maintenance and platform compatibility |
| Learning curve | Importing a standard subscription is straightforward; system proxy and TUN require some additional setup | Importing a standard subscription is straightforward; VPN permission and background operation need setup | Similar day-to-day use to other mobile clients; the extra step is checking core compatibility |
| Subscription groups | Useful for managing multiple subscriptions in one place, with groups for viewing, updating, and filtering | Subscription management for switching between configurations on your phone | Subscription management is available; organization options depend on the build |
| Routing UI | A graphical routing interface for editing and reviewing rules on desktop | Routing settings are available; check core field support for complex configurations | Routing capabilities depend on v2fly; check the build to see which settings are editable |
| TUN and traffic handling | TUN mode is available; it requires system permissions and supporting components, and implementation varies by platform | Creates a virtual network tunnel through the Android VPN interface; this is not the same as a desktop TUN toggle | Routes traffic through the Android VPN interface; routing options depend on the core and app settings |
| Best for | Everyday desktop use, managing multiple subscriptions, and troubleshooting rules | Everyday Android use, especially when you need Xray protocol support | Users with existing V2Fly configurations who specifically need v2fly behavior |
| Download | Choose v2rayN for your desktop OS | Browse v2rayNG packages | Browse the v2flyNG alternative |
Rule out compatibility issues before comparing the experience. Being able to read a subscription only means its format can be parsed; it doesn't guarantee that the current core can run every configuration in it. For combinations such as VLESS, REALITY, and Vision, check the client UI, core support, and server parameters together.
Desktop / Recommended
v2rayN: desktop subscriptions and routing
Manage configurations, review logs, and choose how traffic is routed on your computer.
Built for desktop management
v2rayN brings server configurations, subscription groups, routing, and core startup controls together in a desktop interface. If you manage multiple subscriptions, group them by purpose before updating and filtering servers. Checking fields such as address, port, transport protocol, and security layer is also easier than jumping between screens on a phone.
Recommending v2rayN for desktop doesn't mean every app will use a proxy automatically. The system proxy usually affects only apps that honor system settings; use TUN if you need to route more traffic. Before enabling TUN, make sure a standard connection works, then check permissions, DNS, and other network software. Change one variable at a time.
Package choices and feature limits
The Windows download section offers a desktop edition and a classic WPF edition. The desktop edition uses a cross-platform interface, while WPF retains the classic UI. Choose based on interface and runtime requirements, not assumptions about which one connects faster.
For macOS, choose Apple Silicon or Intel. On Linux, check whether your distribution uses deb or rpm, then confirm the processor architecture. Even under the same client name, permissions, tray behavior, and TUN dependencies can vary by platform.
Switching cores doesn't convert protocols. If your configuration uses core-specific extensions, first check that the target core recognizes those fields before switching.
Browse desktop client downloads →Android / Recommended
v2rayNG: everyday Android connections
Based on the Xray core, it's a solid everyday client for Android devices.
Import your configuration and grant system permission
The typical v2rayNG workflow is straightforward: add a subscription, update configurations, choose a server, and connect. The first time you start a tunnel, Android will ask you to authorize the VPN connection. This permission lets the client route traffic through the system interface; it works differently from a desktop system proxy.
If your subscription uses Xray-specific features, v2rayNG is usually the first Android client to consider. But using Xray doesn't eliminate the need to check parameters. The app's built-in core must recognize the server's flow control, security layer, transport, and extension fields. Being able to save an option in the UI doesn't mean the connection is fully configured correctly.
Pay attention to background restrictions on mobile
A connection dropping when the screen locks isn't necessarily a server or protocol issue. Battery-saving settings, background activity limits, and switching between Wi-Fi and mobile data can all affect connectivity. Check the client's background permissions first, then use logs to distinguish network changes, DNS resolution failures, and handshake failures.
The Android download section offers arm64 and universal packages. Choose based on your device's system architecture, not just the processor's marketing name. If you can't determine the architecture, consider the universal package and check the app's system requirements.
Adjust routing and per-app settings for your needs. Avoid changing many rules at once when getting started: verify browser access first, then test other apps one by one.
Browse v2rayNG downloads →Android / Alternative core
v2flyNG: for v2fly configuration needs
Choose it for a specific compatibility requirement, not because the name sounds familiar or you assume it uses fewer resources.
For users already familiar with V2Fly
v2flyNG uses the v2fly core. It can be an Android alternative if you already understand V2Fly configuration and maintain configurations for that core. Compare the protocols and fields you actually use; the two Android clients aren't simply the same app with different names.
Xray and V2Fly share some technical roots, but their development has since diverged. Shared protocol names and configuration concepts don't guarantee that extensions, field semantics, or support timelines match. For REALITY or XTLS Vision configurations, check each feature against the target core and app build. A successful subscription import doesn't prove compatibility.
Run a minimal test before migrating
Keep the working configuration in your current client, then import the same subscription into v2flyNG. Test one configuration with clearly compatible protocols and fields, and check startup logs, DNS resolution, and actual access. This helps separate format issues from core capability issues.
Don't assume it's a lightweight fix for older phones. Battery and memory use depend on connection type, active apps, rule complexity, background restrictions, and how often the network reconnects. Testing on your own device under the same conditions is more reliable than guessing from the core name.
Check the build's release notes for maintenance, minimum system requirements, and support for new fields. Even if your existing configuration works, keep an eye on compatibility with future system updates.
Browse the v2flyNG alternative →Choose a client by use case
Start with your main task, then decide whether you need more complex routing or traffic handling.
New users: change one setting at a time
Choose v2rayN for desktop or v2rayNG for Android. Import a subscription using the standard workflow and verify one connection before exploring routing and traffic handling. If it fails, don't change the core, DNS, protocol, and server all at once, or you won't know what fixed it. See the client setup guide for the full walkthrough.
Advanced users: match configurations to core capabilities
Use v2rayN on desktop to organize groups and review routing and logs; on Android, choose based on the core your configuration requires. Consider v2rayNG first for Xray-specific features, and choose v2flyNG only when you specifically depend on v2fly behavior. For complex setups, document the protocol, security layer, flow control, and DNS path first instead of inferring the solution from the number of UI options.
Multiple devices: share the source, manage each device separately
Desktop v2rayN and Android v2rayNG can use the same subscription source, but group notes, app rules, system proxy, and local DNS settings may not sync with it. Check the active server and routing mode on each device. Also confirm the subscription provider's device limits and concurrency policy so you don't mistake a server-side limit for a client compatibility issue.
Older phones: check the system and architecture first
Check the system requirements and actual device architecture first, then choose arm64 or universal. Start testing with a standard v2rayNG configuration, minimize unnecessary background tasks, and check whether the connection stays up with the screen locked. Consider v2flyNG only if you need v2fly compatibility. On older devices, hardware performance, signal strength, and battery-saving behavior are often better places to start troubleshooting than the client name.
Compatibility limits that affect your choice
Platform, protocol, subscription format, and routing are separate layers; one blanket claim of “support” can't cover them all.
Check subscription format and connection support separately
A subscription distributes configurations in bulk; it isn't a proxy protocol. A client may read subscription contents but not recognize a particular share-link format or extension field. If entries are missing or imported parameters are incomplete, check format parsing first, then confirm that the core supports the relevant feature.
It's also best not to transfer an entire desktop runtime configuration straight to a phone. Local listening addresses, ports, network interfaces, and system permissions vary by platform. When moving between devices, migrate the subscription source first, then configure device-specific options separately.
TUN support doesn't guarantee that all traffic will be routed as expected
TUN and the Android VPN interface get traffic into the client; rules, DNS, and other settings determine where it goes next. If an app can't connect, check which rules match and how DNS is resolved rather than just checking whether the toggle is on.
Running multiple apps that use virtual network interfaces on one device can cause conflicts. For testing, simplify the setup to one traffic-capture method, then re-enable other network tools one at a time.
Client names don't determine connection speed
Connection setup time, sustained throughput, and device battery use are different metrics. Server location, network quality, transport, encryption overhead, and reconnect frequency all affect results. Without consistent test conditions, you can't conclude that one client is always faster or more power-efficient.
A more useful comparison keeps the server, protocol, network, and test workload fixed. Check whether each client starts reliably, maintains access, and recovers after the screen locks or the network changes.
Maintenance status doesn't replace build notes
An actively maintained project doesn't guarantee that every platform and core feature is available everywhere. Before updating, check system requirements, configuration migration notes, and changes to the core you use. If an old configuration stops working, investigate the changes first instead of repeatedly migrating between all three clients.
For more on the differences between VMess, VLESS, security layers, and core families, read the protocol and core reference. Look up individual terms in the glossary.
Which client to choose and where to download
Choose v2rayN for desktop and start with v2rayNG on Android. Reserve v2flyNG for specific core compatibility needs.
If you just want to get a working connection, you don't need to compare every advanced feature first. Desktop users should download v2rayN for their OS and architecture; Android users should start by considering v2rayNG. After importing a subscription, check the server parameters, system permissions, and traffic handling in order. Consider v2flyNG only if you have a real need for different core behavior.
All three clients are configuration and connection tools; installing one doesn't provide a working server configuration. Before downloading, have a subscription or server details you're authorized to use. If a connection fails, check the error and distinguish subscription updates, parsing, handshake, and routing issues before changing settings or switching to a compatible client.