Start with your node’s requirements, then choose a core. For VLESS with XTLS Vision and REALITY, use an Xray version that supports the required features. For VMess, WebSocket, TLS, and similar configurations, check that the settings match on both ends. This guide is for users who have imported a subscription and need to check core compatibility. It covers protocol layers, Android client choices, and what to verify after switching cores.
Understand the client, core, and Project V branches
First, distinguish the interface from the connection engine. v2rayN, v2rayNG, and v2flyNG are clients: they save nodes, manage subscription groups, generate configurations, and display logs. The core reads the configuration and handles proxy protocols, DNS lookups, and routing. A client’s ability to parse a subscription link does not mean its core supports every parameter in that link.
Project V is an ecosystem of related tools and protocols, and the V2Fly community maintains the V2Ray core within it. Xray-core forked from V2Ray in 2020 and has developed independently since. The two share some protocols and configuration concepts, but their newer features, field formats, and release schedules have diverged. They are not two skins for the same program, and version numbers are not a meaningful way to compare capabilities across projects.
- v2rayN: A desktop client. Check which core the selected node actually uses, based on the options in your current release; don’t rely only on the executables in the installation folder.
- v2rayNG: An Android client that uses the Xray core. Support for newer features also depends on the bundled core version.
- v2flyNG: An Android client that uses the V2Fly core. It’s suited to setups and troubleshooting based on V2Fly’s configuration formats and protocol capabilities.
Understand the roles of VLESS, Vision, and REALITY
“VLESS + TCP + REALITY + Vision” describes a set of settings that work together, not four interchangeable protocol names. VLESS is the proxy protocol, TCP is the transport, REALITY is a security layer, and Vision is an Xray flow-control mode. Treating different layers as a single switch is a common reason a subscription imports successfully but the handshake fails.
| Name | Primary role | What to check |
|---|---|---|
| VMess | Proxy protocol with authentication and associated data protection | UUID, transport settings, server compatibility; modern configurations typically use alterId set to 0 |
| VLESS | Lightweight proxy protocol that does not provide transport encryption on its own | UUID, encryption field, security layer, and flow settings |
| WebSocket | Carries proxy traffic | Path, Host, reverse proxy settings, and whether TLS is used |
| TLS | Establishes a secure connection using certificate validation and related mechanisms | SNI, certificate domain, system clock, and certificate chain |
| XTLS Vision | Xray flow-control mode for specific connection combinations | xtls-rprx-vision, the associated transport, and support on both ends |
| REALITY | Security layer provided by Xray | Server public key parameters, serverName, shortId, and client fingerprint settings |
VLESS encryption=none does not mean the entire connection is necessarily sent in plaintext. To determine whether it is protected, check whether the outer layer uses TLS or REALITY. Likewise, don’t assume a connection is encrypted just because it uses VLESS. Use the complete configuration provided by the server rather than copying only the UUID.
Vision is not a general-purpose “speed boost” either. It has specific requirements for the transport and connection, so don’t add flow=xtls-rprx-vision to a WebSocket node without checking compatibility. REALITY and Vision are often used together, but they are not the same thing; enabling one does not configure the other.
Check where Xray and V2Fly support diverges
Choose a core based on the features the node actually uses. Both projects implement VMess and common WebSocket and TLS configurations, but that doesn’t mean you can copy an entire configuration file between them. Check the target release for differences in V2Fly configuration formats, Xray-specific fields, and newer transport options.
| Node requirement | Xray core | V2Fly core | How to choose |
|---|---|---|---|
| VMess | Supported | Supported | Check authentication, transport, security layer, and version compatibility |
| WebSocket + TLS | Common combinations supported | Common combinations supported | Keep parameters such as path, Host, and SNI consistent |
| Basic VLESS configuration | Supported | Check protocol implementation and configuration format in the target release | VLESS alone does not imply Vision or REALITY support |
| XTLS Vision | Use a version that supports the feature | Does not support Xray’s Vision flow control | Use a compatible Xray version when the node requires this flow |
| REALITY | Use a version that supports the feature | Does not support Xray’s REALITY configuration | Renaming fields cannot convert it to standard TLS |
The history of basic VLESS implementations and differences between releases shouldn’t be reduced to “all V2Fly versions support it” or “VLESS is identical in both projects.” The practical distinction is clearer: if a node requires REALITY or xtls-rprx-vision, choose a client and core within Xray’s support range rather than expecting V2Fly to ignore those fields.
Xray core
RecommendedFor this guide’s VLESS, Vision, and REALITY combinations, Xray is the recommended choice. Keep the security layer and flow parameters provided by the server, and make sure the client’s bundled version supports them.
Best for: connections where the node explicitly requires REALITY or XTLS Vision.
V2Fly core
Use verified protocol and transport combinations within the V2Fly configuration system. Existing VMess deployments can be checked for compatibility and kept in place; there’s no need to migrate solely because the branch names differ.
Best for: setups where the server provides a V2Fly configuration and does not rely on Xray-specific features.
Check subscription settings and connection ports
Updating a subscription fetches node details; it does not convert an incompatible protocol into a compatible one. For a VLESS node, first check the address, port, and UUID, then verify the transport, security layer, SNI, and flow. For REALITY nodes, also check the server-provided public key parameters, shortId, and client fingerprint. Field names can vary between versions, so refer to the current client interface and core documentation.
These are two different ports. The remote port connects to the server; the local listening port lets your browser or another program connect to the proxy on your device. Changing the remote port from 443 to the local port 10808 won’t fix a connection failure. Two local processes using the same listening port can also prevent a core from starting. These numbers are examples, not values for your device.
- Save the original node details. Before making changes, keep a copy of the subscription group and node parameters. Don’t share a full link that contains a token or UUID.
- Match the security layer. If the server requires REALITY, don’t switch to TLS in the client; if it requires TLS, don’t enter a REALITY public key.
- Match the flow. Set
xtls-rprx-visiononly when the server configuration requires it and the combination is supported. - Match the transport fields. A WebSocket path such as
/example-wsis only an example; replace it with the actual server value. Don’t add a path to a TCP node based on this example. - Run a real connection latency test. Record the test time and logs. TCPing only indicates whether the target port is reachable; it does not confirm that authentication or the security handshake succeeded.
Choose a desktop and Android setup
On desktop, first check which core the selected node uses in v2rayN, then test it. To review local listening and proxy settings, open Settings → Parameter Settings; the layout may vary by release, so refer to your actual interface. Subscription groups organize sources, and updating a subscription refreshes node details. Neither action switches the core.
Setup guide: choose a client based on node features
Desktop: v2rayN
- For REALITY or Vision nodes, confirm that the client actually uses a compatible Xray core.
- Keep the original subscription group and test the same node before and after switching.
- Check the core startup log first, then check the system proxy and routing.
Android: choose by core
- For Xray-specific features, choose v2rayNG with a bundled version that meets the requirements.
- For V2Fly configurations, use v2flyNG and check field compatibility.
- Update subscriptions separately; configure per-app proxying and local rules on each device.
Sharing a subscription URL does not sync local settings. Whether nodes match on both devices depends on the subscription content, parsing support, and when each one was updated.
When migrating, don’t change the core, DNS, routing, and proxy mode all at once. Keep the node unchanged, confirm the new core starts and passes a real connection latency test, then restore routing settings one at a time. System proxy settings and Android traffic routing work differently, so the same node can behave differently across apps on each platform.
Use logs to distinguish compatibility issues from network errors
First identify which layer is failing. Errors while reading the configuration usually point to a field or core issue; remote connection timeouts usually point to the address, port, or network; handshake errors call for a check of the security settings. Don’t update the subscription every time an error appears: that removes your original comparison point and may not address the cause.
Why does a REALITY node import successfully but still fail to connect?
Importing means the client parsed the link; the core handles the connection. Check the startup log for the Xray version and the actual executable path, then verify the server public key parameters, serverName, shortId, and fingerprint settings. Finally, run a real connection latency test instead of relying on whether the node appears in the list.
The log says unknown field. Can I delete that line?
First check which project and configuration format the settings belong to. If the field is for REALITY or Vision, deleting it can change how the connection works and is not a compatibility fix. Use a core version that supports the field, or ask the server for a separate, complete node configuration that is compatible.
Can I change REALITY to TLS to use another core?
Changing the client setting alone won’t work. The two security layers use different handshakes and server settings. The client can connect with TLS only if the server has a separately configured TLS inbound and provides the matching port, certificate domain, and authentication details.
TCPing succeeds, but the real connection test times out. What should I check first?
First check the UUID, flow, security layer, and SNI, then look in the logs for authentication or handshake failures. If the real connection test succeeds but your browser still fails, check the system proxy, local port, and routing rules. Also make sure the test destination itself is reachable.
Will switching to Xray make the connection faster?
You can’t tell from the core name alone. Keep the network, server, and test destination the same, then compare real connection latency and actual request results. Server load, routing, DNS, and network conditions all affect performance; a successful connection does not guarantee higher throughput.
Keep a repeatable verification sequence: confirm the core starts, confirm the node completes a real request, then confirm where app traffic is routed. For setup steps, see real connection latency testing and system proxy settings. For Android configuration, see the Android setup guide. Choose based on the server’s requirements and the client’s actual capabilities, not a protocol label alone.