For Linux, Windows, and macOS desktops, start with v2rayN. On Android, try v2rayNG for Xray features, or choose v2flyNG when your configuration specifically requires v2fly. This guide compares clients, cores, and protocols separately, then walks through importing subscriptions, setting up routing, and verifying a connection. It’s for anyone with a subscription URL who hasn’t decided which client to install.
1. Choose a client for your OS, then check your node requirements
These aren’t three versions of the same app with different skins. v2rayN is for desktop systems; v2rayNG and v2flyNG are for Android. The capitalization in their names doesn’t change which platforms they support, and an Android APK won’t run as a Linux desktop app. Before downloading, check your OS and processor architecture, such as x64 or ARM64. Don’t choose based on whether the filename contains “V2Ray.”
v2rayN: Desktop configuration hub
RecommendedIncludes interfaces for node lists, subscription groups, routing, and logs. The available cores and traffic-capture methods depend on the platform, package, and version. Don’t assume settings shown for one OS apply unchanged to another.
Best for: everyday desktop use and troubleshooting on Linux, Windows, and macOS.
v2rayNG: Android client with Xray
Uses the Xray core and routes traffic through Android’s VPN service. Supports subscription management and per-app proxy selection. To confirm a node will work, check that its core and server configuration are compatible.
Best for: Android devices and nodes that require Xray protocols or transport features.
v2flyNG: Android client with v2fly
Uses the v2fly core and suits setups that already use v2fly configurations. Choose it for configuration compatibility—not because its name is closer to V2Ray or because it’s presumed to be faster.
Best for: Android devices and nodes or configurations confirmed to work with v2fly.
“Recommended” here refers to desktop client selection, not a cross-platform performance ranking. All three clients are free and open source, but that alone says nothing about a connection’s speed or whether node parameters are correct.
2. What the core, protocol, and transport each do
The client provides the interface and manages configuration; the core handles the actual connection. VMess and VLESS are protocols. WebSocket and gRPC are transport methods. TLS and REALITY relate to connection security. Seeing a VLESS link doesn’t mean all three clients can use it: check the transport, security settings, and core support too.
| Feature | v2rayN | v2rayNG | v2flyNG |
|---|---|---|---|
| Platforms | Windows、Linux、macOS | Android | Android |
| Core | Can manage different cores; check the current build and settings | Xray | v2fly |
| VMess nodes | Check the selected core and transport settings | Check transport and TLS settings | Check transport and TLS settings |
| VLESS + REALITY | Use an Xray core that supports this combination and check the fields | Check the bundled Xray version and node settings | Xray REALITY settings can’t be applied as-is |
| Traffic routing | System proxy and local proxy ports; TUN availability depends on platform and version | Android VPN service with configurable per-app routing | Android VPN service with configurable per-app routing |
For example, a VMess over WebSocket + TLS node may require checking the address, port, UUID, WebSocket path, Host, and TLS serverName. VLESS + REALITY may also require a public key, shortId, fingerprint, and flow. Field names vary by interface, but the provider’s parameter requirements don’t. Missing just one setting can leave you with a node that imports successfully but won’t connect.
How to choose: check the complete node configuration first
For a VLESS + REALITY node, first check which Xray core the v2rayN node uses on desktop, or try v2rayNG on Android. Consider v2flyNG only if the server configuration is confirmed to support v2fly. Importing a node successfully doesn’t mean the connection works.
3. Subscriptions can be shared; routing and local settings can’t
A subscription URL usually provides a list of nodes; it isn’t a full backup of your device configuration. The same subscription may work on desktop and Android if both clients can parse its format and support the node protocols. The subscription provider determines whether multiple devices can connect at once and whether there’s a device limit.
Setup: import the same compatible subscription on each device
Desktop: v2rayN
- Go to “Subscription Group” → “Subscription Group Settings,” add a group, and enter the subscription URL.
- Save it and update the subscription. Select a node, then check the system proxy status.
- Save routing rules, local listening ports, and any required DNS settings separately.
Android: v2rayNG
- Open “Subscription Group Settings” from the side menu, then add a name and URL.
- Return to the node list, select “Update Subscription,” and check the node names and count.
- When connecting, approve the system VPN prompt and choose which apps to route through the proxy.
Update each client separately to refresh its node list. Routing, per-app lists, and DNS settings also need to be configured on each device. Menu labels may vary slightly by version.
With v2flyNG, check the parsed subscription first, then review the node settings. If two clients show different node counts for the same subscription, check for unsupported node types, parsing errors, or group filters before buying another subscription. Subscription URLs may contain access credentials, so hide the full URL in screenshots, logs, and support requests.
- Node list: Usually refreshed from the subscription; nodes removed by the server may disappear from the list.
- Routing rules: Choose which destinations connect directly, use the proxy, or get blocked. Don’t assume these rules are included with the subscription.
- Local settings: Ports, system proxy, per-app routing, and TUN permissions are device-specific. Importing the same subscription won’t sync them automatically.
4. Desktop and Android use different routing controls
v2rayN’s desktop interface makes it easy to check nodes, logs, and routing side by side. To get started, open “Settings” → “Parameter Settings” to check local listeners, then choose a suitable system proxy mode. The system proxy only affects apps that follow it; terminals, some games, and apps with their own network stack may not. TUN captures more traffic, but also involves routing, DNS, permissions, and potential conflicts with other network tools. It isn’t a required step for your first connection.
v2rayNG and v2flyNG use Android’s VPN mode to create a local tunnel through the system interface. This doesn’t change the protocol used by the node provider. Per-app settings determine which apps enter the tunnel; domain- and IP-based routing rules determine which outbound route traffic takes once it reaches the core. Treat these as separate layers.
- Start with a narrow scope: On desktop, test an explicitly configured local proxy first. On Android, route a single browser through the proxy before adding more apps.
- Then choose a routing policy: If you need access to a network printer or local service, check that private addresses connect directly as intended. Don’t assume what every rule does based only on a label like “Bypass LAN.”
- Add complexity last: Once the basic connection works, add custom domain rules, per-app lists, or TUN. Change one setting at a time and record the results.
5. Compare with the same tests—not latency numbers
For a meaningful speed comparison, keep the node, network, destination, and test time as consistent as possible. TCP latency measures only part of connection setup; it doesn’t predict download throughput, video buffering, or how quickly complex pages load. Even a difference in Wi-Fi band between a phone and computer can affect results. This guide doesn’t rank clients by speed without controlled test conditions.
- Select the same node on both devices and compare its protocol, transport, TLS, and security settings—not just its display name.
- Run the client’s real-connection or availability test, then open the same HTTPS page. Note where a test fails instead of recording only a millisecond value.
- Check whether app traffic is routed through the proxy. On desktop, use an explicit proxy command to rule out system proxy settings; on Android, check VPN permission and the per-app list.
- Check the logs for parsing errors, connection timeouts, TLS handshake failures, or a local port conflict. Then decide whether to adjust DNS, node settings, or local configuration.
The commands below apply only if SOCKS inbound is enabled locally and the listening port is confirmed as 10808. This is an example port, not a fixed default for every version. Check the actual listener in v2rayN under “Settings” → “Parameter Settings,” then replace the number in the command.
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/socks5h sends the destination hostname to the SOCKS proxy for resolution, making it useful for checking whether this proxy route can complete an HTTPS request. A successful response only proves that this command’s traffic went through the specified proxy; it doesn’t mean all apps are routed through it. If you can’t connect to 127.0.0.1, first check that the core is running and the port matches. Don’t change the remote node yet.
6. Common questions before and after installation
I use v2rayN on my computer. Do I need an Android client with the same name?
No. Keep v2rayN on your computer and choose v2rayNG or v2flyNG on Android based on your node requirements. Import the compatible subscription on each device and configure the routing scope separately. Don’t copy the desktop program folder as if it were an Android configuration package.
Why does my subscription work in v2rayNG but fail in v2flyNG?
Open the node details first and check whether the configuration uses REALITY or otherwise depends on Xray. If so, use a compatible Xray client. For configurations both clients support, such as VMess, check the path, Host, serverName, and error logs.
On Linux, command-line connections work but my browser won’t open pages. Should I switch clients?
Not yet. If an explicit proxy command works, check whether the browser follows the desktop system proxy or has its own proxy configured. Then check v2rayN’s system proxy status, routing, and DNS. This points to a traffic-routing issue, not necessarily a problem with the core.
Can I run two Android clients at once and let them choose the best connection?
Usually not. On Android, only one app can generally use the system VPN service at a time for a given user or profile. Stop the other client before testing, then start the one you’re testing and approve its VPN request. Otherwise, a replaced tunnel may look like a dropped node connection.
My subscription update timed out. Did I choose the wrong client?
First check that the URL is complete and hasn’t expired. Then distinguish between updating directly and updating through a proxy. If you already have a working node, retry the update through the proxy using the client’s available option. If you don’t have a working node, first get an accessible subscription URL or valid configuration.
Bottom line: choose by platform, match the core, then add routing
Start with v2rayN on desktop. On Android, start with v2rayNG for Xray nodes; choose v2flyNG only when you know you need v2fly compatibility. First verify the subscription, connect to a node, route app traffic, and check the logs. Save your configuration and expand your rules only after that—it’s easier to troubleshoot than installing and testing all three clients at once.