For desktop, start with v2rayN. On Android, choose between v2rayNG and v2flyNG based on your node requirements. Similar names don’t mean the apps use the same core or accept interchangeable configurations. This guide compares platforms and cores, reviews settings for VLESS, REALITY, and VMess, then walks through subscriptions, traffic routing, and migration checks. It’s for anyone choosing a client for the first time or switching devices.
Start with the platform: desktop and Android use different apps
v2rayN is a desktop client for Windows, macOS, and Linux. v2rayNG and v2flyNG are Android clients; the former uses the Xray core, while the latter uses the v2fly core. All three provide a front end for managing configurations: the interface imports subscriptions, selects nodes, and generates configs, while the core establishes connections and applies routing. Don’t infer protocol support or connection speed from whether the name includes a “G.”
| Client | Platforms | Core | What to check first |
|---|---|---|---|
| v2rayN | Windows、macOS、Linux | Can manage different cores; the one in use depends on the node type, settings, and version | Package architecture, core in use, system proxy or TUN |
| v2rayNG | Android | Xray core | Xray-specific settings, VPN permission, per-app routing |
| v2flyNG | Android | v2fly core | Compatibility with the current v2fly version and supported config import formats |
On Windows, v2rayN Desktop and WPF are different interfaces, not different node protocols. On macOS, check whether your Mac has Apple silicon or an Intel processor. On Linux, check the package format for your distribution and your processor architecture. For Android, choose a package that matches your device; if you’re unsure about its architecture, look for the universal option in the download center. If installation fails, check the platform and architecture before changing server settings.
- Desktop work or managing many nodes: start with v2rayN, then choose the installer for your system.
- Android node uses Xray-specific settings: first check whether v2rayNG supports them.
- Already have a verified v2fly config? Choose v2flyNG to keep your existing setup.
Cores and protocols: don’t stop at VMess or VLESS
A node usually combines a protocol, transport, and security layer. With a VLESS node, for example, recognizing the vless:// link is only the first check. You also need to verify the transport, TLS or REALITY, server name, fingerprint, and flow. If even one setting isn’t supported, the node may import successfully but fail to connect. Seeing a name in the subscription list only confirms that some of its data was parsed.
| Node requirements | How to choose | What to check after import |
|---|---|---|
| VMess + WebSocket + TLS | Check the actual core version in each client; this alone doesn’t prove one will be faster | Address, port, UUID, Host, path, and server name |
| VLESS + REALITY | Prefer an Xray setup that supports this combination; on Android, check v2rayNG first | Public key, shortId, server name, and fingerprint; set flow as required by the server |
| Trojan + TLS | Check that the current client and core support the node’s transport combination | Password, server name, certificate verification, and transport settings |
| Existing v2fly JSON config | Verify it in a v2fly environment first; don’t import it as a complete Xray config without checking compatibility | Supported fields, inbound ports, routing tags, and DNS settings |
Xray and v2fly share technical roots, but they have evolved separately. REALITY is a feature in the Xray ecosystem, so a config with REALITY settings shouldn’t be treated as a generic v2fly config. Likewise, there’s no need to convert a working VMess node to VLESS just to switch clients. Keep a working setup and consider migrating only when there’s a practical reason.
Choose by how you use it: node management, per-app routing, and config compatibility
There’s no need to rank these three clients across every platform. Desktop users tend to care about subscription groups, batch testing, and system proxy settings. On Android, VPN permission, background activity, and which apps use the proxy are often more important. The recommendation below applies specifically to using common Xray nodes on Android; it doesn’t mean the other clients are unsuitable on their respective platforms.
v2rayN: desktop node management
A good fit for editing nodes in a larger window, organizing subscription groups, and reviewing logs. System proxy and TUN use different traffic-routing methods. Test the simpler system proxy path first, then add routing rules as needed.
Best for: everyday desktop use on Windows, macOS, and Linux
v2rayNG: Xray nodes on Android
RecommendedUses the Xray core. For combinations such as VLESS and REALITY, first check whether the current version supports the required settings. After connecting, traffic is routed through Android’s VPN interface; per-app settings determine which apps are covered.
Best for: using Xray configs on Android and routing traffic by app
v2flyNG: v2fly configs on Android
Uses the v2fly core. If you already have stable v2fly nodes and configs, staying within the same core family can reduce the work involved in migrating settings. Check compatibility before importing any Xray-specific fields.
Best for: continuing to use a verified v2fly setup on Android
Bottom line: test with one node you know works
Import a complete node into the client you plan to use. Confirm that the core starts and that web access and DNS work before migrating subscriptions and routing rules in bulk. If something goes wrong, you can then tell whether the cause is client compatibility, subscription parsing, or a new rule.
Don’t treat latency sorting in the interface as a client performance ranking. The same node can test differently at different times due to network conditions, server load, and the test target. For a fair comparison, keep the node, network, test address, and proxy mode consistent. TCP connection latency also doesn’t measure actual download throughput.
How traffic is routed: system proxy, VPN, and local ports
v2rayN’s system proxy mode mainly affects apps that follow the system proxy settings; it doesn’t automatically route every program. TUN routes traffic through a virtual network interface and usually covers more apps, but it can also introduce permission, DNS, and routing issues. If you’re new to the client, test the system proxy first and only use TUN if you need it. Avoid changing several things at once.
These two port numbers are examples for troubleshooting, not shared defaults across all three clients. Some versions use a single mixed-protocol listening port, so don’t split it into two ports based on an outdated guide. In v2rayN, check the local listener settings under Settings → Parameter Settings; menu names may vary by version. Then use the startup log to confirm the listening address. When configuring an app manually, make sure its proxy type, address, and port match the listener.
- Make sure the core starts without errors or port conflicts before connecting an app to the local proxy.
- On the same device, use
127.0.0.1to connect locally. On a phone, that address points to the phone itself, not your desktop computer. - Don’t enable LAN access just to fix a connection issue. Using the proxy from another device also requires checking the listening address, firewall, and access controls.
- The first time you connect on Android, approve the system VPN prompt. Before switching between v2rayNG and v2flyNG, stop the current VPN connection so you can tell which client is active.
On Android, “Connected” means the VPN interface is up, not that the remote node is working. If your browser works but another app doesn’t, check whether per-app routing is set to “Proxy selected apps only” or “Bypass selected apps.” The same app list means opposite things in these modes, so confirm the mode before changing the list.
Share subscriptions between desktop and Android—not the entire config
A subscription link usually provides a list of nodes; it doesn’t sync system proxy settings, VPN permissions, per-app lists, or all routing rules. You can use the same subscription on both devices as long as each client can parse the returned format and its core supports the node settings. Don’t overwrite one client’s full runtime JSON config with a config generated by the other.
Setup approach: use the same node source, manage traffic routing separately
Desktop: v2rayN
- Save the subscription URL under Subscription Groups → Subscription Group Settings.
- Select “Update current subscription (without proxy),” or update through the proxy if your network requires it.
- Select a node, then confirm the system proxy mode and current routing rules.
Android: v2rayNG or v2flyNG
- Add the same subscription source in the subscription settings, then update it using the menu for your app version.
- Test one node first, then configure per-app routing.
- Set background activity permissions for your device and keep the logs if the connection drops.
After updating each client, compare node names and settings. Using the same subscription URL doesn’t guarantee identical results or local settings.
Subscription services may return different formats depending on the client, and may include nodes that one client doesn’t yet support. A difference in node count doesn’t necessarily mean the update failed. Check the selected group, any active filters, and the update log first. Then compare the protocols and transport settings of missing nodes. A subscription URL is a credential; redact it in full before sharing screenshots or logs.
- Before migrating, keep a record of the old client’s subscription groups, routing rules, and DNS settings. Don’t delete a working config right away.
- Migrate nodes first, then traffic routing. Check domain rules, IP rules, and rule-set files separately.
- If subscription updates require a proxy, connect through a working node first. On a fresh install with no usable nodes, first make sure the subscription URL is reachable.
Still can’t connect? Troubleshoot by symptom
Switching clients isn’t a universal fix. A connection can fail while fetching a subscription, parsing settings, starting the core, routing traffic locally, or handshaking with the remote server. Identify the failing stage before deciding whether you need a different core. These four common scenarios point to the next steps.
Why does the same subscription show fewer nodes in another client?
Update the current group, clear any node filters, and check the update log. Pick a missing node and see whether it uses REALITY, a specific flow, or a transport the client doesn’t recognize. If it’s a compatibility issue, use a client that supports the combination or ask the subscription provider for a compatible format instead of repeatedly overwriting the import.
v2rayN shows the node as ready, but is your browser bypassing the proxy?
First check that the core is listening. Then check the system proxy status in the tray menu and whether your browser follows system settings. If you configured a proxy manually in the browser, verify 127.0.0.1 and the actual port. The log message address already in use indicates a port conflict; stop the program using the port or change the port number.
Connected on Android, but some apps still won’t load?
Check the per-app routing mode and app list in Settings, then test the same node in a browser. If no apps work, check the node handshake and DNS logs. If the connection drops only after the screen locks, check battery optimization and background restrictions. Don’t start by changing the protocol, DNS, and routing all at once.
Getting errors for old config fields after switching to v2rayNG?
First check whether you imported a node link or a complete JSON config. Inbound, outbound, DNS, and routing fields in a full config may not work across different cores. Keep the original file and create a minimal node manually in the new client. Once it connects, add settings back one at a time and check the logs to confirm which core is running.
The choice comes down to three steps: identify your platform, check the core and settings your nodes require, then test how the client routes traffic in everyday use. For desktop, start with v2rayN. On Android, choose v2rayNG or v2flyNG based on whether your config needs Xray or v2fly. There’s no need to migrate a stable setup just because the name or interface changed. What matters is whether the client supports all required settings, the logs help pinpoint issues, and apps on your device route traffic as expected.