Start with your device, then check that the client’s core supports your nodes. For Windows, macOS, and Linux, start with v2rayN. On Android, consider v2rayNG for Xray nodes; if you already have a v2fly configuration, evaluate v2flyNG. This guide covers what subscriptions do and don’t sync, when to use system proxy versus TUN, and what to record before switching clients.
1. Platforms and cores: Check node compatibility first
v2rayN, v2rayNG, and v2flyNG are tools for managing configurations and connections. Similar names don’t mean they’re interchangeable. The client stores subscriptions, generates configurations, and controls connections; the core handles protocols, routing, and traffic forwarding. When troubleshooting compatibility, note both the client version and the core version actually in use.
v2rayN: Desktop
RecommendedFor Windows, macOS, and Linux. Manage nodes, subscriptions, and routing in one place. Available cores and TUN support depend on the package, version, and system environment.
Best for: desktop browsers, developer tools, and managing multiple subscriptions.
v2rayNG: Android with the Xray core
Routes app traffic through Android’s VPN service. For nodes using VLESS, REALITY, or XTLS Vision, first check the bundled Xray version and imported fields.
Best for: everyday Android connections, Xray nodes, and per-app proxying.
v2flyNG: Android with the v2fly core
Runs configurations compatible with v2fly. For existing nodes such as VMess, check the transport, TLS settings, and configuration format individually. A matching protocol name alone doesn’t guarantee compatibility.
Best for: Android devices with existing v2fly configurations or a need to retain existing core behavior.
REALITY and XTLS Vision are Xray-related features. Don’t assume a v2fly configuration will work just because both clients have “V2Ray” in their names. Conversely, a standard VMess node doesn’t automatically require switching cores. Check the server requirements before choosing a client.
2. Compare five key features: traffic entry and routing
The comparison below focuses on real configuration tasks, not a vague claim that one client has “more features.” Subscription management covers fetching and parsing nodes. Routing determines whether traffic is sent direct, through a proxy, or blocked after it reaches the core. TUN and Android’s VPN service handle how traffic enters the client.
| Category | v2rayN | v2rayNG | v2flyNG |
|---|---|---|---|
| Platform | Windows, macOS, and Linux; choose the package for your OS and architecture | Android; choose the package for your device architecture | Android; choose the package for your device architecture |
| Core | Choose a supported core for your nodes; Xray nodes need a compatible Xray core | Xray; supported protocols vary by bundled core version | v2fly; check against v2fly configuration and protocol support |
| Subscription management | Group subscriptions, update them, and choose nodes; available update options depend on the current interface | Manage subscription groups and update nodes; check imported fields | Manage subscriptions in compatible formats; parsing may differ from the other two clients |
| Routing | Coordinate rules, domain policies, and outbound settings; configure the system proxy separately | Core routing combined with Android per-app proxy settings | Core routing combined with available Android app filtering settings |
| TUN and traffic handling | Support depends on the version, permissions, and system routes; check for a TUN toggle in your package | Typically uses Android’s VPN service; this is not the same as a desktop system proxy | Typically uses Android’s VPN service; check routing and DNS as well |
How to choose: narrow down options by node requirements
For a VLESS + REALITY + Vision node, first test the Xray configuration in v2rayN on desktop or v2rayNG on Android. Don’t migrate every subscription right away: test one node successfully before importing the rest.
3. Sharing subscriptions: the same nodes don’t mean synced settings
You can add the same subscription URL to desktop and Android clients, provided your service allows multiple devices and both clients can parse its response format. A subscription URL may contain access credentials, so store it securely. Redact the full URL, user ID, and connection keys in screenshots you share for troubleshooting.
Suggested setup: manage nodes from the same source separately on desktop and Android
Desktop: v2rayN
- Go to “Subscription Group” → “Subscription Group Settings” and add the URL. Menu names may vary by version.
- Update the relevant subscription group, then check the node count and protocols.
- Save routing rules, system proxy settings, and local listening ports separately.
Android: v2rayNG or v2flyNG
- Add the URL from the same source in “Subscription Group Settings,” then update the subscription.
- Start with one node both clients can parse, and check its address, port, and transport settings.
- Configure per-app proxying, DNS, and background permissions separately.
Update subscriptions on each device separately. Update timing, parsing support, and the server’s response can all affect the node list. Local rules and permissions don’t sync automatically with node subscriptions.
If the desktop shows 12 nodes but Android shows only 9, don’t assume there’s a network issue. Check whether the 3 missing nodes use a different format or unsupported fields, then look for parsing errors in the update log. The subscription service may also return different content depending on the request. Repeatedly updating won’t fix a format mismatch.
- Update failed: Tell apart an invalid URL, a connection timeout, and a parsing error. Use the proxy option for subscription updates only if the update request actually needs a proxy.
- Manual changes disappeared after an update: Subscription entries may be regenerated. Save changes you need to keep as manual nodes and manage them separately from subscription nodes.
- Device limit reached: Check the server’s concurrent connection limit. Copying a subscription URL doesn’t increase your connection allowance.
4. Choosing between system proxy, TUN, and Android VPN
For desktop browsers that follow the system proxy, v2rayN’s system proxy setting is usually enough. For apps with manual proxy settings, enter the protocol, address, and port the client is actually listening on. Consider TUN only for apps that ignore the system proxy. TUN still requires routing and DNS configuration; it won’t automatically fix every connection issue.
- Test the local proxy first. In v2rayN, check the listening settings under “Settings” → “Parameter Settings.” If the HTTP endpoint is set to
127.0.0.1:10809, the app must use that address too. This is an example, not a default for every version. - Change one variable at a time. Turn off TUN first, then test the node and system proxy with an app that supports HTTP proxies. Once the proxy endpoint works, check whether other apps need a virtual network interface.
- Grant permissions only if you need TUN. Follow the prompts for your version, then check the virtual network interface, default route, and DNS. Test both direct and proxied sites with TUN on and off.
- Grant Android VPN permission first. Approve the system prompt when starting a connection in v2rayNG or v2flyNG, then configure per-app proxying. The VPN indicator means the service is running; it doesn’t guarantee the remote node is reachable.
“Proxy selected apps only” and “Bypass selected apps” do the opposite. Test with a single browser, reconnect, and visit the target page. Confirm the setting works as intended before expanding its scope. Android generally can’t run two standard VPN services at once. Stop the current client before switching to avoid mistaking a traffic-handling conflict for a node failure.
5. Before switching clients: test under the same conditions
Latency results for the same node can’t always be compared directly between clients. A TCP connection test, browsing through a proxy, and measuring an actual download test different stages. Differences in the node, network, destination, or test time can all affect results, so they don’t prove that one client is inherently faster.
- Keep a record of the original configuration: Note the server address, server port, user ID, transport, TLS, SNI, path, and any required REALITY fields. Don’t confuse the server port with the local proxy port.
- Keep test conditions consistent: Use the same node, network, and destination page on both devices. Run only one client at a time and keep routing policies as similar as possible.
- Check three things separately: Can the node connect? Can the target domain resolve? Is the request using the right outbound route? A single timeout in the logs isn’t a substitute for checking all three.
- Record repeatable results: For example, open the same page three times and note how many attempts succeeded and what errors occurred. This is a troubleshooting method, not a performance benchmark of the three clients.
- Restore traffic rules last: Once the basic connection works, add per-app proxying, complex routing, and custom DNS one at a time. Retest after each change.
Don’t overwrite the entire configuration file when switching clients. Different cores may use different configuration structures, DNS behavior, and routing options; client-generated internal configurations also aren’t suitable for syncing across platforms. Import compatible node links first, then rebuild local settings in the new client.
6. Common questions about choosing a client
I use v2rayN on desktop. Should I look for the same client on Android?
Choose by platform. For Xray nodes on Android, start with v2rayNG; if you already have a v2fly configuration, consider v2flyNG. Add the subscription to the Android client and configure routing, DNS, and app selection again—don’t copy the desktop installation folder.
Can v2flyNG use a subscription with REALITY?
A successful subscription import doesn’t guarantee compatibility. Check whether the specific node requires REALITY or Vision. If it does, choose an Xray client and core that support those features. Check other nodes in the subscription individually.
Android connects, but my desktop browser won’t load pages. Should I switch clients?
First, confirm that v2rayN’s active node is selected and its core is running. Then check the system proxy and the browser’s own proxy settings. If the browser is set to use 127.0.0.1:10809, make sure that port is actually listening. Next, check routing and DNS.
After switching to v2rayNG, why can only some apps connect?
Check whether per-app proxying is set to the wrong mode and whether the app is in a separate environment, such as a work profile. Temporarily disable app filtering and reconnect to compare. Once basic access works, add the apps that need a proxy one at a time.
Do I need to install all three clients?
Install based on your device and node requirements. Use v2rayN on desktop; on Android, start with a client whose core supports your nodes. Install another only if you need to compare or troubleshoot. During testing, let only one client handle traffic at a time to avoid conflicts between routing and VPN services.