Choose v2rayN first for desktop devices; for everyday Android use, choose v2rayNG with the Xray core. Consider v2flyNG as an Android alternative when you already use a v2fly-based setup, need to compare both cores, or require VMess compatibility. The sections below cover platforms, protocol support, subscription management, routing, and resource use.
Filter by platform first, not by protocol name
The simplest rule is: Windows, macOS, and Linux are desktop platforms, so start with v2rayN; Android is a mobile platform, so choose between v2rayNG and v2flyNG. These are not different editions of one interface, but independent clients built for different platforms and core families.
v2rayN 7.x now uses a cross-platform desktop interface for managing nodes, subscriptions, the system proxy, and routing rules on Windows, macOS, and Linux. Windows users may see different desktop builds, but they are all v2rayN, so there is no need to change your node subscription just because the interface differs.
Both v2rayNG and v2flyNG target Android. Both can import single-node links and subscription URLs, and both can route app traffic through the system VPN interface. The key differences are not whether they can connect, but their bundled cores, protocol support pace, routing details, and troubleshooting workflow.
| Client | Platform coverage | Primary core | Best fit |
|---|---|---|---|
| v2rayN 7.x | Windows、macOS、Linux | Manage desktop cores such as Xray and v2fly | Primary desktop client, subscription management, rule debugging |
| v2rayNG 1.10.x | Android | Xray | Primary Android client, VLESS, fine-grained routing |
| v2flyNG 1.9.x | Android | v2fly | VMess compatibility, v2fly configuration testing |
The core family determines protocol support and configuration parsing
The client handles the interface, subscriptions, and system integration; the core actually processes VMess, VLESS, transport settings, and route matching. v2rayNG uses Xray, while v2flyNG uses v2fly. v2rayN works more like a desktop manager that can call configured cores, giving it broader coverage.
If your subscription is mainly VLESS and includes parameters such as Reality or XTLS Vision, the Xray route is usually the easier choice. That means v2rayN with the Xray core on desktop and v2rayNG on Android. Preserve all key fields in shared links, especially the transport, service name, server name, and fingerprint parameters.
If your existing nodes mainly use VMess with WebSocket, HTTP/2, or TCP, and the server has long been configured around v2fly, v2flyNG still has a clear role. It can also help diagnose cases where the subscription is valid but the two cores behave differently: test the same node in both clients to narrow the issue down to core settings, routing rules, or the system network layer.
Xray core route
RecommendedSupport for VLESS, Reality, and XTLS Vision is more direct, making this the default choice for most current node setups.
Best for: primary desktop use, primary Android use, VLESS nodes
v2fly core route
Best for existing VMess configurations, standard transport combinations, and troubleshooting environments that need to compare v2fly behavior.
Best for: legacy VMess configurations, compatibility checks, core testing
Dual-core desktop management
v2rayN can switch cores according to node and configuration requirements, while logs, ports, and routing rules are easier to inspect in one place.
Best for: multiple subscriptions, mixed protocols, desktop debugging
Similar names do not mean configurations are interchangeable
Common VMess fields are relatively consistent across both cores, but complete JSON configurations are not guaranteed to be interchangeable. Routing objects, DNS objects, outbound tags, and experimental features may differ. Subscription links are usually converted into local configurations by the client, which is safer than manually copying an entire JSON file.
- With a single share link, use the client's “Import from clipboard” function first.
- When a provider gives you a subscription URL, create a separate subscription group instead of pasting the link into the server address field.
- For manual configuration, confirm the target core first, then verify the protocol fields and routing tags.
- If a node connects but carries no traffic, check the core log first instead of repeatedly deleting the subscription.
Subscription management: different entry points, similar workflow
All three clients follow the same basic flow: save the subscription URL, request its contents, parse the nodes, write them to a local group, and let you choose the active node. What affects the experience is the entry point, update method, and error message—not the subscription URL itself.
In v2rayN 7.x, add an address under “Subscription groups” → “Subscription group settings.” After saving, use “Subscription groups” → “Update all subscriptions” to fetch nodes. If the current network can reach the subscription source only through an existing node, choose the update option that indicates “through proxy.” After updating, check the group name, node count, and latest update time.
In v2rayNG 1.10.x, open “Subscription group settings” from the main menu, tap the add button in the top right, enter a label and subscription URL, and save. Return to the node list and select “Update subscription.” v2flyNG 1.9.x follows a similar process; menu labels may vary between patch versions, but adding and updating are still handled from the subscription settings page.
- Copy the complete subscription URL and make sure there are no spaces or line breaks at either end.
- Give the subscription a recognizable label, such as “Work nodes” or “Backup line.”
- Record the node count after the first update. For example, if the server shows 12 nodes, the client should parse 12 entries as well.
- Run a latency test on one node before starting the connection; do not treat the latency result as actual download speed.
- When a subscription update fails, keep the existing group, switch the update method and network first, and avoid repeatedly creating groups with the same name.
Recommended setup: share one subscription across both devices
Desktop (v2rayN)
- Prefer the Xray core
- Manage nodes by subscription group
- Enable the system proxy before testing in a browser
Android (v2rayNG)
- Import the same subscription URL
- Enable per-app proxying as needed
- Test mobile and Wi-Fi networks separately
Using the same subscription source on both devices keeps the node list consistent, but test results, the active node, and routing settings remain stored separately on each device.
Split tunneling: system proxy on desktop, traffic scope on Android
Split tunneling determines which traffic connects directly, which traffic uses a node, and which traffic is blocked. After importing the same subscription into all three clients, node parameters may match, but local routing rules do not sync automatically. When changing clients, migrate the routing logic separately instead of comparing only node counts.
A common starting point in v2rayN is “Settings” → “Routing settings.” For everyday use, begin with the built-in basic rules, then add custom entries for domains, IPs, or processes as needed. The system proxy sends desktop programs that honor proxy settings through the client; evaluate TUN only when broader coverage is needed. Do not change the system proxy, TUN, DNS, and firewall all at once.
Android generally routes traffic through the system VPN interface. Both v2rayNG and v2flyNG support per-app proxying: you can include selected apps in the proxy or exclude local services, banking tools, and apps that should access only the LAN. Reversing the rule direction can leave the browser working while other apps fail, or cause every app to bypass the node.
| Goal | v2rayN focus | Android focus |
|---|---|---|
| Get the browser working first | Start the core and enable the system proxy | Start system VPN routing |
| Direct LAN access | Place private-address rules before proxy rules | Keep LAN bypass rules |
| Proxy selected apps | Use process rules or TUN | Select target apps under per-app proxy settings |
| Check which rules match | Review routing and core logs | Review runtime logs and temporarily disable custom rules |
Keep the ports straight as well. For a manual test setup, set the local SOCKS listener to 127.0.0.1:10808 and the HTTP listener to 127.0.0.1:10809. If a program uses the wrong protocol or port, the core may run normally while the app still cannot connect. Use the client's current parameter page and logs as the source of truth.
Desktop troubleshooting order
1. Core status: running
2. SOCKS endpoint: 127.0.0.1:10808
3. HTTP endpoint: 127.0.0.1:10809
4. System proxy: enabled
5. Routing rules: direct LAN access comes before proxy rules
6. Log check: no port conflicts or configuration parsing errorsFeatures and resource use: the gap is usually smaller than the network gap
Client selection should not be based on speed-test screenshots alone. Variation across times and access networks usually outweighs the processing differences between Android clients. More useful signals are stable startup, complete subscriptions, correctly matched rules, and successful reconnection after sleep.
This article uses a reproducible observation method: import 100 nodes on desktop and the same subscription on Android; close other downloads and start the core 10 times in succession; then visit a direct domain, a proxied domain, and a LAN address. The test uses v2rayN 7.x, v2rayNG 1.10.x, and v2flyNG 1.9.x. The figures illustrate scale and are not fixed results for every device.
On an 8-core desktop, v2rayN takes about 0.7 to 1.1 seconds to parse 100 typical VMess and VLESS nodes. On an Android device with 8 GB of memory, v2rayNG and v2flyNG take about 1.0 to 1.6 seconds. The actual difference is under a second, far less significant than the effect of the subscription server's response time.
If the device shows noticeably higher battery use or disconnects in the background, check background restrictions, the always-on VPN setting, and network switching behavior first. Do not judge battery use by the client name alone. Detailed continuous logging, frequent full-node speed tests, and many long-lived concurrent connections all increase processor wakeups.
- For everyday use, keep only the subscription groups you need and disable duplicates or expired groups.
- Do not put all 300 nodes into an automatic speed-test loop; narrow the list by region or purpose first.
- Enable verbose logging while troubleshooting, then restore the normal log level when the issue is resolved.
- After switching between Wi-Fi and mobile data, first confirm that the active node has reconnected successfully.
Final choice: use simple rules based on device role
For most users, the choice comes down to two lines: use v2rayN on desktop and v2rayNG on Android; use v2flyNG only for v2fly core compatibility, legacy VMess configuration testing, or comparative troubleshooting. This avoids duplicate configuration and makes it easier to tell which core produced a log.
When desktop and Android share a subscription, there is no need to make every setting identical. The subscription delivers nodes; the local client handles system integration, DNS, and routing. Desktop may need a system proxy and process rules, while Android relies more on system VPN, per-app proxying, and background recovery. They are different runtime environments by design.
Which Android client should you choose if you only have VMess nodes?
Start by importing and testing them in v2rayNG. If the nodes come from a clearly v2fly-based configuration or you need to compare logs and routing results between the two cores, install v2flyNG for a second test.
The subscription has nodes in v2rayN, but the Android list is empty. Why?
Open “Subscription group settings” in the Android client and make sure the URL contains no line breaks. Return to the main screen and select “Update subscription.” If the list is still empty, check the response status and parsing errors in the log. Do not enter the subscription URL on the manual node page.
v2rayNG connects, but one app does not use the node. Why?
Check the per-app proxy switch and selection mode under “Settings.” Temporarily disable per-app rules and test again. Once normal operation is restored, add apps one by one to the proxy or bypass list.
The v2rayN core is running normally, but the browser still cannot open pages. Why?
First confirm that the system proxy is enabled, then verify the listening protocol and port on the parameters page. If the manual setup uses SOCKS 10808 and HTTP 10809, the browser extension must use the same protocols and corresponding ports.
Do you need to keep both v2rayNG and v2flyNG installed?
Not for ordinary use. Keeping one primary client makes subscriptions and rules easier to maintain. Install both only for core compatibility testing, using the same node in each client; do not run them simultaneously during testing.
An actionable client selection checklist
- Windows, macOS, and Linux: download v2rayN and complete the initial connection with the system proxy.
- Android with VLESS and Reality nodes: download v2rayNG.
- Android with an explicit v2fly core requirement or legacy VMess configuration testing: choose v2flyNG.
- Subscriptions containing multiple protocols: identify the required core for each node before deciding whether to split them into groups.
- Connection problems: check subscription parsing, core startup, local ports, system integration, and route matching in that order.