For desktop, start with v2rayN. On Android, choose v2rayNG or v2flyNG based on the core your nodes require. This guide is for first-time installs, syncing subscriptions across a computer and phone, or switching clients. It covers platforms, protocol compatibility, traffic routing, and configuration migration—and explains why importing a subscription doesn’t guarantee that its nodes will connect.
1. Choose by operating system, then compare features
Despite their similar names, these aren’t different skins for the same app. v2rayN is designed for desktop systems, while v2rayNG and v2flyNG are for Android. First check your device and package architecture—not screenshots of the interfaces. For desktop, choose the build for Windows, macOS, or Linux, then select x64 or ARM64. On Android, follow your device’s processor and the package requirements.
v2rayN: Desktop
RecommendedOn desktop, it’s convenient to manage subscriptions, switch nodes, and review logs. You can also adjust system proxy, routing, and local listening settings individually. This recommendation is for desktop use; v2rayN is not a replacement for an Android client.
Best for: Everyday connections and configuration management on Windows, macOS, or Linux computers.
v2rayNG: Android and the Xray core
Manage nodes through an Android interface and route selected apps’ traffic through Android’s VPN interface. v2rayNG uses the Xray core. For nodes that require REALITY, check that this client—and the specific version you’re using—supports the required configuration.
Best for: Android devices, Xray nodes, and users who want to choose which apps use the proxy.
v2flyNG: Android and the V2Fly core
Designed for Android setups using the V2Fly core. A good fit for existing V2Fly configurations or nodes that explicitly require this core. Don’t assume every configuration works in both v2flyNG and v2rayNG just because their names are similar.
Best for: Android users with existing V2Fly configurations and workflows.
Package architecture and node protocols are separate concerns. ARM64 determines whether the app can run on your device; parameters such as VMess and VLESS determine how the core connects to a server. If the app won’t install, check your OS and architecture. If it starts but a node fails, check the protocol and network.
2. Cores and protocols: similar names don’t mean compatible configurations
The client provides the interface, manages subscriptions, and calls the core. The core handles connections, transport, and routing. The core used by v2rayN depends on the build, node type, and settings; don’t assume it always uses one specific core. v2rayNG uses Xray, while v2flyNG uses V2Fly—and that difference can determine whether a node works.
| Feature | v2rayN | v2rayNG | v2flyNG |
|---|---|---|---|
| Platforms | Windows, macOS, and Linux; choose the right build | Android | Android |
| Core | Uses the core required by the node and configuration | Xray | V2Fly |
| VMess nodes | Check the selected core and transport settings | Check transport and TLS settings | Check transport and TLS settings |
| VLESS + REALITY | Requires an Xray configuration that supports this combination | Check the bundled Xray version and parameters | Xray REALITY configurations can’t be used as-is |
| Primary traffic entry point | System proxy; TUN in some setups | Android VPN interface | Android VPN interface |
VMess and VLESS are protocols; WebSocket is a transport; TLS is a security layer option. REALITY isn’t a general-purpose speed boost you can enable for any TLS node. The protocol, transport, security layer, and client core must all match what the server requires. Supporting VLESS alone doesn’t guarantee support for every VLESS configuration.
How to check: review the node parameters before switching clients
If a node specifies VLESS + REALITY, check v2rayNG first on Android. On desktop, verify that v2rayN is using an Xray core that supports the configuration. Don’t keep changing ports in v2flyNG to work around a core incompatibility.
3. Importing subscriptions and using two devices: a node list isn’t the whole setup
A subscription usually provides a set of node details, which the client converts into local configurations. Downloading a subscription and seeing nodes in the list only means the subscription was retrieved and parsed; it doesn’t prove a connection will work. The service may also return different content based on the client’s identifier, so the same URL may show a different number of nodes on each device.
- Create a separate group. In common v2rayN interfaces, open “Subscription Groups” → “Subscription Group Settings” and add a name and subscription URL. Menu labels may vary by release.
- Run an update. After saving the URL, update the subscription. On Android, you’ll usually save it under “Subscription Group Settings” in the menu, then return to the main screen and select “Update Subscription.” Follow the options in your version.
- Test a node. Check which node is selected, start the connection, then visit a destination that clearly requires the proxy. A latency result in the node list alone doesn’t prove that browser traffic is being proxied.
- Configure each device separately. Check system proxy settings, Android per-app selection, local ports, and DNS options on each device. Don’t expect a subscription to sync these settings.
Using two devices: share the subscription, configure traffic routing separately
Desktop: v2rayN
- Add the subscription and update it once to confirm the nodes parse correctly.
- Choose a core and routing mode that meet the node’s requirements.
- Check that the system proxy points to the current local listening port.
Android: choose a client based on the core
- First, check whether your subscription allows multiple devices and review any connection limits.
- Import the same subscription, then update it and select a node separately.
- Grant VPN permission, then check which apps are included.
Sharing a subscription avoids entering the same details twice, but doesn’t guarantee that node lists, update times, or local routing settings will match.
Subscription URLs often contain access credentials. Don’t post them in public forums or include the full URL in troubleshooting screenshots. When moving to a new device, add the subscription again if possible. Export a configuration only when you need to preserve manual nodes or complex rules, and check it for sensitive data such as keys.
4. System proxy, TUN, and Android per-app proxying
One of the easiest things to confuse is a successful connection with an app’s traffic actually going through the proxy. With system proxy enabled in v2rayN, only apps that follow the system proxy settings will use it. Some command-line tools and apps that manage their own networking need separate configuration. TUN routes traffic through a virtual network interface, but results still depend on routing, DNS, permissions, and implementation. Enabling it won’t fix every problem.
- Test with the system proxy in a desktop browser first. For example, if the local HTTP proxy listens on
127.0.0.1:10809, apps configured manually should use that address and port. This is an example, not a default for every version. - Check the proxy protocol. If the settings show a SOCKS listener at
127.0.0.1:10808, don’t enter it as an HTTP proxy port. If your version uses a mixed-protocol port, follow the settings for that version. - On Android, check which apps are included. For per-app proxying, confirm whether the mode proxies only selected apps or bypasses selected apps. The same app selection means the opposite in each mode.
- Run only one VPN service at a time. Another VPN service on your Android device may compete for the system interface. When troubleshooting, stop any other VPN connections first.
Per-app proxying determines which apps enter the proxy path; routing rules determine whether connections on that path go direct or through the proxy. They aren’t interchangeable. A browser included in the proxy scope may still connect directly if a domain matches a direct rule. Conversely, an app outside the scope won’t start using the proxy just because you added a domain rule.
5. Ease of use and the cost of switching clients
v2rayN’s desktop lists make it easy to review multiple nodes, groups, and logs, but there are many options—you don’t need to change them all on your first run. Android workflows are more focused, but you’ll still need to understand VPN permissions, battery management, and per-app scope. Fewer menu options don’t mean less troubleshooting or a faster connection.
| Task | What to do first | What to watch for when switching |
|---|---|---|
| First connection | Import the subscription, update it, select a node, and enable the traffic entry point | Recheck the parameters instead of copying only the node name |
| Switching during everyday use | Check the active node and routing mode | Stop the old client before starting the new one |
| Subscription maintenance | Check the update result and number of groups | Local manual changes may be overwritten by an update |
| Migrating rules | Record domains, IPs, outbound actions, and rule priority | Rule files and interface options may not import unchanged |
If your VMess nodes are working reliably and your current client still meets your maintenance and feature needs, there’s no need to switch just because another client has a similar name. Consider migrating if your nodes change to a combination your current core doesn’t support, or if you need a different way to route traffic. Before switching, record your routing, DNS, and app scope, and keep a way to roll back.
For speed tests, keep the node and test conditions consistent
Compare using the same device, network, server, and destination. Run only one client at a time and confirm that both tests use the same outbound route. If one uses the proxy and the other connects directly, the results don’t tell you which client performs better.
6. Common questions and final checks
Can I use the same subscription on a computer and an Android phone?
You can try importing it on both, but first check the provider’s device and simultaneous connection limits. Update the subscription on each device and confirm that the node types work with their respective cores. Sharing a subscription doesn’t sync local settings.
A node works in v2rayNG but fails in v2flyNG. What should I do?
Open the node editor and check the protocol, transport, and security layer. If the configuration includes REALITY or other Xray-specific settings, don’t copy it directly into V2Fly. Use a compatible client or ask the provider for a node configuration that explicitly supports V2Fly.
The subscription updated successfully, but my browser still won’t load anything. What should I check?
Select a node and start the connection first. On desktop, check the system proxy address and port. On Android, confirm the VPN connection is active and the browser is within its scope. Then check the logs for DNS errors, timeouts, or handshake failures instead of assuming the subscription is the cause.
My Android client disconnects when it goes into the background. Should I switch to another one?
First check your system’s battery settings and allow the client to run in the background as needed. Check its connection status in the notification shade. If the service is still running but there’s no internet access, test another network and review the logs. Distinguish a stopped background process from a failed server connection before switching clients.
Narrow your choice down to three questions: What OS does your device run? Which core do your nodes require? Which apps need their traffic routed? For desktop, start with v2rayN. On Android, check v2rayNG for Xray support or v2flyNG for existing V2Fly configurations. Start with a minimal working setup and add routing rules and custom settings one at a time; it’s easier to troubleshoot than migrating every old rule at once.
- Before downloading: check your OS, processor architecture, and node protocol.
- Before connecting: update the subscription, select a node, and check the proxy or VPN entry point.
- Before migrating: record local ports, DNS, routing, and per-app settings.
- When troubleshooting: change one variable at a time and check the logs.