For desktop, start with v2rayN and choose the desktop or WPF edition for your system. On Android, v2rayNG is a strong first choice for Xray configurations; consider v2flyNG for existing V2Fly configurations. This guide is for users installing a client, moving between devices, or troubleshooting protocol incompatibility. It explains platform, core, and traffic-routing differences, then walks through subscription imports, routing checks, and cross-device migration.
Platform comparison: choose desktop and Android clients separately
v2rayN, v2rayNG, and v2flyNG are client names, not three proxy protocols. A client manages servers, subscription updates, runtime options, and the user interface; the core usually handles the actual connection. Similar names don’t mean the apps are interchangeable or that importing the same link will produce identical configurations.
| Comparison | v2rayN | v2rayNG | v2flyNG |
|---|---|---|---|
| Primary platforms | Windows, macOS, and Linux desktops | Android | Android |
| Interface and editions | The Avalonia desktop edition supports all three desktop platforms; the WPF edition is Windows-only | Android server list and settings | Android server list and settings |
| Core | Choose a supported core based on the version and configuration; Xray is a common option | Xray core | V2Fly’s V2Ray core |
| How traffic is routed | Local proxy ports and system proxy; TUN is also available in supported versions | Typically routes traffic through Android’s VPN service | Typically routes traffic through Android’s VPN service |
| What to consider | Operating system, architecture, release package, and desktop traffic-routing method | Xray protocol support, subscription format, and per-app settings | Existing V2Fly configuration and version compatibility |
Windows users should also distinguish between the interface framework and core capabilities. WPF and Avalonia describe desktop UI frameworks, not transport protocols. Switching UI editions won’t make a server support additional protocols. macOS and Linux users should choose the release package for their platform, while Android users should match the package to their device’s processor architecture.
- For everyday desktop use: Start with v2rayN. Check your operating system and processor architecture, then review the requirements for the current release package.
- For Xray configurations on Android: Start with v2rayNG and check the node’s security settings and transport fields.
- For existing V2Fly configurations on Android: Consider v2flyNG. First confirm that its current core accepts your configuration, then decide whether to migrate.
Core comparison: check security and transport settings, not just protocol names
Project V provides the broader technical context: V2Fly maintains V2Ray, while Xray is a separate core. The difference between v2rayNG and v2flyNG isn’t just a matter of interface color or name. To assess compatibility, check the protocol, transport, security settings, and core version. A client displaying a node doesn’t mean its core can connect to it.
v2rayN: desktop configuration and management
A good fit for managing multiple subscription groups, switching routing rules, and checking core logs on desktop systems. Choose a core based on the node parameters and options available in your current version; support for multiple cores doesn’t mean every combination will work.
Best for: Everyday proxy use and configuration troubleshooting on Windows, macOS, and Linux.
v2rayNG: Xray configurations on Android
RecommendedFor Android users with Xray configurations, v2rayNG is a good first choice. If a node requires VLESS, REALITY, or a specific flow value, verify that the included core supports each setting. Don’t judge compatibility only by the link’s prefix.
Best for: Everyday Android use and nodes that specifically require Xray capabilities.
v2flyNG: V2Fly configurations on Android
A good option for continuing to use a tested V2Fly configuration. Compatibility with protocols such as VMess still depends on the configuration fields and core version. If the configuration includes Xray-specific parameters, check support first rather than repeatedly trying to import it.
Best for: Android users with an existing V2Fly configuration who want to preserve its behavior.
For example, VLESS configurations using TLS and REALITY have different requirements; VMess over TCP and WebSocket also use different transport fields. A mismatch in the WebSocket path, TLS server name, or server listening port can prevent a connection. Removing an unrecognized field may allow a link to import, but that doesn’t mean the connection will work correctly.
Choosing a client: list the node’s required fields before picking an Android app
Record the protocol, transport, security method, server name, and any flow requirements. If you rely on Xray-specific features, start by testing v2rayNG. If your existing V2Fly configuration works, keep it as a working baseline in v2flyNG and test migration with the same node.
Subscriptions and interfaces: importing a link isn’t the same as managing a subscription
All three clients provide a server list, but a single share link and a subscription address serve different purposes. Share links such as vmess:// and vless:// usually describe one node; a subscription address retrieves a list of nodes and supports later updates. Importing a subscription address as a regular text node may leave the list empty or show an unsupported-format message.
- Add a subscription in v2rayN: Open “Subscription Group Settings” from the “Subscription Group” menu in the main window. Add a group name and subscription address, save, then update the subscription. Menu labels may vary slightly between versions. Choose the option for managing subscription addresses, not the editor for a single server.
- Import a single node in v2rayNG: Copy the complete share link, then tap “+” in the upper-right corner of the main screen and choose “Import from clipboard.” Open the node’s edit screen after importing and check the address, port, transport, and security settings.
- Add a subscription in v2rayNG: Open “Subscription settings” from the main menu, add a name and address, and save. Return to the list and tap “Update subscription.” If your version offers multiple update methods, choose the one that works with your subscription address.
- Manage subscriptions in v2flyNG: Add the address through the subscription settings in your current version, then update it. Before migrating, make sure the returned format can be parsed. Don’t assume another client’s subscription groups will be imported along with the address.
On desktop, v2rayN makes it easier to inspect groups, nodes, and logs with a mouse and keyboard. Android workflows center on lists, menus, and the connect button. Interface preferences can affect how efficiently you manage settings, but connection quality depends on the server, network path, and core configuration. A smoother interface alone doesn’t mean a client is faster.
Routing and ports: check where traffic goes after connecting
Routing rules decide whether a type of traffic goes through the proxy, connects directly, or gets blocked. Routing is not node testing or subscription grouping. The desktop system proxy usually affects only apps that honor system proxy settings. TUN has a different coverage and may involve permissions, routes, and DNS. On Android, if the client routes traffic through the VPN service, check whether per-app settings exclude the app you’re testing.
These numbers are examples for troubleshooting, not default settings shared by all three clients. If the desktop client listens on 127.0.0.1:10808, that port is for local apps connecting to the proxy. The :443 in a server address is the remote server port. They serve different purposes, so don’t set them to the same number just for consistency. If the local port is already in use, change the listening port and update the app’s proxy settings to match.
- Desktop: In v2rayN, open “Settings” → “Parameter Settings” to check the local listener, then check the system proxy status in the main window. Menu names and grouping can change between versions, so use the listening address and port shown in your current interface.
- Android: After starting a connection, make sure the system VPN permission is granted, then check per-app proxy settings in the client. If another VPN service is running, you’ll usually need to stop it first.
- Rule matching: Check the active routing preset, rule order, and default outbound. Rules are generally matched in order, so an overly broad rule near the top may catch the traffic first.
- DNS checks: DNS resolution, domain rules, and IP rules can affect one another. Testing a single IP address won’t confirm that domain-based routing is working. Check the logs using a domain you actually visit.
Android per-app proxy settings and domain routing control different things. Per-app settings determine which apps’ traffic enters the client; domain routing determines which outbound handles traffic that has entered the client. If an app is excluded from VPN routing, changing the client’s domain rules usually won’t affect where that app’s traffic goes.
Using desktop and Android together: share a subscription, configure routing separately
Desktop and Android can use the same subscription address if the subscription service allows both devices and both clients support the returned node format. Sharing an address doesn’t sync routing, DNS, per-app lists, or system proxy status. Since the two clients may update at different times, their node lists may temporarily differ.
Suggested setup: test v2rayN on desktop and v2rayNG on Android separately
Desktop: v2rayN
- Choose a release package for your system and architecture, add a subscription group, then run an update manually.
- Choose a core that matches the node parameters and note the actual local listening port.
- Test browser access with the system proxy first, then consider TUN if needed.
- Save routing presets and DNS settings separately; don’t rely on the subscription to replace local configuration.
Android: v2rayNG
- Add the same subscription address and check the target node’s security and transport settings.
- Grant VPN permission and keep the test app within the routed apps for now.
- Once the basic connection works, enable per-app proxying and custom routing.
- If you already have a V2Fly configuration, keep a working baseline in v2flyNG first.
Sharing a subscription reduces duplicate node entry, but each client still needs its own updates, configuration checks, and traffic-routing tests.
Migration testing: change one variable at a time
- Record the working node’s protocol, address, port, and transport fields in the original client, and keep the original configuration.
- Import the same node into the new client. Start with simple routing and don’t add custom rules yet.
- Visit the same test page and note whether DNS resolution, the connection, and page loading succeed. If something fails, check the relevant core logs.
- Once the basic connection works, restore routing, per-app, and DNS settings. Retest after each change to identify which setting causes any problems.
For speed comparisons, use the same device, network, node, and test window where possible, and run multiple tests. Results from a wired desktop connection and a phone’s mobile network can’t be attributed directly to client differences. This guide doesn’t use speed figures from tests with inconsistent conditions as a basis for choosing a client.
Choosing a client: import errors, websites that won’t load, and what to keep when migrating
Can I freely switch between v2rayNG and v2flyNG?
First check which core capabilities the node requires. Copy the same share link into the target client and verify the protocol, transport, security method, and flow one by one. If it includes parameters the target core doesn’t support, switch clients or use a compatible configuration from the server provider. Don’t simply delete fields.
The subscription address opens, so why is the list still empty after updating?
Make sure you added a subscription address, not a link to an account page, and check the update message. A browser page showing a login screen or an error doesn’t mean the subscription is valid. Ask the provider to confirm that it returns a subscription format your client can parse, then try updating again.
v2rayN says it’s running, but websites won’t load. What should I do?
Check the system proxy status first, then confirm that your browser follows the system proxy or isn’t using separate proxy settings. If you manually set 127.0.0.1:10808, make sure that port is actually listening and the proxy protocol is correct. Then check the core logs for connection and DNS errors.
Only one app can’t access the internet after connecting on Android. Should I switch clients?
Open settings and check per-app proxying first. Make sure the app isn’t excluded and check whether it uses separate network settings. Keep the same node and temporarily simplify routing rules, then test again. Consider switching clients first only if the logs show that the core doesn’t support a required configuration.
Is copying the subscription address enough when switching clients?
After copying the address, update the subscription again and check the selected node. Also record routing presets, DNS, per-app lists, local ports, and manual edits. These settings usually aren’t part of the subscription, so they won’t automatically move with the node list.
The choice comes down to three factors: your device platform determines which client to install, node parameters determine the core, and your apps determine how traffic is routed. Start with v2rayN on desktop; test v2rayNG first for Android Xray configurations; and use a working v2flyNG setup as the baseline for existing V2Fly configurations. Get a repeatable connection working before adjusting advanced settings.