For desktop, first check which operating systems and architectures v2rayN supports. On Android, consider v2rayNG for Xray-based nodes; choose v2flyNG when you specifically need the V2Fly core. This guide distinguishes clients, cores, and node protocols, explains why the same subscription can import differently, and covers setup on both platforms, port checks, and migration. Start by confirming feature compatibility, then compare real-world network performance—not similar-sounding names.
Platforms and cores: identify what you’re installing
v2rayN, v2rayNG, and v2flyNG are clients, not proxy services. A client manages server details, builds configurations, starts a core, and provides a proxy interface to the operating system or apps. The core handles protocols, transports, DNS, and routing rules. Installing a client does not give you a working server; subscription URLs must come from a trusted source.
The names are similar, but these apps are not desktop and Android counterparts with interchangeable settings. v2rayN is designed for desktop; its interface and available cores depend on the release package. v2rayNG targets Android and uses the Xray core, while v2flyNG also targets Android but uses the V2Fly core. Similar-looking interfaces don’t make their configurations interchangeable.
| Client | Platforms | Core | What to check first |
|---|---|---|---|
| v2rayN | Windows、macOS、Linux | Can manage cores such as Xray and sing-box; support varies by release package | Operating system, processor architecture, desktop interface, and the core actually in use |
| v2rayNG | Android | Xray core | Node protocol, transport settings, and Android requirements |
| v2flyNG | Android | V2Fly core | Whether the node uses a protocol and configuration format supported by this core |
Different Windows interface editions are not different node protocols. Choose the correct package for macOS or Linux as well. Check the download page for your operating system and architecture, such as x64 or arm64, then look in the client logs for the core name and version. The client version and core version are separate; record both when troubleshooting.
Node protocols: V2Ray support doesn’t mean configurations are interchangeable
“Supports V2Ray” is too broad to tell you whether a specific configuration will work. Before importing, check the protocol, server address, port, credentials, transport, and security settings. VMess and VLESS are proxy protocols; WebSocket and gRPC are transport methods; TLS and REALITY are connection security settings. These belong to different layers and cannot be substituted for one another.
v2rayNG: Xray configurations on Android
RecommendedFor Android setups using Xray-supported VLESS and REALITY configurations, start with v2rayNG. A successful connection still depends on the bundled core version and complete settings, including the public key, serverName, and shortId.
Best for: everyday Android use and nodes with clearly specified Xray settings
v2flyNG: V2Fly configurations on Android
Use it with existing V2Fly configurations or when you need to verify V2Fly behavior. Check combinations such as VMess and WebSocket field by field; Xray REALITY settings cannot simply be applied to this core.
Best for: environments that require V2Fly and maintaining existing compatible configurations
v2rayN: desktop configuration management
Manage subscriptions, nodes, and routing from one desktop app. If a node imports but the core won’t start, check which core is actually being used—not just whether the node appears in the list.
Best for: desktop browsers, developer tools, and managing multiple subscriptions
For example, a server port of 443 does not mean TLS must be enabled, nor does it mean you can enter any domain name. The WebSocket path, request Host, and TLS serverName serve different purposes. They may match, but they may also differ. Use the values provided by the server; don’t guess based on the node name.
Bottom line: check the core before troubleshooting imports
If import fails, check the sharing format and supported fields. If import succeeds but the core won’t start, check protocol and core compatibility. For Android nodes that require REALITY, verify the v2rayNG core and settings first; changing the node remark or scanning the QR code repeatedly won’t fix the issue.
Subscription management: a shared URL doesn’t sync every setting
Subscriptions typically fetch multiple nodes at once. The same URL can produce different results in different clients: the subscription service may return content based on client type, and a client’s parser may filter out unsupported protocols. A different node count doesn’t automatically mean a network problem. Distinguish between download failures, parsing errors, and unsupported nodes.
- Test a single node first. Import a trusted share link using the client’s clipboard or QR code import option. Once the connection works, add the full subscription to narrow down any issues.
- Then create a subscription group. In v2rayN, look for “Subscription Group” → “Subscription Group Settings.” In v2rayNG, open the side menu and choose “Subscription Group Settings.” Enter a group name and URL, then update it. Menu labels can vary by version, so use the subscription management option in your current interface.
- Choose direct or proxied updates. If the URL is reachable directly, try a direct update first. If it’s only reachable through an existing connection, update through the proxy. Proxied updates require a working node, so they can’t fix a setup where every node is down.
- Protect subscription credentials. Subscription URLs may contain access tokens. Don’t share the full URL in public screenshots or troubleshooting posts. When asking for help, include only the error type, response status, and a redacted domain.
Subscription updates generally don’t sync system proxy settings, per-app lists, routing priorities, or local listening ports. Even with the same subscription on a computer and phone, each device may use a different connection method and DNS policy. After updating, make sure the active node is still available and that the selected node changed as expected.
Using the same subscription on two platforms, with separate connection settings
Desktop: v2rayN
- Add a subscription, then select a compatible core and node.
- Test the connection in a browser using the system proxy.
- Set a local proxy address in developer tools if needed.
Android: v2rayNG
- Use a compatible subscription URL from the same provider.
- Grant permission to establish the Android VPN connection.
- Set up the per-app list to match your needs.
You can use the same node source on both devices, but the lists may differ depending on the subscription response and protocol support. Configure routing and per-app settings separately on each device.
Routing and connections: desktop system proxy vs. Android VPN mode
v2rayN’s system proxy setting directs apps that follow the operating system’s proxy settings to a local proxy; it doesn’t capture all traffic. Some command-line tools, games, and apps with their own network stacks may ignore the system proxy. Desktop TUN mode can cover more traffic, but requires permissions and involves a virtual network adapter and routing. Enable it only after confirming that the regular proxy works.
On Android, v2rayNG and v2flyNG can use VpnService to create a local VPN interface and send traffic from selected apps through the client. The VPN icon only confirms that the local interface is up; it doesn’t prove the remote node is connected. The per-app list determines which apps use this route. Routing rules then decide whether their traffic is proxied or sent directly.
- Traffic coverage: First check whether the target app uses the system proxy, a manual proxy, or the VPN interface. Traffic that never reaches the client is not affected by its routing rules.
- Outbound routing: Check whether the rules send the target domain or IP through the proxy, directly, or block it. Put specific rules before broad ones to prevent an earlier match from taking precedence.
- DNS behavior: Check where the domain is resolved and whether DNS queries follow the intended route. Changing routing mode alone does not guarantee that DNS settings will change too.
- Android app list: Check whether the mode is “proxy selected apps only” or “bypass selected apps” before adding apps. The same list means the opposite thing in each mode.
Local ports: verify desktop connections with explicit addresses
Port checks help diagnose cases where the client appears to be running but a specific tool can’t connect. This example uses a manual setup with SOCKS at 127.0.0.1:10808 and HTTP at 127.0.0.1:10809. These are not universal defaults; if your version uses a mixed inbound or different ports, check the settings and startup logs.
In v2rayN, check the local listener settings under “Settings” → “Parameter Settings”; section names may differ between interface versions. If a tool supports only HTTP proxies, enter the address of an actual HTTP listener rather than using a SOCKS port. The commands below check only whether the example ports are listening; they don’t confirm that the remote node works.
# Windows PowerShell: check the two local listeners in this example
Get-NetTCPConnection -State Listen -LocalPort 10808,10809
# Linux: check local listening ports
ss -lnt
# macOS: show local TCP listeners
lsof -nP -iTCP -sTCP:LISTENIf nothing is listening, check whether the core started, whether the configuration reported errors, and whether another process is using the port. If a port is listening but the tool still can’t connect, verify its proxy type and address. Keep the listener bound to the loopback address by default. If you need to share it with devices on your local network, review the bind address, firewall, and access controls separately; don’t expose a local listener to the public internet.
Migration and troubleshooting: preserve settings and test each layer
When moving from v2rayN to an Android client, migrate the subscription URL or a single-node share link—not the entire desktop runtime configuration. A generated configuration may include desktop inbounds, file paths, rule resource locations, and core-specific fields. Working on the original device doesn’t mean it can be imported directly on a phone.
- Record the original node’s protocol, transport, security settings, and key fields. Keep a private backup of the configuration.
- Import one node into the new client first, keep the default connection settings, and test with a real page load or app request.
- Next, add the subscription, then configure routing and the per-app list. Retest after each category of change to avoid introducing multiple variables at once.
- For speed comparisons, keep the node, destination, network, and test time consistent. On Android, use the same Wi-Fi or mobile network for each test so network differences aren’t mistaken for core performance.
Why does my phone show fewer nodes after importing the subscription that works on my computer?
First compare the subscription URLs and update times on both devices, then check the update logs for parsing errors. If a specific protocol is missing, confirm that the Android client’s core supports it. If the entire list is empty, check that the response is valid subscription data—not a login or error page.
v2rayNG says connected, but one app won’t open. What should I check?
Open the per-app proxy settings and check the list mode and whether the app is included. Then review the routing rules and logs. If other apps work, start by checking how that app is routed instead of replacing all your nodes.
Can v2flyNG import a complete Xray configuration directly?
Don’t assume full configuration compatibility. First confirm that V2Fly supports the node protocol, then recreate the node using a share link or manual entry. For Xray-specific settings such as REALITY, use a client and core that support them rather than removing security fields to force it to start.
Is v2rayNG always faster than v2flyNG?
There’s no basis for that assumption. Compare the same node setup supported by both clients on the same network, and test real requests, connection stability, and sustained transfers. If the protocols or routes differ, the results can’t isolate client performance.
The choice comes down to three steps: select a client for desktop or Android, match the core to the node protocol, then configure traffic coverage and routing for your apps. Use v2rayN on desktop. For Xray features on Android, start with v2rayNG; choose v2flyNG when you specifically depend on V2Fly. For terminology, see the Glossary. For connection and split-routing setup, see the User Guide.