Start with the protocols, transport, and security settings your node requires, then choose a core that supports those fields. There’s no need to judge a standard VMess node by its name alone. If a node specifies REALITY or a particular VLESS flow, check Xray support first. This guide is for anyone comparing v2rayN, v2rayNG, and v2flyNG, or troubleshooting a node that imports successfully but won’t connect.
Where the fork began: project history isn’t the same as client naming
Project V’s V2Ray project was later maintained by the V2Fly community. The term “V2Fly core” usually refers to that branch’s v2ray-core. Xray began evolving independently from related code in 2020, becoming a separate, actively developed core. The two share a common origin, but newer transport and security features, as well as config fields, aren’t guaranteed to be compatible. To check compatibility, look at the core currently in use—not just the “V2Ray” label on a node link.
A graphical client handles subscription imports, server lists, and system proxy switching. The core uses the config to establish connections and route traffic. v2rayN is a desktop client, and what it can do also depends on the core and version it’s currently running. On Android, v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. Switching clients can also mean switching cores, so the same link may behave differently in each one.
These three layers aren’t a ranking of versions. For a VLESS node, for example, VLESS is the proxy protocol, TCP is a transport, and TLS or REALITY is a security setting used during the connection. Simply confirming VLESS support doesn’t mean the client can handle the node’s specified flow control and security parameters.
Feature differences: check the server config before judging compatibility
VMess over WebSocket with TLS is a common setup that both branches have supported for years. Whether a node connects still depends on the server config, the client core version, and whether the fields match. VLESS configurations also vary: a basic VLESS setup doesn’t require the same capabilities as one using Xray-specific flow control. If a link or subscription includes fields such as xtls-rprx-vision or reality, don’t treat them as optional notes you can delete.
| Node configuration | How to choose | What to check after importing |
|---|---|---|
| VMess + WebSocket + TLS | Either core may work; check the actual version and server config. | Address, port, path, Host, and TLS domain. |
| Standard VLESS + TCP + TLS | Check whether your core version supports the complete config. Don’t decide based on the word “VLESS” alone. | User ID, transport, TLS domain, and certificate settings. |
| VLESS + Vision flow control | Prefer an Xray core that supports this flow. | Check whether flow matches the value required by the server. |
| VLESS + REALITY | Prefer an Xray core with REALITY support; standard TLS settings aren’t a substitute. | Fields such as the public key, short ID, target domain, and fingerprint. |
“Prefer” here means reducing the chance of a config mismatch, not promising faster speeds. For example, if the server listens on port 443, enter the same port in the client. That alone doesn’t prove the node uses TLS or guarantee that the REALITY parameters are correct. A subscription missing even one required field may import and appear in the server list without being able to connect.
Bottom line: choose a core based on the node’s fields
If a subscription explicitly requires REALITY or xtls-rprx-vision, first check that an Xray core is available, then troubleshoot the network. For a standard VMess node, check its parameters and routing first—you don’t need to switch cores just to troubleshoot.
Choosing a client: desktop and Android
On desktop with v2rayN, check which core is running before deciding whether it supports the node’s fields. Being able to import a link doesn’t mean the current core supports every setting in it. On Android, narrow down your options based on the capabilities you need: v2rayNG uses Xray, while v2flyNG uses V2Fly. Either way, check the app version, subscription contents, and server requirements.
Xray core: v2rayN or v2rayNG
RecommendedIf your node uses Xray-specific features such as REALITY or Vision, start by checking the config with an Xray core. Standard VMess nodes can also work; connection success still depends on the actual parameters.
Best for: subscriptions with Xray-specific fields, or troubleshooting desktop and Android configs side by side
V2Fly core: v2flyNG
Best for nodes maintained for the V2Fly core. If you’re keeping existing VMess or other configs, make sure the subscription doesn’t include fields the current core can’t recognize.
Best for: server configs built for V2Fly, with existing nodes that connect reliably
If a subscription includes both standard nodes and REALITY nodes, don’t assume the whole subscription is compatible just because the standard nodes connect. Open each server’s details and note its protocol, transport, security settings, and flow control. Then test a node with all its parameters in place. This makes it easier to find the problem than repeatedly switching the entire subscription.
Using one subscription across devices: make sure all fields are present
A subscription link provides a server list; it doesn’t rewrite every parameter for different cores. When using the same subscription on desktop and Android, choose a node to test on both devices and compare the imported fields. If the provider changes a node’s port, transport path, or security settings, update the subscription on both clients. Fixing it manually on one device won’t update the other.
Setup plan: match each device to the node’s capabilities
Desktop: v2rayN
- Make sure the active core matches the node’s requirements.
- After updating the subscription, check each server’s details—not just its name.
- Test a single node first, then check system proxy and routing settings.
Android: v2rayNG or v2flyNG
- For REALITY or Vision requirements, check v2rayNG first.
- With v2flyNG, choose nodes supported by its core.
- After updating the same subscription, compare protocol, port, and security fields.
Sharing a subscription URL gives you the same set of nodes; verify each node’s fields to confirm it will connect on both devices.
Routing is a separate layer: even when the client connects to the server, rules may send a particular site directly instead of through the proxy. In v2rayN, go to Settings → Parameter Settings to check local proxy options, then review the current system proxy mode and routing rules. If you’ve configured a browser to use a local SOCKS proxy, check that its port matches the one shown in the client. The commonly used port 10808 may not match your actual setting.
When switching cores or moving nodes, troubleshoot in this order
When switching from v2flyNG to v2rayNG, or changing cores in v2rayN, keep the existing subscription URL and one known-working node for comparison. Don’t change the subscription, routing, DNS, and local proxy port all at once; if the connection starts working again, you won’t know which change fixed it. Change and test one thing at a time to tell a config compatibility issue from a local proxy problem.
- Check the imported config: Open the node details and compare the server address, port, user ID, transport, path, and security settings. For REALITY nodes, also check the public key, short ID, domain, and fingerprint. For Vision nodes, check the flow value.
- Check core support: Confirm that the active core supports the node’s requirements and see whether the client reports any unsupported fields. Importing a link only means the client read some of its config; it doesn’t mean all connection parameters are present.
- Check the local proxy: Test the connection in the client first. If the client connects but your browser doesn’t, check the system proxy switch, browser proxy settings, and whether the local SOCKS port matches the one shown in the client.
- Check routing last: If some destinations work and others don’t, check whether the routing rules send them through the proxy or directly, and review your DNS settings. Don’t assume every routing issue is caused by differences between cores.
Logs can help narrow down the cause. For an “unsupported config field” error, check the core and its version first. For a connection timeout, verify the address, port, and current network. For a handshake failure, check the security parameters required by the server. The same error can have different causes, so compare the node details with your most recent changes.
Bottom line: change one layer at a time
Keep the node fixed and check the core first, then test the connection, and finally review the system proxy, routing, and DNS. This helps you identify the compatibility limits between Xray and V2Fly without mistaking a local routing issue for a dead node.
The key question when choosing a core isn’t which name sounds newer—it’s which fields the node requires. If your existing V2Fly setup works reliably, you can leave it as is. For REALITY or a specific VLESS flow, use an Xray core that supports those settings and compare each field with the server details. On desktop, check which core v2rayN is running; on Android, choose between v2rayNG and v2flyNG based on their core differences. Troubleshooting is much clearer this way.