Xray vs. V2Fly Core: Protocol Support, Performance, and Configuration Compatibility

Know the Difference Between Clients, Cores, and Node Protocols

v2rayN, v2rayNG, and v2flyNG are clients for managing subscriptions, editing configs, viewing logs, and controlling connections. The core establishes proxy connections, applies routing rules, and handles traffic. VMess and VLESS shown in a node list are protocol names, not client names. Changing the client interface does not change which protocols the server accepts.

The V2Fly community maintains the V2Ray project; this article uses “V2Fly core” to refer to that implementation. Xray is an independent core developed as a fork of the V2Ray project. They share a history, but they are no longer two names for the same program. Protocol extensions, config fields, and version changes may differ.

• Desktop: v2rayN manages nodes and runs the configured core. Being able to enter a field in the UI does not mean the active core supports it.
• Android: v2rayNG uses the Xray core; v2flyNG uses the V2Fly core. Choose the app that matches your node requirements rather than treating them as interchangeable shells for different cores.
• Server: Determines the protocol, listening port, identity parameters, transport, and security layer. The client must match these settings.

Protocol Support: VLESS Isn’t REALITY, and XTLS Isn’t TLS

When comparing cores, it’s easy to conflate protocols with security layers. VLESS is a proxy protocol; TCP and WebSocket are transport options; TLS and REALITY are connection security settings; and xtls-rprx-vision is a flow value that requires a compatible implementation. To understand a node config, check each layer separately.

Basic VLESS does not provide transport encryption. Don’t skip the security layer just because a node uses VLESS, and don’t switch the REALITY setting to TLS as a compatibility workaround. If the server requires REALITY, the client must use a compatible implementation and the parameters supplied by the server.

Legacy XTLS configs and current Vision configs are not interchangeable either. Flow values, transport names, or security fields in older guides may no longer apply to current versions. When migrating, use the complete parameters from the node provider and check the core logs. Don’t assume similarly named settings are interchangeable.

Choosing a Client: Match Xray or V2Fly to Your Node

The recommendations below apply specifically when a node requires REALITY or Vision. They do not mean one core is faster on every connection or device. If the server already provides a working V2Fly config and you don’t need additional features, keeping the existing setup usually makes it easier to isolate variables than swapping cores.

1. Check the fields: Open the node editor and look for security=reality or flow=xtls-rprx-vision. If either is present, start with an Xray config.
2. Check desktop settings: In v2rayN, open Settings → Parameters and look for the core options in your version. If the version lets you assign cores by protocol, check the mapping for the node’s protocol. The option may be in a different place in other UI versions.
3. Check the runtime: Save the node, set it as the active server, and check the logs for the core name, version, and startup errors. Don’t rely only on the selection shown in Settings.
4. Check the Android app: In v2rayNG or v2flyNG, long-press the node in the list and open its settings. If the app cannot represent a required field, switch to a compatible client instead of removing the field.

Config Compatibility: Importing a Share Link Doesn’t Make JSON Configs Interchangeable

Importing a subscription and migrating a full config are two different things. A share link usually describes a single outbound node; after parsing it, the client generates local inbound, DNS, routing, and other settings. A full JSON config may also contain extensions specific to a particular core. Even if both clients can import the same VMess link, that doesn’t mean you can use either full JSON config in the other client unchanged.

For example, the three fields below come from Xray REALITY and Vision configs. They illustrate what to look for; they are not a runnable config and should not be used to assemble a node:

"protocol": "vless"
"security": "reality"
"flow": "xtls-rprx-vision"

When migration fails, first distinguish a config parsing error from a remote handshake failure. Logs showing an unknown field, unknown security type, or unsupported flow point to a local config issue. If the core starts but the handshake fails, check the address, port, identity parameters, security layer, and system time. Don’t disable certificate validation as a substitute for diagnosing the problem.

Performance: Test Under the Same Conditions Instead of Ranking Core Names

Xray Vision optimizes a specific TLS traffic handling path, but that doesn’t guarantee the same gains for every protocol or workload. Network congestion, server load, transport encapsulation, device CPU, and network changes may matter more than the core. Comparing latency across two different nodes cannot establish which core performs better.

Start by using the same test entry points. The ports below are examples for troubleshooting, not client defaults; use the values shown in Settings and startup logs. A remote port of 443 does not necessarily mean the service uses standard TLS.

• Keep the connection the same: Use the same device, network, server, and protocol combination supported by both cores. Don’t use WebSocket on one side and a different transport on the other.
• Keep the workload the same: Run each test 3 times, downloading the same test file for 30 seconds each time. Record median throughput, CPU usage, and error count. This is a test method, not a benchmark result from this site.
• Separate the metrics: TCP handshake latency reflects only the connection entry point. A real connection test also depends on the destination and security handshake; download throughput is a better indicator of sustained transfer performance.
• Control background activity: Pause automatic subscription updates and other downloads. On Android, keep the power mode consistent to avoid mistaking system throttling for a core performance difference.

If only a REALITY node is available, there’s no valid way to switch to V2Fly while keeping the protocol the same. In that case, evaluate Xray’s connection stability and resource usage on your device instead of changing the server protocol just to make a comparison.

Troubleshooting After a Switch: Check Core Startup, Then Routing and DNS

A core starting successfully doesn’t mean app traffic is going through the proxy. On desktop, the system proxy affects only apps that follow that setting; on Android, the VPN connection and per-app rules determine which apps are routed through it. Changing routing, DNS, and proxy mode along with the core makes issues harder to reproduce. Change one thing at a time.

1. Check startup logs: First rule out config parsing errors and address already in use. If an old process is using the example port 10808, stop it before starting the new config.
2. Confirm the traffic entry point: On desktop, check the system proxy or the app’s manual proxy address. On Android, confirm VPN permission is granted and that the test app is included in the per-app list.
3. Check routing tags: Outbound tags in a custom config must exist. After migration, rules that still reference old tags may cause startup failures or route traffic incorrectly.
4. Check DNS: Verify the route to DNS servers and how domain rules interact with the DNS resolution policy. A DNS lookup failure cannot simply be blamed on VMess or VLESS.
5. Test a single node: Temporarily disable automatic selection and complex routing. First use an explicit proxy outbound to access a fixed destination, then restore routing rules one at a time.

To understand how domains, IPs, and outbound rules work together, see the routing section of the protocol guide. To set up the proxy entry point again, check the client configuration in the Getting Started guide. Don’t overwrite the entire runtime config.

FAQ: Subscriptions, Handshakes, and Choosing an Android App

The choice comes down to two steps: first, make sure the client and core meet the node’s protocol requirements; then verify the connection and performance under the same conditions. REALITY and Vision are clear feature-based reasons to choose a core. For standard VMess or basic VLESS configs, also check the transport, security layer, and config format instead of choosing by core name alone.