Start with your node’s requirements, then choose a core. If your subscription includes REALITY or xtls-rprx-vision, use an Xray core that supports the required features. For nodes using only VMess, WebSocket, and TLS, check the transport settings and test the connection. This guide is for anyone choosing an Android client, switching desktop cores, or troubleshooting an imported node that won’t connect. It covers compatibility limits and verification steps—not speed claims based on core names.
Know the difference between the client, core, and node configuration
In v2rayN, select a node, right-click it, and choose “Edit server” to review its protocol, transport, and transport security settings. The window lets you edit and view the configuration; the core running in the background handles the connection. Updating the client does not necessarily change the core currently in use. Importing a node also does not guarantee that the current core supports every field in its configuration.
The V2Fly community maintains the V2Ray core. Xray-core forked from the V2Ray codebase in 2020, and the two have evolved independently since then. They share a history, but they are not interchangeable binaries. New features may differ in their configuration fields, default behavior, and release timelines. Don’t assume one core will handle the other’s configuration identically.
- Clients: v2rayN manages subscriptions, nodes, and proxy settings on desktop; v2rayNG and v2flyNG are Android clients.
- Cores: Xray or V2Fly handles protocol processing, transport connections, DNS, routing, and other core functions.
- Nodes: Describe the remote address, port, credentials, and the transport and security settings required by the server.
- Subscriptions: Distribute node details. They are not proxy protocols and cannot automatically fill in required parameters that the server has not provided.
Protocol support: don’t stop at VMess or VLESS
Check three layers: proxy protocol, transport, and security. VMess and VLESS are proxy protocols; WebSocket and gRPC carry the connection; TLS and REALITY belong to a separate layer. Even if both sides say VLESS, the connection will fail if either side lacks the security mechanism the node requires.
| Feature | Xray core | V2Fly core | What to check |
|---|---|---|---|
| VMess | Supported | Supported | Still check the identity details, system time, and transport settings. |
| VLESS base protocol | Supported | Supports the base protocol; check the specific version and configuration format. | Base protocol support does not guarantee compatibility with Xray-specific feature combinations. |
| WebSocket and TLS | Common combinations are supported | Common combinations are supported | Check the path, Host, SNI, and certificate—not just the core. |
| XTLS Vision | Supported; must match the server configuration. | Does not support Xray’s Vision flow control. | Choose Xray if the node requires xtls-rprx-vision. |
| REALITY | Supported; requires the corresponding authentication parameters. | Does not support Xray’s REALITY implementation. | You can’t simply switch to regular TLS and expect it to work. |
| DNS and split routing | Provides these capabilities | Provides these capabilities | Check the rule syntax and behavior for the specific version. |
Use this table to identify the right direction, not as a complete compatibility list for every version. Newer transport extensions are especially likely to differ, even when they use the same field names. If the server specifies a core and minimum version, meet those requirements first, then check that the client preserves all node parameters.
XTLS Vision and REALITY: what each feature does
Start by checking the node’s flow and security settings. If you see flow=xtls-rprx-vision, the node requires Vision flow control. If you see security=reality, it uses REALITY. They’re often used together, but they’re separate features—not two switches that must always be enabled at the same time.
- Vision: An Xray flow-control mechanism that optimizes processing for eligible TLS traffic. Whether it takes effect depends on the protocol, transport combination, and traffic. It does not speed up every connection.
- REALITY: A transport security mechanism provided by Xray. The client needs the server name, public-key-related parameters, short ID, and other details that match the server; a server address alone is not enough.
- Regular TLS: Validates the certificate and server name according to the node settings. It is not a “compatibility mode” for REALITY; changing the security type changes the handshake.
- Combination limits: Don’t add Vision flow control to an arbitrary WebSocket or gRPC node. Import the full combination provided by the server instead of stacking options just because they seem more secure.
If an imported share link is missing flow control or REALITY fields, check the client and core versions first, then ask the node provider about the link format. Subscription converters can drop extension fields. Guessing a short ID or server name won’t restore the original configuration.
Choosing a client: v2rayN on desktop, Android based on node requirements
Start by listing the node types you actually use. If your subscription includes nodes that require REALITY or Vision, choose the Xray-based v2rayNG for Android. If your existing nodes and workflow are built around V2Fly configurations, v2flyNG may be a better fit. These recommendations are based on feature compatibility, not which client name sounds newer.
v2rayNG: best for Xray-based nodes
RecommendedIf an Android node explicitly requires REALITY, XTLS Vision, or another Xray feature, choose a compatible client and check its bundled core version. This recommendation applies specifically to those node requirements.
Best for: Android users with nodes that combine VLESS, REALITY, and Vision.
v2flyNG: keep your V2Fly configuration
A good fit if you want to keep using V2Fly nodes and configurations that you’ve already verified. Whether combinations such as VMess, WebSocket, and TLS will connect still depends on the version and parameters; the protocol name alone isn’t enough to tell.
Best for: Android users whose provider explicitly uses V2Fly and who already have a stable configuration.
In desktop v2rayN, open “Settings” → “Parameter settings” and check whether your version has a core mapping option such as “Core type.” The setting may be in a different place in some versions. If you don’t see the option, don’t try to follow an old screenshot. After switching, re-enable the node and use the core name and version in the startup log to confirm what’s running.
How to check a subscription on desktop and Android
Desktop: v2rayN
- Import the subscription from the same source and check each node’s security type.
- Use Xray for nodes that require REALITY or Vision.
- Note the core version and any errors in the startup log.
Android: choose based on core requirements
- Use v2rayNG for nodes that require Xray features.
- Use v2flyNG if you already have a V2Fly-based workflow.
- After updating the subscription, compare the node count and key parameters.
Using the same subscription does not guarantee identical configurations. Check each client’s parsing support, update time, and routing settings separately.
Verify after switching: check startup, then the local proxy entry
Verify in this order: core startup, remote handshake, and application entry point. If startup fails, check the logs before changing system proxy settings repeatedly. If the core starts but apps can’t connect, determine whether the problem is the remote connection or the local entry point. The ports below illustrate these roles; they are not defaults for every installation.
- Save your current configuration. Record the node, core, system proxy status, and routing preset. Change one variable at a time and keep a working baseline you can restore.
- Confirm the core starts successfully. Re-enable the node and check the version in the logs. If you see a configuration parsing error, an unknown field, or an unsupported flow-control setting, resolve the compatibility issue first.
- Check the remote parameters. Verify the address, port, credentials, transport, SNI, and REALITY parameters one by one. The remote port is not your local HTTP or SOCKS proxy port.
- Verify the local entry point. Check the listening details under “Settings” → “Parameter settings.” Confirm whether the example address
127.0.0.1:10808provides SOCKS, HTTP, or a mixed entry point, then configure your test tool to use the matching protocol. - Check system proxy settings and routing. When testing in a browser, confirm the system proxy is enabled. Whether a terminal program uses the system proxy depends on the program itself. Routing rules may also send your test destination through a direct outbound connection.
For a speed comparison, use the same node and test destination at similar times, and run each test three times. Record connection time and sustained download performance. A single latency test only reflects the route and destination response at that moment; it can’t prove one core is faster on every network. Results are not comparable if the tests use different outbound routes.
FAQ: imports, core switching, and compatibility with older nodes
The node imports, but enabling it reports an unsupported flow. Why?
Open the node editor and check whether it includes xtls-rprx-vision, then check the startup log to confirm that Xray is running. If you’re already using Xray, check its version and the configuration generated by the client. Don’t remove flow as a first step: the server may require it, and the handshake can still fail without it.
Do older VMess nodes have to be replaced with VLESS?
No. You don’t need to change protocols just because you’re using a different core. First check the system time, credentials, and transport settings. The server determines which protocol is available; changing the VMess selection to VLESS in the client alone won’t work. You need the corresponding node details from the server.
Will switching to Xray automatically route every website through the proxy?
No. First confirm the app is using the local proxy entry point, then check the routing preset. System proxy settings provide an entry point for some apps; routing determines which outbound connection is used. TUN is a separate way to capture traffic. Switching cores doesn’t reconfigure these layers for you.
The same subscription works on desktop but not Android. What should I check first?
First confirm that both clients have the same updated node, then compare the protocol, transport, security type, and flow settings. For a REALITY node, use v2rayNG on Android with REALITY support, confirm the VPN connection is active, and make sure the test app is included in the proxy scope. Matching names in the node list don’t prove the configurations are identical.
Do I still need to check DNS if I’m using REALITY?
Yes. DNS may be involved when connecting to a server by domain name, matching routing rules, or accessing a destination site. If the logs show a DNS timeout, test the server domain and destination domain separately and check your DNS settings. Don’t attribute every resolution failure to the security handshake.
Bottom line: choose by required features, not by name
Meet the server’s requirements first, then consider the cost of switching. The main differences between Xray and V2Fly are their feature development and configuration compatibility—not that one is always faster or the other only works with older nodes. If your current nodes are stable, keep the working configuration. When you need a newer feature, update the corresponding client and core, then verify each layer.
- Node requires REALITY or Vision: Use v2rayN with Xray on desktop, configured to support the required features; choose v2rayNG on Android.
- Node uses a verified V2Fly configuration: You can keep your existing workflow and use v2flyNG on Android. There’s no need to switch just for a different name.
- Only VMess, WebSocket, TLS, and similar details are provided: Ask the provider for the path, Host, SNI, and other missing parameters before checking compatibility.
- Connection fails: Troubleshoot configuration parsing, the remote handshake, the proxy entry point, and routing—in that order. Avoid changing several settings at once.