For desktop, start with the v2rayN package for your platform. On Android, choose v2rayNG for Xray protocol support, or consider v2flyNG if you need to keep using a v2fly configuration. This guide compares platforms, cores, subscriptions, routing, and traffic handling, with steps for checking a shared subscription on both devices. The key is not a similar name, but whether the required node features match the core actually in use.
Choose by platform first, then compare client features
All three are proxy clients, not node services. You still need to import a valid server configuration or subscription after installation. v2rayN is for desktop, while v2rayNG and v2flyNG are for Android. Don't use an Android package on desktop or vice versa, and don't assume configurations are interchangeable just because the names are similar.
v2rayN: the desktop-first choice
RecommendedA good fit for managing subscriptions, nodes, routing, and logs on Windows, macOS, and Linux. Before installing, check which operating systems and processor architectures the current release supports. The classic WPF edition is for Windows and cannot replace desktop packages for other platforms.
Best for: everyday desktop use, managing multiple nodes, and users who need detailed logs.
v2rayNG: the Xray option for Android
Uses the Xray core to handle connections and Android VPN permission to route device traffic. Node selection, subscription updates, and connection controls are grouped in a mobile interface. It's a good fit when you need protocols and transport features supported by Xray.
Best for: everyday proxy use on Android, per-app routing, and nodes that specifically require Xray.
v2flyNG: the v2fly option for Android
Uses the v2fly core. This can be a good fit if you maintain existing configurations in v2fly format and the current core supports their protocols and transports. Don't assume it includes Xray-specific features.
Best for: Android users with a working v2fly configuration who want to keep the same core behavior.
v2rayN is the desktop pick because its configuration tools fit desktop workflows—not because a different interface can increase node bandwidth. For Android, base the choice on the node configuration. If the server parameters rely on Xray, test v2rayNG first rather than importing the same subscription into both clients and guessing at the cause.
Core differences: the same protocol name doesn't guarantee full compatibility
A client stores configuration, presents the interface, calls the core, and sets how the system routes traffic. The core implements protocols, transports, DNS, and routing. V2Ray is a widely used name across this technology ecosystem; v2fly and Xray are separate core projects. Seeing “V2Ray client” doesn't tell you whether a specific feature is supported.
| Client | Platform and core | What to check |
|---|---|---|
| v2rayN | Desktop; can manage different cores, depending on the release package and node type | Check whether Xray or another configured core is actually running; the node type shown in the interface doesn't confirm what's running |
| v2rayNG | Android; Xray core | Check that the bundled Xray version supports the node's requirements, especially newer security and transport parameters |
| v2flyNG | Android; v2fly core | Check protocol and transport support in the current v2fly version; Xray-specific fields won't work directly |
With VLESS, knowing the protocol name isn't enough. Check the transport, security layer, server name, and related authentication parameters too. REALITY is an Xray feature; the fact that v2flyNG can import a link doesn't mean it can connect using the same settings. For VMess, Trojan, and Shadowsocks, check each specific combination as well—don't rely on whether the protocol dropdown contains a matching name.
The available cores and bundled components in v2rayN vary by release. For example, some node types can be handled by Xray or sing-box, but routing and DNS settings may not transfer between cores. When troubleshooting, first confirm the core name and version in the startup log, then check its parameters. Updating the client interface alone doesn't necessarily update an external core in use.
How to decide: check the node's requirements before choosing a client
Break down the server requirements into four parts: protocol, transport, security layer, and authentication parameters. If the target core doesn't support any one of them, stop testing the migration and use a compatible core instead. Refreshing the subscription repeatedly won't add features the core lacks.
Subscriptions and routing: node lists may be shared, but traffic policies need separate setup
A standard subscription usually distributes node settings; it isn't a complete device configuration. Even with the same subscription on both devices, system proxy settings, VPN permissions, DNS, per-app proxying, and local routing rules may differ. So if a connection works on your computer but not your phone, don't assume the subscription is broken.
- Check the input format first. Make sure you have a subscription URL or node share link the client can recognize, not an account sign-in page. Don't import an error message returned by a webpage as node data.
- Then create a subscription group. In v2rayN, the usual path is “Subscription Group” → “Subscription Group Settings”; save the URL and update the relevant group. In v2rayNG, open the main menu → “Subscription Group Settings,” then return to the main screen and update the subscription. Wording may vary slightly by version.
- Test one node. First check that its protocol, address, port, and security parameters are complete, then review the core logs. A successful latency test only shows that a probe can reach the destination; it doesn't guarantee that web requests will work.
- Restore routing rules last. Start with the client's simple built-in rules to verify the connection, then add custom domain rules and per-app settings one at a time. Change only one type of setting at a time, and keep a configuration you can roll back to.
Routing rules take effect after traffic reaches the core. If a browser isn't using the system proxy at all, changing domain rules in the core won't affect it. On Android, per-app proxy settings first decide which apps enter the VPN tunnel; the core then routes that traffic directly, through the proxy, or blocks it. These are separate layers.
Using both devices: share the node source, configure traffic handling separately
Desktop: v2rayN
- Import a subscription you've confirmed is compatible, then select the matching core.
- First, test access in a browser through the system proxy.
- Configure proxy settings separately for terminal tools; consider TUN only if you need system-wide traffic handling.
Android: v2rayNG or v2flyNG
- Confirm that the core supports the subscription's protocols and transports.
- Grant Android VPN permission the first time you connect.
- Verify a basic connection first, then configure per-app access and background permissions.
Sharing a subscription doesn't automatically sync settings across devices. The node lists may also differ depending on when each client updates and which node formats it supports.
Traffic handling and ports: distinguish system proxy, TUN, and Android VPN
v2rayN's system proxy is mainly for apps that follow the operating system's proxy settings. Browsers usually use these settings, while command-line tools may need explicit proxy arguments or environment variables. TUN routes traffic through a virtual network interface, but also involves permissions, routing, and DNS; it isn't a universal fix for connection problems.
On Android, v2rayNG and v2flyNG use VpnService to create a local VPN interface and pass selected traffic to the proxy core. The VPN icon in the status bar means the system tunnel is up; it doesn't confirm that the remote server has authenticated successfully or that DNS and routing are correct. Usually, only one VPN service can be active in a user environment at a time. Stop the current connection before testing another client.
These values are for troubleshooting examples, not universal defaults for all three clients. Some versions use a mixed inbound that accepts multiple proxy protocols on one port; others configure separate ports. Check the local listener settings in v2rayN under “Settings” → “Parameter Settings,” and use the actual listening address in the startup log. If only a mixed port is enabled, don't look for a separate HTTP port that isn't configured.
# Use only if the corresponding inbound is enabled locally; replace the port with the configured value.
# SOCKS example: resolve the destination domain through the proxy
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 https://example.com/
# HTTP example: only for an enabled HTTP or compatible mixed inbound
curl --proxy http://127.0.0.1:10809 --connect-timeout 10 https://example.com/- Local connection refused: first check that the core is running, the port is correct, and no other process is using it.
- Local port connects but the remote connection times out: check the node parameters, network reachability, and server status.
- Command succeeds but the browser fails: check browser extensions, per-browser proxy settings, and system proxy status instead of reinstalling the client right away.
Choosing between the Android clients: test compatibility and background behavior
On Android, establish a baseline with a node you know is compatible, then compare background behavior and per-app routing. Don't change the client, node, and routing at the same time; even if the connection starts working again, you won't know which change fixed it. During testing, note the node name, core version, network type, and error logs. There's no need to share the full subscription URL.
Why does the same subscription work in v2rayNG but not v2flyNG?
First check whether the failing node relies on REALITY or another Xray-specific parameter. Then verify that the transport and security fields in the share link were imported correctly. If it's a core capability difference, keep using the compatible v2rayNG setup; don't remove required security fields just to force an import.
The connection drops when the phone locks. Should I switch clients?
On Android, open Settings → Apps → the client → Battery and check background restrictions. Allow background activity or set the app to unrestricted if your system offers that option. Menu paths vary by manufacturer. Test with the screen on and locked before deciding whether to switch clients.
I only want a few apps to use the proxy. What should I change first?
In the client's Settings, look for “Per-app proxy” and check whether the list means “only selected apps use the proxy” or “bypass selected apps.” Save your changes, stop and restart the connection, then test one selected app and one unselected app. This helps avoid misreading what the list does.
Can I run both clients at once to compare their speeds?
Don't let two VPN services compete for the system tunnel. Stop the first client before starting the second. Test each using the same network, node, and destination, and repeat the tests. Compare actual download performance and logs; a single latency reading isn't enough to judge which core is better.
Battery use can't be ranked by client name alone. Weak signal and reconnects, apps that keep connections open, frequent probes, and actual traffic volume all affect power consumption. For a fair comparison, use the same network for a similar length of time and check the system's battery statistics. Percentages measured under different conditions aren't a sound basis for choosing a client.
Final choice and migration checklist
For desktop, start with v2rayN and verify the full path: the node works, the core starts, and the app uses the proxy. On Android, choose v2rayNG when you need Xray features; v2flyNG is an option if you have a compatible v2fly configuration. There's no need to migrate a stable setup just because the client has a different name or interface.
- Record your working setup. Back up the client settings and note the core, node type, DNS policy, and traffic-handling mode. Backups may contain credentials, so store them securely.
- Make sure the package matches your device. On desktop, check the operating system and architecture, such as x64 or ARM64. On Android, check that the package supports your device. Refer to the download page for specific compatibility details.
- Migrate nodes only; don't add complex rules yet. Import one known-good configuration, test browser access, and review the logs before restoring other settings.
- Restore your usual settings one at a time. Set up subscription updates, routing, DNS, system proxy, or per-app access in sequence. If something breaks, roll back the most recent change.
- Keep the old configuration until testing is complete. Confirm that the connection still works after restarting the device, switching networks, and running the client in the background. Then remove unused configurations and any leftover system proxy settings.
To compare where settings are located, see Client Comparison. For your first setup, follow the Quick Start; for routing and DNS concepts, see the User Guide. Once you've chosen a client, focus on repeatable configuration checks rather than repeatedly importing the same broken settings into all three.