For desktop, start with v2rayN. On Android, choose between v2rayNG and v2flyNG based on your node requirements. This guide separates client interfaces, proxy cores, and subscription formats, explains why a subscription can import successfully but fail to connect, and covers setup on both platforms, per-app proxying, and port checks. If you already have node configurations and are considering switching clients, use this guide to see which settings carry over and which need to be configured again.
1. Choose by platform, then compare workflows
The names are similar, but these aren't three skins of the same app. v2rayN is for desktop systems, with server lists, subscription groups, routing, and core settings. v2rayNG and v2flyNG are Android clients that use the system's VpnService to route traffic from selected apps. The clients don't provide nodes, so you'll still need to import server configurations you're authorized to use.
| Client | Platforms | Core | Interface and key features |
|---|---|---|---|
| v2rayN | Windows / macOS / Linux | Choose a core based on version, protocol, and configuration; Xray is common | Server lists, subscription groups, system proxy, and routing settings |
| v2rayNG | Android | Xray core | Node list, VPN service, per-app proxy |
| v2flyNG | Android | V2Fly's v2ray-core | Manage nodes and connections using V2Fly core features |
v2rayN is available with both a cross-platform desktop interface and the classic Windows WPF interface. Menus and feature coverage may differ between them. Before choosing an installer, check your operating system and processor architecture, then find settings in the interface you're actually using. Don't assume the layout in a Windows screenshot applies to every platform.
- Managing multiple subscriptions on desktop: Start with v2rayN to compare node settings, review logs, and adjust routing.
- Connecting day to day on Android: Check the node's protocol and security requirements first, then choose a compatible core.
- Just switching interfaces: Note your current protocol, transport, security layer, and routing rules first, so you don't lose important settings when changing apps.
2. Xray vs. V2Fly: core compatibility matters
V2Ray is often used as a general term for a family of proxy tools. But the core is what reads the configuration, establishes the connection, and handles routing. v2rayN is a management interface, not the same thing as v2ray-core. v2rayNG uses Xray, so don't assume that its name means you should follow configuration instructions for a different core.
VMess is a protocol, WebSocket is a transport, and TLS is a security layer—they operate at different levels. VLESS nodes may also use REALITY. To determine whether a connection will work, check the full set of parameters; seeing “VLESS” in the node list isn't enough. In particular, don't apply Xray-specific REALITY settings directly to v2flyNG.
v2rayNG: the Xray option for Android
RecommendedA good first option to check for everyday Android use. If a node explicitly requires Xray or uses VLESS + REALITY, make sure the app's bundled core supports the required fields, then import the parameters provided by your server.
Best for: Everyday Android connections and nodes with configuration instructions for Xray
v2flyNG: the V2Fly option for Android
Choose v2flyNG when your existing configuration targets V2Fly and its protocol, transport, and security layer are supported by the bundled core. This keeps the configuration semantics consistent. Custom JSON must also be checked against this core's format.
Best for: Android users with existing V2Fly configurations who need to preserve the corresponding core behavior
v2rayN: desktop management and core settings
On desktop, choose a core based on the node's protocol. After switching cores, check the generated configuration and startup logs again. A successful switch doesn't guarantee that every transport parameter is compatible.
Best for: Managing multiple desktop subscriptions and reviewing routing and core logs
Check the configuration first, then choose a client
Ask your configuration provider to confirm the protocol, transport, and security layer, then check that the client's bundled core supports them. If the REALITY public key, server name, or WebSocket path is missing, get the required parameters first instead of installing all three apps and hoping one works.
3. Shared subscriptions don't guarantee identical imports
A subscription link is a way to retrieve configuration data, not a universal compatibility guarantee. Common formats include lists of share links, base64-encoded lists, and JSON designed for a specific core. The client must recognize the outer format and support the protocol parameters inside it. A mismatch at either stage can result in an empty list, missing fields, or a startup failure.
- Check the content type first: Ask your subscription provider whether it offers an output format for your client. A webpage URL, a login page, and a subscription URL that returns node data aren't interchangeable.
- Add a group in v2rayN: A common path is “Subscription Group” → “Subscription Group Settings.” Add a name and URL, then run the subscription update command. Exact menu labels may vary by version.
- Update the list in v2rayNG: Open “Subscription Group Settings” from the menu, save the URL, return to the main screen, and select “Update Subscription.” Saving the URL alone doesn't mean the nodes have been imported.
- Check a representative node: Select a node you plan to use and review its address, port, user ID, transport, and TLS / REALITY settings before connecting.
In v2flyNG, use its own subscription manager and confirm that the returned content is compatible with V2Fly. Native JSON may be a complete runtime configuration containing inbounds, outbounds, and routing—not a standard list of nodes that can be split up. Share links also may not include DNS, split routing, or per-app settings. The same subscription source doesn't guarantee the same behavior on every device.
4. Desktop system proxy and Android VPN mode work differently
v2rayN's system proxy typically routes traffic from apps that honor the system proxy settings through a local proxy port; it doesn't automatically capture every process. Command-line tools, games, and apps that manage their own networking may ignore the system proxy. TUN mode is a separate way to capture traffic. It involves a virtual network interface, routing, and permissions, so it isn't the same as enabling the system proxy.
Android clients typically use VpnService to create a local VPN interface and send selected traffic to the proxy core. You'll need to approve the system permission the first time you connect. Another VPN app may replace the active connection in the same Android user profile. Per-app proxy settings determine which apps enter the connection; routing rules determine whether requests handled by the core use the proxy or connect directly. Check these settings separately.
These example ports illustrate how to check settings; they aren't universal defaults for the three clients. If your configuration uses SOCKS 127.0.0.1:10808 and HTTP 127.0.0.1:10809, make sure each app uses the matching proxy type and port. Some versions use a mixed port; check the client settings and startup logs.
- Desktop check: Confirm that the core has started, then check the status in the “System Proxy” menu. If a port is already in use, stop the old process or change the listening port, and update the apps that use it.
- Android check: In v2rayNG, open “Settings” → “Per-app proxy” and check the toggle and selected apps. Confirm whether the mode proxies selected apps or bypasses them.
- Background check: In Android Settings, open “Apps” → your client → “Battery” and check for background restrictions. Menus vary by manufacturer, so look for the battery management settings for the app by name.
- Scope check: Don't expose every listening address just to route your phone through your computer's proxy. Access from other devices also involves your local network, firewall, and access controls, and should be planned separately.
5. Share a subscription between desktop and Android
Using the same subscription on both devices avoids entering node addresses twice, but it doesn't replace local configuration. To compare connection performance, select the same node on both devices and use the same network and test destination. Different speed-test methods, concurrent connections, and test servers mean latency figures in the interface aren't directly comparable as measures of client performance.
Setup plan: share the source, configure traffic handling and routing separately
Desktop: v2rayN
- Add a subscription group, update it manually, and check the key fields.
- Choose a core that supports the node, and check the logs for startup errors.
- Test your browser with the system proxy first, then configure TUN if needed.
- Record the local listening ports, DNS settings, and routing mode.
Android: v2rayNG or v2flyNG
- Choose a client based on core compatibility and import the corresponding subscription format.
- Approve the VPN permission and check that another VPN isn't taking over the connection.
- Verify the basic connection first, then add per-app proxy rules.
- Check again after locking the screen to confirm the connection keeps working in the background.
Update the subscription on each device before comparing nodes. DNS, routing, per-app rules, and update schedules still need to be configured separately.
When moving from v2rayNG to v2flyNG, re-import a compatible subscription or share link rather than copying app-private data. If the old client used custom JSON, check each field against the target core. Configurations with core-specific transport, security, or routing options usually need adjustments before they will work.
6. Three common questions after choosing a client
Why does the same subscription work on desktop but not on Android?
Select the same node on both devices and compare the transport, security layer, and user ID. Then review the Android logs to distinguish an unsupported configuration from a connection timeout or certificate error. If the node requires REALITY and the Android client is v2flyNG, check core compatibility first. For a timeout, check the network and server reachability.
v2rayN says it's connected. Why can only my browser access the internet?
Check whether the app honors the system proxy. In apps that support manual proxy settings, enter the actual listening address and port configured in the client. To route more traffic, configure TUN using the relevant guide. First confirm that requests from the app appear in the logs; a selected node in the server list doesn't mean its traffic is being captured.
Android disconnects when the screen locks. Should I switch clients?
Check the system's battery restrictions, background permissions, and other VPN apps first, then review the logs after waking the screen. If the connection works in the foreground but the system stops the service after the screen locks, adjust background app management. If the logs show a remote disconnect or network change, investigate the connection and reconnection process instead. This alone doesn't tell you which core is better.
Bottom line: choose by platform, match the core, and test traffic handling separately
Start with v2rayN on desktop. For Android nodes using Xray, check v2rayNG first; consider v2flyNG when the configuration explicitly depends on V2Fly. Get one node working reliably before enabling subscription updates, routing, and per-app proxy rules. Change one setting at a time to make troubleshooting easier.