Start with your node’s requirements, then check whether your client preserves all required settings. For nodes using REALITY or Vision, choose an Xray-based client. For existing VMess nodes, verify the transport and TLS settings too. This guide explains the differences between projects, cores, and interfaces, with selection advice for desktop and Android and a checklist for verifying a client switch.
Where the forks came from: V2Ray, V2Fly, and Xray
V2Ray can refer to the broader proxy ecosystem or to the core program itself. Project V is the project behind this toolchain; the core that handles connections reads the configuration, sets up local entry points, selects outbound connections, and applies routing. Confusing these names can lead to the mistaken assumption that similarly named clients support exactly the same protocols.
2020 is a key date for understanding how the two core projects diverged. The V2Fly community continued developing and maintaining the V2Ray core, while Xray forked from the V2Ray codebase of that time and went on to develop independently. The projects share some history and configuration concepts, but they are not two skins for the same program. One project’s version number also says nothing about how up to date the other is.
- V2Fly: Maintains the V2Ray core, continuing to develop its own protocol implementations, transports, and configuration system.
- Xray: Maintains Xray-core and has since introduced features such as REALITY and XTLS Vision.
- GUI clients: Manage subscriptions, edit nodes, and toggle the proxy, then pass those settings to the core.
So, “subscription imported successfully” only means the interface parsed or saved the data. It does not mean the running core accepted every field. To assess compatibility, check the client version, the core actually in use, and the protocols and settings required by the node.
Protocol support: VMess vs. VLESS is not the whole story
A node usually consists of several layers of settings. VMess and VLESS are proxy protocols; TCP, WebSocket, and gRPC describe transport methods; TLS and REALITY relate to connection security; Vision is an Xray flow-control feature. Each serves a different purpose: REALITY is not a proxy protocol alongside VLESS that you can swap in on its own.
| Node feature | Xray core | V2Fly core | What to choose |
|---|---|---|---|
| VMess | Supports common combinations | Supports common combinations | Check the transport, TLS, and server settings |
| Basic VLESS protocol | Supported | Basic implementation available | The VLESS label alone does not guarantee full compatibility |
| VLESS + REALITY | Supported; match the version and settings | Cannot use an Xray REALITY configuration as-is | Choose an Xray client that supports the required feature |
| Vision flow control | Supported; must match the server | Does not provide Xray's Vision flow control | Keep the flow value required by the server |
| WebSocket + TLS | Supports common combinations | Supports common combinations | Check the path, Host, SNI, and certificate |
“Supported” does not mean every historical version will work. An older client may fail to parse a subscription that uses a newer transport or field. Even if the interface recognizes the setting, an outdated core may fail when it starts. Check the feature notes for the version you have installed; a shared protocol name is no guarantee of compatibility across versions.
Bottom line: Keep the node’s requirements; don’t remove fields to switch cores
If you see security=reality or flow=xtls-rprx-vision, choose an Xray client that supports the required features. Removing these fields will not turn the node into a working, standard TLS setup; it changes how the server expects the connection to work.
Choosing a client: Desktop and Android options
v2rayN is a desktop GUI client. Its name alone does not tell you which core it is actually running. Supported cores and switching options vary by release, so check the settings and startup logs on your device. For REALITY, make sure the node is handled by Xray; simply having Xray files in the installation folder is not enough.
v2rayNG: The Xray option for Android
RecommendedFor nodes that rely on Xray features. Choose it for protocol compatibility, not its name, interface, or unverified speed claims. After importing, make sure the REALITY and flow-control settings are intact.
Best for: Android users whose provider specifically requires Xray, REALITY, or Vision.
v2flyNG: The V2Fly option for Android
Uses the V2Fly core and suits nodes confirmed to be compatible. If your existing VMess connection is stable, there’s no need to switch just because the other core offers more features.
Best for: Android users with an existing V2Fly configuration and verified node settings.
v2rayN: Desktop configuration and management
Manage subscriptions, servers, and routing in one place. First check which cores your build provides, then use the logs to confirm which core starts the node.
Best for: Managing subscriptions and routing on Windows, macOS, or Linux desktops.
These recommendations focus on the Xray features discussed here; they are not a performance ranking for every network. Updating the client interface and updating its core are separate things: an input field in the interface does not guarantee that the running core can use it.
Check your subscription: Verify settings in the node editor
In v2rayN, open “Subscription Group” → “Subscription Group Settings” to check the subscription URL and group. Then update the group from the “Subscription Group” menu. Update commands may have different suffixes in different versions, so use the option shown in your menu. After updating, double-click a server entry to check its protocol, address, port, and transport settings. Don’t rely on the node name alone.
- Check the protocol first. Confirm whether the entry uses VMess or VLESS. Labels such as “high-speed” or “dedicated line” in a node name do not affect protocol negotiation and are not a basis for choosing a core.
- Then check the transport. For WebSocket, check the path and Host; for gRPC, check the service name. The client must use the settings required by the server’s transport.
- Check the security layer. For TLS, verify the server name and certificate validation. For REALITY, also check the server-provided public key, short ID, and other settings. Field names vary by interface.
- Finally, check flow control. If the server requires Vision, make sure flow is set to
xtls-rprx-visionand use a core that supports it.
In v2rayNG and v2flyNG, update from the subscription group menu, then open a specific entry to check its settings. The same subscription link does not guarantee the same node list: the client version, filtering settings, and subscription response can all affect the results.
Using desktop and Android together: Verify the node, then configure each device
You can use the same subscription on desktop and Android, but don’t copy the entire runtime configuration between devices. Desktop system proxy settings, Android VPN routing, per-app settings, and local listening addresses depend on the device environment and should not be copied along with node settings. Share server details, not the entire runtime state.
Setup: Check compatibility on both devices with the same node
Desktop: v2rayN
- Update the target subscription group and select one node.
- For REALITY, check the startup logs to confirm that Xray is in use.
- Check the local listening port under “Settings” → “Parameter Settings”.
- Verify the system proxy first, then check routing rules separately.
Android: Choose a client to match the node
- Use v2rayNG for nodes that require Xray features.
- Use v2flyNG for nodes compatible with V2Fly.
- Update the same subscription group and check the address, port, and security settings.
- Grant VPN permission, then check which apps are covered by per-app proxy settings.
Update the subscription and verify connectivity on each device separately. Sharing a subscription does not sync local settings.
If a node works on your computer but not your phone, compare the node settings first, then check the phone’s system time, VPN permission, and per-app coverage. If only certain apps have problems, check proxy coverage and DNS before assuming the two core projects differ in protocol support.
Ports and troubleshooting: Distinguish local entry points from server ports
A port number is a specific configuration value, not an identifier for a core. The examples below use 10808 for a local SOCKS entry point and 443 for a remote server port. Neither is a required default, and they are not interchangeable. Check the actual values in the client settings and node editor.
For example, if an app requires you to enter a SOCKS proxy manually, its address could be 127.0.0.1:10808, provided the client is actually listening on that port. Use the provider’s value for the remote port in the node editor. For ordinary local use, keep the listener bound to loopback; don’t expose it on every network interface just to troubleshoot.
| Symptom | Check first | Next step |
|---|---|---|
| No entries after updating the subscription | Update status, whether the group is enabled, subscription format, and filters | Verify subscription parsing before investigating core compatibility |
| Startup immediately reports an unknown field | Client logs, core version, and configuration format | Update to a compatible client and keep the original node settings |
| Connection times out | Server address, remote port, and current network reachability | Try another network on the same device; change only one setting at a time |
| TLS or authentication failure | System time, SNI, UUID, and REALITY settings | Compare each setting against the provider’s details |
| Logs look normal, but apps cannot connect | System proxy, VPN permission, routing, and DNS | Confirm that app traffic is reaching the local entry point |
Before switching cores: Keep a reproducible baseline
Before switching cores, save the working node and routing settings. A GUI client may regenerate config.json when it starts or switches nodes, so this guide recommends making changes through the interface and keeping a record rather than editing a temporary generated file. Xray and V2Fly share some configuration fields, but that does not make their entire JSON configurations interchangeable.
- Node requires REALITY or Vision: Use a compatible Xray setup and check the client and core versions.
- Existing VMess node is stable: Keep your current setup unless you have a clear reason to switch.
- Switching for speed alone: Hold the node, network, destination site, and test window constant, then compare latency and sustained throughput. Don’t attribute a change in routes to the core.
- Something breaks after switching: Restore the last working configuration, then compare the protocol, transport, security layer, traffic coverage, and routing one at a time. Don’t change everything at once.
Bottom line: Meet protocol requirements first, then reduce variables
The first criterion when choosing a core is whether the node works with its original settings. Once compatibility is established, compare day-to-day connection performance. When troubleshooting, change one setting at a time to pinpoint whether the problem is subscription parsing, the core, or traffic routing.