For desktop, start by checking which platforms and architectures v2rayN supports. On Android, choose v2rayNG or v2flyNG based on the core your nodes require. This guide explains the differences between clients, cores, and protocols; what subscription links sync; and how to check routing, ports, and connections on both devices. If you already have nodes or a subscription URL, use these criteria to narrow your options without installing every client to compare them.
1. Clients, Cores, and Proxy Protocols: What's the Difference?
v2rayN, v2rayNG, and v2flyNG are client names, not three different proxy protocols. A client imports nodes, stores subscriptions, generates configuration, and manages connections. Its core handles protocol connections, DNS queries, and traffic routing according to that configuration. VMess and VLESS, by contrast, are proxy protocols. Similar names don't guarantee that the same configuration will behave identically in every client.
v2rayNG is based on the Xray core, while v2flyNG uses the V2Ray core maintained by V2Fly. v2rayN is a desktop configuration manager, and the cores it can run vary by release package and version. When troubleshooting compatibility, note both the client version and the core actually in use—not just the software name.
| Client | Platforms | Core | What to check first |
|---|---|---|---|
| v2rayN | Windows, macOS, and Linux; varies by release package | Depends on the version, core settings, and node type | System architecture, active core, and system proxy status |
| v2rayNG | Android | Xray core | Node fields, VPN permission, and per-app scope |
| v2flyNG | Android | V2Ray core maintained by V2Fly | V2Fly config compatibility, transport, and runtime logs |
Xray and V2Fly share technical roots, but their ongoing development hasn't kept every feature in sync. VMess or VLESS compatibility is only the first thing to check; also verify the transport, TLS settings, and any extension fields. For example, if a node requires Xray's REALITY feature, use an Xray core and client version that support the required fields. Seeing a VLESS option in the interface alone doesn't mean the node will work.
2. Narrow Down Your Options by Platform and Existing Config
Choose in this order: platform → node requirements → how you manage connections. On desktop, start with v2rayN if you switch between nodes, inspect logs, or edit routing rules. On Android, first check whether your nodes need Xray-specific features or whether you need to reuse a configuration already tested with V2Fly. The recommendations below are for setting up a new Android configuration, not a performance ranking of the three clients.
v2rayNG: Set Up a New Android Configuration
RecommendedIf a node specifically requires Xray or REALITY, start by checking v2rayNG. After importing it, verify that the server address, port, transport, and security settings are all present. Older client versions may not recognize newer share-link fields.
Best for: everyday Android connections, Xray nodes, and per-app proxy rules.
v2rayN: Manage Desktop Nodes and Configurations
On Windows, macOS, or Linux, choose the release package for your system architecture, then check the core settings. A desktop system proxy, a browser proxy, and TUN are different ways to route traffic. Starting a node doesn't mean every app is connected through it.
Best for: desktop use, managing multiple subscriptions, and monitoring runtime logs.
v2flyNG: Keep Using Your V2Fly Configuration
If you already have a working V2Fly node or custom configuration, consider v2flyNG. Keep the existing protocol and transport settings, then check that the current version can import the format. There's no need to switch cores just to get a different interface.
Best for: keeping your existing V2Fly setup on Android and preserving established configuration behavior.
How to Decide: Check Required Fields Before Comparing Interfaces
Note the protocol, transport, and security type in the node details. If any of them relies on a feature your current core doesn't support, switch to a compatible core or client first. Changing the theme, subscription groups, or speed-test settings won't fix a protocol incompatibility.
Don't assume a core name tells you which client will be faster. Real-world throughput also depends on the route, server load, transport settings, and device resources. To compare performance across devices, use the same node, network, and test target, and record the error type shown in the logs. Results gathered under different conditions can't reliably rank clients.
3. Subscriptions Can Be Shared, but Local Settings Don't Sync
A subscription URL usually returns a list of nodes, not a complete device setup. Adding the same URL to v2rayN and v2rayNG saves you from manually maintaining server addresses, ports, and credentials. It won't sync system proxy status, Android per-app lists, DNS settings, or local routing rules.
Using Both Devices: Share the Subscription, Configure Each Separately
Desktop: v2rayN
- Save the URL under “Subscription Groups,” then update the subscription.
- Select an active node and confirm which core is actually running.
- Set the system proxy and local listening port separately.
- Manage custom routing as a separate configuration.
Android: v2rayNG
- Add the same URL under “Subscription Group Settings,” then update the subscription.
- Check the imported nodes' protocol and transport settings.
- When connecting for the first time, approve the system VPN connection request.
- Configure “Per-App Proxy” and its scope as needed.
The node lists can stay in sync only if updates succeed on both devices, the subscription returns the same content, and both clients support all the fields. Check local rules separately. Menu names may vary between client versions.
Share links and QR codes are better for moving a single node temporarily. The imported node is usually an independent copy: changes to the server address or credentials on one device won't update the other. Exporting a custom configuration can preserve more fields, but inbound settings, file paths, and platform-specific options may not transfer cleanly to another system.
- Managing multiple nodes long-term: Use a subscription and check the update result and node count.
- Moving one node temporarily: Use a share link or QR code, then check each important field after import.
- Moving complex routing rules: Check the target core's config format, then migrate fields individually. Don't treat a full configuration as a universal subscription.
- Protecting credentials: Subscription URLs, share links, and QR codes may contain access credentials. Redact them from troubleshooting screenshots.
4. Check Routing Rules and Traffic Capture Separately
Routing rules can only process traffic that has already reached the client core. On desktop, enabling the system proxy mainly affects apps that follow system proxy settings; some apps use their own network settings and need a proxy configured separately. On Android, when the client captures traffic through the system VPN interface, per-app settings determine which apps use that route.
So “this domain is set to use the proxy in the rules” doesn't mean “requests to this domain will definitely go through the proxy.” First confirm that app traffic reaches the core, then check rule order, the selected outbound, and DNS behavior. TUN routing can also be affected by exclusions, route conflicts, and permission limits, so the toggle alone doesn't show which traffic is covered.
- Check traffic capture: On desktop, check the system proxy or the app's proxy settings; on Android, check VPN status and the per-app list.
- Check the outbound: Use the logs or connection records to see which outbound handled the request, not just which node is selected in the list.
- Check rule order: A request can match multiple conditions, and rules are generally evaluated in order. An overly broad rule near the top can take precedence over more specific rules below it.
- Check the domain resolution strategy:
routing.domainStrategycontrols how domain names are resolved for routing matches. It is not the same as choosing a DNS server or setting the domain strategy for outbound connections.
If you're new to configuring rules, start with a simple set that's easy to troubleshoot. First verify that one known destination goes through the proxy, then add direct or block rules. Changing DNS, routing mode, and core all at once makes it harder to identify the cause of a failure. For a field-by-field reference, see the configuration reference.
5. Verify Desktop Connections with Explicit Port Settings
A port is a local entry point for apps to connect to the client, not a remote server port. Here's a manual configuration example: SOCKS listens on 10808, HTTP on 10809, and both bind to 127.0.0.1. These aren't default values shared by all three clients. Check the local listening settings under “Settings” → “Parameter Settings” and the startup logs for the actual values; menu names may vary by version.
If the software enables only one mixed inbound port, point all apps to that port instead of assuming a separate HTTP listener is available. Using 127.0.0.1 also means a phone can't reach the computer's proxy at that address; on a phone, the loopback address points back to the phone itself.
- Connection refused: Check that the core is running, the listening protocol is correct, and the app is using the configured port.
- Log shows address already in use: Close any duplicate client instances first. If the conflict persists, change the local port and update the app that connects to it.
- Node test succeeds, but the browser fails: Check whether the browser follows the system proxy settings and whether the system proxy still points to an old port.
- Works on desktop but not Android: Check Android VPN permission, node fields, and the current network separately. Don't enter the computer's local port in the remote node port field.
In runtime logs, connection refused, TLS handshake errors, and configuration parsing failures happen at different stages. Record the specific error and when it occurred, then adjust the relevant setting instead of repeatedly switching clients. Include the client version, core version, connection method, and node type in your troubleshooting notes.
6. Client Comparison: Frequently Asked Questions
Why does the same subscription work in v2rayN but fail after importing into v2rayNG?
Compare the server, port, protocol, transport, and TLS settings for the same node on both clients, then check the core version. If the subscription contains a field the current client doesn't recognize, update to a version that supports it. If the logs show a handshake failure, check the device clock and the server name required by the server. Avoid resetting every setting at once.
If I only use VMess, do I have to switch from v2flyNG to v2rayNG?
The VMess name alone isn't a reason to switch. First check whether your current version supports the node's transport and security settings, and whether the connection is stable. If you do need to migrate, import and test one node before moving the rest of your nodes and routes. Don't delete the original configuration until the new setup is verified.
Why does only some of my Android traffic use the proxy when the connection is active?
Open “Per-App Proxy” in “Settings” and check whether the selected apps are included in or excluded from the proxy, then confirm the target app falls within that scope. Next, check whether routing rules send the target traffic direct. Per-app scope and domain routing are separate settings; changing only one won't tell you whether the result is correct.
Should I switch clients if a subscription update times out?
First check that the subscription URL is complete and still valid. If your current version has a “Update through proxy” option, try it when you already have a working connection. Without a working node, you can't rely on a proxy that hasn't been established to complete the initial update. Also distinguish a connection timeout from an authentication failure or unparseable subscription content before changing the import method.
The choice comes down to three points: on desktop, start with the v2rayN release package for your system; on Android, check v2rayNG first for Xray nodes; choose v2flyNG when you specifically need an existing V2Fly configuration. Track the client, core, subscription, and traffic capture separately to make future migrations and troubleshooting less guesswork.