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

When a subscription includes VMess, VLESS, Trojan, WebSocket, gRPC, and REALITY nodes, startup depends on more than the client name. It depends on the core the client invokes, the transports and security layers that core supports, and the fields generated after subscription conversion. Xray and V2Fly share a substantial foundation, but their configuration files are not freely interchangeable.

A shared origin, separate branches: how the two cores relate

V2Ray originally established a configuration model built around inbounds, outbounds, routing, DNS, policies, and transport layers. As the project moved into community maintenance, V2Fly continued this model and maintained V2Ray Core. Xray forked from the same technical foundation, retaining many configuration objects and common protocols while expanding VLESS, XTLS, REALITY, transport implementations, and performance paths.

The relationship is therefore best understood as shared syntax with separate extensions, not as a simple replacement of one by the other. VMess over TCP, VMess over WebSocket, standard VLESS over TCP, SOCKS inbounds, and domain-based routing are usually quite similar. Compatibility boundaries become clear when Xray-specific security layers or flow-control fields are involved.

• Shared foundation: Both use a JSON-based configuration model with major objects such as inbounds, outbounds, routing, dns, and policy.
• Key fork: Xray adds and maintains XTLS and REALITY capabilities, and some fields are parsed only by Xray.
• Selection rule: Start with the node's required capabilities, then check which core the client invokes by default. Do not decide based only on which core is newer.

Protocol and security-layer differences: XTLS, REALITY, and VLESS

VMess is a foundational protocol supported by both cores. When the address, port, user ID, transport, TLS parameters, and server settings match, VMess over TCP or WebSocket can usually produce similar outbound configurations in both. Similar does not mean the entire configuration can be copied directly: logging, DNS, transport details, and experimental fields may still differ.

VLESS is a lightweight protocol. Standard VLESS with TLS is not the same as XTLS Vision, and seeing VLESS in a subscription does not automatically mean Xray is required. Check the flow field, security-layer name, and related settings object. When the flow value is xtls-rprx-vision, use an Xray core that supports it and make sure the client does not discard flow during import.

REALITY operates at the transport security layer. In addition to the address, port, and user ID, the client needs parameters such as serverName, fingerprint, public key, and shortId. A typical server listens on port 443, but the port is not a protocol identifier; other ports are also possible. A port number alone cannot determine whether a node uses REALITY.

Configuration compatibility: which fields can be reused

Both cores use layered configurations. inbounds receive traffic from local applications, outbounds define remote nodes or direct exits, routing selects an exit based on domains, IPs, ports, and network types, and dns controls query behavior. Migration usually has a high success rate when only these basic objects are used.

Most risks come from extension fields. Xray declares security as reality in streamSettings and uses realitySettings for the server name, client fingerprint, public key, and short ID. XTLS Vision commonly appears as flow inside a VLESS user object. When V2Fly encounters an unknown critical field, it may report a field or security-layer error during startup, or the client may refuse to create the node while generating the configuration.

Standard inspection path
outbounds → protocol → settings → user and server parameters
outbounds → streamSettings → network → transport method
outbounds → streamSettings → security → security layer
outbounds → streamSettings → tlsSettings / realitySettings
VLESS user parameters → encryption / flow

A subscription link is not itself a core configuration file. The server usually returns a list of share links or subscription data, which the client parses into runtime JSON. If the same subscription produces different results in v2rayN and v2flyNG, the parser may not support a field, or the underlying core may not support the required node. During troubleshooting, compare the details of a single node first instead of repeatedly deleting and re-adding the entire subscription.

Parts that can usually be reused first

• Basic conditions in routing rules, including domain, ip, port, network, and outboundTag.
• A VMess node's address, port, user ID, alterId, transport, and standard TLS parameters.
• Local SOCKS and HTTP inbound ports, after confirming that no other process is using them.
• Standard DNS server addresses and query policies, after checking the field names accepted by the target version.

Parts that must be checked again

1. Whether security is set to reality and whether realitySettings is present.
2. Whether the VLESS user object contains xtls-rprx-vision flow control.
3. Whether the transport layer uses a network type and parameters supported by the target core version.
4. Whether every outboundTag referenced by the routing rules actually exists in the target configuration.
5. Whether the tags for the DNS, direct, and block outbounds match the routing rules.

Choosing a client: v2rayN, v2rayNG, and v2flyNG

v2rayN is a desktop configuration manager for subscriptions, nodes, routing, and multiple cores. For subscriptions containing VMess, VLESS Vision, and REALITY, keep Xray as the runtime core for the relevant nodes. A common path is “Settings” → “Parameter Settings” → “Core Type Settings”; confirm that VLESS and related node types are not assigned to an incompatible core.

After starting a node, check the log area to confirm the core that actually launched. If the local SOCKS port is 10808 and the HTTP port is 10809, also verify that the system proxy points to the active ports. Even a correct node configuration cannot take over traffic when the ports are occupied by a browser extension, an old core process, or another networking tool.

v2rayNG targets Android devices and uses the Xray core, making it suitable for REALITY, VLESS Vision, VMess, and common subscriptions. After importing, open the node editor and verify the transport protocol, camouflage domain, fingerprint, public key, shortId, and flow control. Before long-pressing a node for a real connection test, start the service and confirm that live traffic changes in the status bar.

v2flyNG targets Android environments that require the V2Fly core and is suitable for keeping V2Fly servers and existing VMess configurations consistent. If a subscription also contains REALITY nodes, leave those nodes to v2rayNG instead of deleting fields and trying to connect. Removing security, flow, or the public key does not convert a REALITY node into a standard TLS node because the server handshake method has not changed.

The practical v2rayN check order

1. Open the subscription group, update the node list once, and confirm that the target node was not parsed with an empty address or port 0.
2. Go to “Settings” → “Parameter Settings” → “Core Type Settings” and check the core assigned to VLESS.
3. Open the node and verify security, flow, serverName, fingerprint, public key, and shortId.
4. Start the node and open the logs to confirm that the core is listening on 10808 or your custom local port.
5. Enable the system proxy, visit an actual destination, and then check whether upstream and downstream byte counts increase.

The practical Android check order

1. Update the subscription in v2rayNG or v2flyNG and note which node types fail to import.
2. Open the details for one node and compare them with the protocol and transport parameters provided by the service operator.
3. Start the service and run a connection test instead of relying only on the latency number shown in the subscription list.
4. If the connection fails, check the first core error in the logs before troubleshooting DNS or routing.

Performance and stability: the core name is not the only variable

With the same server, network, and transport, the everyday throughput difference between the two cores is usually less important than protocol compatibility. Server load, packet loss, round-trip latency, congestion control, TLS handshakes, DNS query paths, and client hardware all affect the result. Ranking cores from a single latency test can be misleading.

Choose one node and run three consecutive tests on the same network. Record connection setup time, time to the first web response, sustained download speed, and failure count. For example, with round-trip latency around 53 ms and packet loss below 1%, differences in VMess over WebSocket may mainly reflect line variation. With a REALITY node, V2Fly cannot provide a meaningful comparison because the protocol capabilities do not match.

• Verify the protocol first: The core must fully support the node's protocol, security layer, and flow control.
• Standardize conditions next: Keep the server, test time, network access method, and DNS configuration consistent.
• Read the logs last: Distinguish handshake failures, timeouts, DNS errors, routing mistakes, and occupied ports.

Common issues: importing, errors, and switching cores

Most compatibility problems can be located across four stages: subscription parsing, core startup, handshake establishment, and traffic capture. Identify the failed layer first, then change the relevant parameters; this is more efficient than repeatedly switching nodes or reinstalling the client.

Final selection checklist

• Subscription includes REALITY or XTLS Vision: choose the Xray core.
• Using v2rayNG: verify the subscription against the Xray node parameters.
• Using v2flyNG: prioritize existing nodes that match V2Fly capabilities.
• Using v2rayN: assign the core by protocol instead of merely replacing the executable.
• Migrating routing and DNS: check tags, fields, and target-version support one by one.
• Testing performance: run at least three consecutive rounds and record logs, packet loss, and real traffic.