Xray vs. V2Fly Core: XTLS, REALITY, and Configuration Compatibility

At a glance

Choose a core based on what your node requires, not the client’s name. Standard VMess, WebSocket, and TLS configurations may work across both core families. Nodes using REALITY or xtls-rprx-vision require an Xray implementation. This guide compares features and configuration fields, then walks through troubleshooting for anyone choosing an Android client, switching desktop cores, or dealing with a node that imports but won’t connect.

1. What the Xray core, V2Fly core, and clients each do

V2Ray was originally the name of a proxy project and its core application. The V2Fly community continues to maintain v2ray-core. Xray-core grew from related code in 2020 and has since followed its own feature and configuration roadmap. The two share a history, but they are not simply different display names for the same program, and their names alone don’t tell you which version is newer.

The core handles the actual protocol handshakes, transport, DNS, and routing. A client provides subscription management, node editing, connection controls, and logs, then converts its interface fields into a core configuration. Whether a node works depends both on whether the client can represent its settings and whether the core implements the required features.

Parse subscription Map fields Load core Complete remote handshake Route outbound traffic

v2rayN: A desktop client. When troubleshooting, check which core is selected; the client version number is not the Xray or V2Fly core version.
v2rayNG: An Android client. This article covers its Xray core configuration path, suited to nodes that require features such as REALITY or Vision.
v2flyNG: An Android client that uses the V2Fly core. Before choosing it, confirm that the node’s protocol, transport, and configuration format are supported by your version.

A node appearing in the list only means the subscription was parsed into an entry. The connection is confirmed only after the core loads the configuration and completes a handshake with the remote server. A successful import is not the end of a compatibility check.

2. Feature differences: Vision and REALITY

VMess and VLESS are proxy protocols; WebSocket and TCP are transports; TLS and REALITY are options for connection security. XTLS Vision is a flow-control mechanism used with specific connection combinations. These belong to different layers, so changing VMess to REALITY does not describe a complete configuration change.

Feature	Xray core	V2Fly core	What to check
VMess	Supported	Supported	Also verify the transport, TLS, and authentication fields
Basic VLESS	Supported	Supported in relevant versions	VLESS alone does not imply Vision support
WebSocket + TLS	Supported	Supported	Check the path, Host, SNI, and certificate
XTLS Vision	Supports the corresponding flow control	Does not support Xray Vision flow control	Check xtls-rprx-vision
REALITY	Supported	Does not support Xray REALITY	Check the security layer and server public key settings
DNS and rule-based routing	Available	Available	Check the specific fields and configuration format separately

A common value for the Vision field is xtls-rprx-vision. It is neither an alias for legacy XTLS configuration nor a performance option that can be added to any transport. A common setup combines VLESS with TCP and TLS or REALITY; the client’s flow-control setting must match the server’s.

REALITY is not the same as disabling certificate verification. It uses a different handshake and authentication mechanism. Clients typically need the server public key, an allowed server name, a short ID, and a fingerprint. Simply changing a standard TLS node’s security layer to REALITY won’t make it connect.

Bottom line: Choose a core based on the node’s required features

If a node uses security=reality or flow=xtls-rprx-vision, make sure the configuration path supports Xray. For standard VMess + WebSocket + TLS, check that the fields match before switching cores just because their names differ.

3. Key fields compared across node types

The two cards below illustrate how fields relate; they are not ready-to-import nodes. The example ports and paths show what those fields are for. Get actual values from your node provider. A server listening on port 443 does not prove it uses TLS, let alone REALITY.

VLESS + REALITY + Vision

Transport: TCP
Security layer: REALITY
Flow control: xtls-rprx-vision
Identity fields: UUID, server public key, short ID
Handshake fields: serverName、fingerprint

Use an Xray core that supports this combination, and match each setting to the server parameters. Whether the short ID can be empty depends on the server’s allowed values.

VMess + WebSocket + TLS

Transport: WebSocket
Security layer: TLS
Authentication: UUID; modern configurations typically use alterId=0
Example path: /ws; match the server’s capitalization
Domain fields: WebSocket Host and TLS serverName

Both core families provide the relevant capabilities. Host, connection address, and certificate name serve different purposes; don’t treat them as interchangeable.

In REALITY share links, pbk usually contains the server public key, sid is the short ID, sni is the server name, and fp is the client fingerprint identifier. Field names in a share link, a client’s editing interface, and native JSON keys may differ. A client that supports the format must map them correctly.

4. Configuration compatibility: A share link is not native JSON

The same node can be represented as a share link, a subscription entry, or native JSON, but these are not interchangeable files. A share link mainly describes node parameters. A native configuration may also include local inbounds, DNS, routing, logging, and multiple outbounds. Converting a full configuration into a node link often loses settings and behavior.

First, identify the configuration source. vmess:// and vless:// are share-link prefixes. JSON organized as objects may be a complete core configuration or just an API response from a service provider.
Next, identify the JSON dialect. V2Fly configuration formats and Xray’s evolving fields are not interchangeable. Even when both use top-level inbounds and outbounds, their nested fields may differ.
Compare outbounds layer by layer. Start with the protocol and user authentication, then check transport, security layer, and flow control. Don’t fill in missing REALITY-specific settings with standard TLS settings.
Finally, migrate environment settings. Check local listen addresses and ports, DNS, routing tags, and rule order. If the handshake succeeds but routing behaves unexpectedly, changing the UUID or public key is usually not the answer.

Switching native JSON from Xray to V2Fly is not a matter of replacing the executable. A core may reject unknown values outright or ignore some fields in certain parsing paths; neither outcome counts as a successful migration. First validate the configuration with the target core, then make a real proxy request.

xray version
xray run -test -config client.json
v2ray version

These commands are for desktop command-line environments: the first two check the Xray version and validate an existing client.json; the third checks the V2Fly version. Prepare the file first. Command-line options may vary by release, so check help before running them. Configuration validation can catch parsing and some initialization issues, but it cannot replace a network connection test.

5. Choosing between v2rayNG and v2flyNG

On Android, choose a client based on the node’s capabilities rather than guessing from its name. If your provider explicitly requires VLESS + REALITY + Vision, use the Xray path in v2rayNG and confirm that the client and its bundled core support the subscription fields. If you already have a native V2Fly configuration, first check whether v2flyNG’s configuration import and core version support that format.

Node requires REALITY or Vision: Use v2rayNG and check that the security layer, public key, short ID, fingerprint, and flow-control settings are all present.
Existing node uses VMess + WebSocket + TLS: Either client may work. Keep the combination that imports, handshakes, and routes traffic correctly. Back up your subscription and local settings before switching.
Custom DNS or routing is involved: Check the configuration generated by the client. A successful node import alone does not prove full compatibility.
Using v2rayN on desktop: Record the client version and selected core version separately. After switching cores, restart the connection and use fresh logs for troubleshooting.

There is no universal rule that Xray is always faster or V2Fly is always more stable. Node location, packet loss, server load, transport, and routing all affect performance. For a fair comparison, use the same server, protocol combination, test target, and roughly the same time of day. Otherwise, differences may come from the network route rather than the core.

6. Troubleshooting: Imported successfully, but won’t connect

First, distinguish the local proxy entry point from the remote server port. The numbers below are examples for a troubleshooting setup, not defaults for every client or speed-test results. Use the actual local port configured in your client and the remote port provided with the node.

443

Example remote TCP listening port

10808

Example local SOCKS entry port

127.0.0.1

Desktop local proxy listen address

Confirm which core is running. Start the current node, read the latest logs, and note the core family, version, and first error. Don’t rely on the installation package name alone.
Troubleshoot configuration loading failures. If you see an unknown protocol, security layer, or flow-control value, first check feature support. Changing DNS repeatedly won’t help if the core hasn’t started successfully.
Troubleshoot network reachability. Confirm that the server address resolves, the remote port is correct, and the network allows the connection. An accessible TCP port proves only that the transport endpoint can be reached, not that authentication succeeded.
Troubleshoot handshake errors. For standard TLS, check the device clock, serverName, and certificate chain. For REALITY, check the server public key, short ID, allowed server name, and fingerprint settings. For Vision, also verify flow control.
Troubleshoot requests that bypass the proxy. On desktop, check the system proxy or app proxy settings; on Android, check VPN permission and per-app rules. If the connection is established but traffic to the destination isn’t going through the proxy, changing protocol fields will only complicate the issue.

On desktop, if you’ve confirmed the local SOCKS entry is 127.0.0.1:10808, use the command below to explicitly access this site through the proxy. socks5h resolves the destination hostname through the SOCKS proxy, helping distinguish that path from local DNS resolution.

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://v2rayid.com/

A response from the command only confirms that this destination can be reached through the local entry under the current rules. If the core routes it directly, that does not prove the remote proxy exit is working. Check access logs to confirm the outbound route, then verify the result with a trusted exit-IP lookup service. A single timeout does not prove core incompatibility; check whether the failure occurred at the local connection, remote handshake, or destination access stage.

Bottom line: Change one layer at a time

First make sure the core loads the configuration, then verify the remote handshake, and finally check DNS and routing. Change one field at a time and keep logs from before and after each change to distinguish missing features, incorrect parameters, and traffic that never entered the proxy.

7. Common compatibility questions

Does every VLESS node require Xray?

Not necessarily. Basic VLESS and VLESS + REALITY + Vision have different feature requirements. Check the transport, security layer, and flow—not just whether the link starts with vless://. If the node uses Xray-specific features, choose an implementation that supports them.

Can enabling allowInsecure fix REALITY errors?

No. It is not a fix. Skipping standard TLS certificate verification won’t add missing REALITY support or correct a wrong public key, short ID, or flow-control setting. Restore normal verification and use the logs to check the required connection parameters.

Will routing rules for traffic in and outside mainland China stay the same after switching cores?

Not necessarily. Routing tags, rule order, domain resolution policies, and geodata files can all affect the result. During migration, keep one clear proxy test route, confirm the node works, then restore your existing rules gradually and check the actual outbound route for each destination type.