For desktop, start with v2rayN. On Android, choose v2rayNG or v2flyNG based on your server configuration. This guide is for users with a share link or subscription URL who are installing or switching clients. First check platform and core compatibility, then verify the protocol, transport, security settings, and routing. Finally, test the connection with the same checklist instead of relying on similar names or interfaces.
1. Platforms and cores: different tools for different roles
v2rayN, v2rayNG, and v2flyNG are clients, not three different proxy protocols. A client displays nodes, imports subscriptions, manages settings, and launches a core. The core handles connections, protocols, DNS, and routing. So being able to import a link does not mean the client can connect using every parameter in it.
v2rayN is for desktop use. Choose a release for Windows, macOS, or Linux; the desktop edition uses a cross-platform interface, while the WPF edition retains the classic Windows UI. v2rayNG and v2flyNG are for Android: the former uses Xray as its core, the latter V2Fly. The core used by v2rayN depends on the release, configuration type, and selected settings, so there is no single default that applies to every installer.
| Category | v2rayN | v2rayNG | v2flyNG |
|---|---|---|---|
| Platform | Windows, macOS, and Linux; choose the matching release | Android | Android |
| Core | Can use Xray or V2Fly, depending on version and configuration | Xray | V2Fly |
| Configuration options | Subscription groups, clipboard import, manual configuration | Subscription groups, clipboard import, QR code scan | Subscription settings, clipboard import, QR code scan |
| Traffic routing | Local proxy ports and system proxy; TUN depends on version and permissions | Typically routes traffic through Android's VPN service | Typically routes traffic through Android's VPN service |
| Routing workflow | Well suited to keyboard-driven editing, bulk management, and log review | Routing settings work alongside per-app proxy rules | Routing settings work alongside per-app proxy rules |
Choose in this order: platform → configuration compatibility → workflow
Rule out installers for the wrong platform first, then check which core features the server requires. Only after those requirements are met should you compare list management, subscription handling, and interface layout.
2. Protocol compatibility: check VLESS and REALITY separately
VMess and VLESS are proxy protocols; TCP and WebSocket describe transport methods; TLS and REALITY are connection security settings. REALITY is not a standalone proxy protocol alongside VMess, and seeing a VLESS option in a client does not mean it supports every VLESS configuration.
For example, a VLESS + REALITY configuration needs more than an address, port, and user ID: the server name, public key, short ID, and any specified flow-control settings must also match. v2rayNG's Xray core is a good starting point for checking this type of configuration. v2flyNG uses V2Fly, so Xray-specific REALITY settings cannot simply be carried over. VMess nodes also require checking the transport, TLS, and path—not just the protocol name.
- Protocol: Check whether the share link starts with
vmess://orvless://, and look for options the client may not recognize. - Transport: The WebSocket path and Host must match the server settings. Do not change the path to
/arbitrarily. - Security: The TLS server name must meet certificate validation requirements. Enter REALITY parameters exactly as provided by the server.
- Version compatibility: Note the actual client and core versions before checking whether a field is supported. The interface version is not the core version.
3. Choose by use case: desktop management or everyday Android connections
If you just need to decide what to install, narrow it down by these three use cases. The recommendation below applies specifically to everyday Android use with server settings compatible with Xray; it is not a universal cross-platform ranking. For desktop use, choose a desktop client.
v2rayNG: the Xray option for Android
RecommendedFor Android configurations supported by Xray. After importing, check the transport, security settings, routing, and per-app options. A successful import does not confirm that the connection works.
Best for: everyday Android connections, existing Xray configurations, and users who need VLESS + REALITY.
v2rayN: desktop configuration management
Its node table, subscription groups, and log window make v2rayN well suited to desktop workflows. Choose an installer for your operating system and processor architecture. Before switching cores, check that the target core can read your existing configurations.
Best for: Windows, macOS, or Linux desktops; managing nodes in bulk and troubleshooting connection issues.
v2flyNG: the V2Fly option for Android
A good fit for environments that need to stay aligned with the V2Fly configuration ecosystem. Choose it based on compatibility with your existing server and configuration—not because V2Fly in the name guarantees speed or reliability.
Best for: Android users with a tested V2Fly configuration who want to keep using the same core implementation.
4. Subscription imports: sharing a URL does not sync every setting
A single share link usually contains the connection settings for one node. A subscription URL retrieves a set of configurations, and updates may add, remove, or change entries. A subscription works in both clients only if its contents are compatible with both parsers. Even when the nodes match, DNS, routing, per-app rules, and system proxy settings are not necessarily synced.
- Add a subscription on desktop: In v2rayN, open “Subscription Group” → “Subscription Group Settings,” add a group, and enter the URL. Save it, then use the “Subscription Group” menu to update. Menu labels may vary slightly between interface versions.
- Add a subscription on Android: In v2rayNG, open “Subscription Group Settings” from the side menu, add and save the URL, then return to the main screen and select “Update Subscription” from the menu. The node list may remain empty until you update after adding the URL.
- Import a single link separately: Copy the complete link and use an option such as “Import from Clipboard,” or scan its QR code. In v2flyNG, distinguish node import from subscription management; a webpage URL is not a share link.
- Review the first update: Open a node's edit screen and compare its protocol, port, transport, and security settings with the server details. If a key field is missing, resolve the format compatibility issue before connecting.
Using both platforms: share a compatible subscription, manage local policies separately
Desktop: v2rayN
- Create a separate group for the subscription to keep it distinct from manually added nodes.
- Check which core the current configuration uses and which local ports are listening.
- Configure the system proxy, routing, and DNS separately.
Android: v2rayNG
- Before using the same URL, confirm that the client can parse the node format completely.
- Choose which apps to route through the proxy based on your needs.
- Test DNS and connectivity separately on mobile and Wi-Fi networks.
Subscriptions sync node sources. Check update times, parsing results, and local policies separately; do not assume both clients will always be identical.
Subscription URLs may contain access credentials. When troubleshooting, record only the status code, error, and necessary fields—never include the full URL in a public screenshot. If you manually edited subscription nodes, save a copy first, as a later update may overwrite those changes.
5. Routing and traffic handling: what to check beyond the Connect button
On desktop, “core running” only means the local service has started; it does not mean every app is sending traffic through it. The system proxy affects apps that honor system proxy settings, while command-line tools may need a proxy specified separately. TUN can cover more traffic, but it also involves permissions, routing, and DNS. It is not a one-click way to capture all traffic in every environment.
On Android, traffic typically goes through the VPN service, which requires system permission to start. Another app using the same system channel may prevent it from starting. Per-app proxy settings determine which apps use that channel, while core routing determines whether connections that enter it go direct or through the proxy. These are separate layers: changing one does not automatically change the other.
- Check traffic handling first: On desktop, check the system proxy or the app's own proxy settings. On Android, check the system connection status and per-app scope.
- Then check rule matching: Review the order of routing rules. Put specific domains that need priority before broader rules that would also match them.
- Finally, check the rule data:
geositematches domain categories, whilegeoipmatches IP categories. Rule data and DNS resolution behavior can affect the outcome.
For example, the command below applies only if the local SOCKS listener is actually set to 127.0.0.1:10808. 10808 is an example for testing, not a fixed default port shared by all three clients. socks5h sends the destination hostname to the proxy for resolution, which can help isolate local DNS issues; it does not mean a regular browser will necessarily use the same route.
curl --proxy socks5h://127.0.0.1:10808 --head --max-time 15 https://example.com/When migrating, verify the node first and move routing settings afterward
Test the connection with one node whose parameters you have verified, then add DNS, domain rules, and per-app policies one at a time. Changing only one category of settings per test makes it easier to identify what caused a change in behavior from the logs.
6. Interface differences and common issues: follow repeatable troubleshooting steps
v2rayN's desktop table works well for bulk selection and comparing logs; Android clients focus more on node lists, edit screens, and the Connect button. Most workflow differences come down to screen size and where controls are placed. Fewer buttons do not mean fewer features. Before upgrading, note the current client and core versions, node sources, and key policies so you do not mistake an interface change for a protocol compatibility issue.
The subscription updated, but why won't the node connect?
A successful subscription update only confirms that the URL was reachable. Open the node's edit screen and check the server port, transport, and TLS or REALITY settings in turn. Then review the startup log for unknown fields, handshake failures, or authentication errors. Repeatedly updating the subscription will not fix these issues.
v2rayN says it is running, but is the browser bypassing the proxy?
First check that the system proxy is set, then make sure the browser is not using a separate proxy configuration. Check the local listening port in settings and test a single app against that port. If the log reports a port conflict, close the conflicting process or change the port, then update the app's settings to match.
Only some Android apps fail to connect. Should you switch clients?
First check the per-app proxy list and whether the current mode means “proxy selected apps” or “bypass selected apps.” Then check routing and DNS for the domains used by the apps that fail. On the same network, change one setting at a time and retest; do not switch nodes, rules, and clients all at once.
Switching from v2rayNG to v2flyNG: is copying the link enough?
First make sure the link does not rely on Xray-specific features. Importing a configuration does not guarantee it will work. Check the protocol, transport, and security settings before migrating subscriptions and local rules. For REALITY configurations, continue using a client and core with the required Xray support.
7. Pre-installation checklist
Make the final choice based on platform, compatibility, and maintenance: use v2rayN on desktop; on Android, start with v2rayNG for Xray configurations; consider v2flyNG if you already use V2Fly and the configuration is compatible. No client is universally better regardless of server setup. Reliable choices come from reproducible configurations and test records.
- Make sure the operating system, processor architecture, and installer match. Do not choose based on a similar-looking filename.
- Record the client and actual core versions, then check the protocol, transport, and security settings required by the node.
- Back up the original subscription and manual configurations. After migrating, test a single node before restoring complex routing.
- Test web access, the target app, and DNS separately. Keep the error timestamp and relevant logs.
- For terminology, see the Protocol Reference. For your first setup, follow Getting Started.