What’s the difference between Xray Core and V2Fly Core: protocol support, performance, and client compatibility

When choosing a client, seeing “Xray core” and “V2Fly core” can make it seem as though they are simply two names for the same program. In practice, the graphical client handles subscription imports, node selection, system proxy settings, and interface interactions. The core parses the configuration, establishes connections, applies routing, and processes traffic. Whether a node can use a particular protocol combination ultimately depends on whether the active core recognizes its fields.

Both Xray and V2Fly carry forward Project V’s configuration model, so common inbound, outbound, routing, DNS, and policy structures remain similar. They overlap considerably for VMess, conventional transports, and basic routing, but their development paths have diverged. Xray has expanded more aggressively into VLESS, XTLS Vision, and REALITY, while V2Fly continues maintaining the V2Ray core and its configuration system along its own release line.

That is why core comparisons should not begin and end with “which one is faster.” A better sequence is to identify the protocol and security layer used by the subscription nodes, confirm which core the client actually runs, and only then compare the local device and network conditions. Speed-test figures mean little when the protocols are incompatible; when they are compatible, network quality often matters more than the core’s name.

Shared origins do not mean interchangeable configurations

V2Fly is a core implementation line maintained by the V2Ray community, preserving the modular design of the proxy platform. Xray grew from the earlier V2Ray codebase and, while retaining some compatible configuration concepts, added independent protocol capabilities, transport options, and security mechanisms. Both can serve as proxy cores, but they are now separately released and developed projects.

Their common foundation is clearest in the configuration model. A typical configuration still describes a local inbound port, a remote outbound, domain resolution, and routing rules. A SOCKS inbound might listen on local port 10808, while an HTTP inbound listens on 10809; routing then chooses direct, proxied, or blocked outbounds by domain or address range. These structural concepts appear in both project lines.

The differences emerge in specific fields and implementation details. Subscription parameters such as `security=reality`, `flow=xtls-rprx-vision`, the public key, short ID, and server name map to Xray’s REALITY and Vision capabilities. Giving such a node to a core that does not support those fields can result in parameters being dropped during import, an unknown-configuration error at startup, or an immediate disconnect after the connection is established.

Protocol support: focus on VLESS, XTLS, and REALITY

VMess is one of the most established protocols shared by both technical lines. Mature combinations such as VMess + TCP and VMess + WebSocket + TLS are generally handled by both Xray and V2Fly. When the server parameters, user ID, port, transport path, and TLS domain match, client-side compatibility is broad. At that point, focus on server reachability, clock synchronization, and complete subscription fields.

VLESS is an important clue when choosing a core. If a node also includes `xtls-rprx-vision` or REALITY parameters, use the Xray core directly. Vision is not simply a TLS replacement; on suitable traffic paths, it reduces unnecessary repeated processing. REALITY provides a handshake and identity-verification mechanism implemented by Xray. They often appear together, but neither is a universal “turn it on and get faster” switch. The server and client must match exactly.

Matching transport names do not guarantee interchangeable configurations. A WebSocket path and Host, gRPC’s serviceName, TLS’s serverName, and REALITY’s publicKey, shortId, and fingerprint all affect the connection. Missing one field can make two apparently identical nodes behave completely differently. When converting a subscription or copying a node manually, verify every field instead of keeping only the server address and port.

Performance: the protocol path matters more than the core name

With the same server, network path, and protocol, Xray and V2Fly may show no visible speed difference. Connection speed is also affected by server CPU, link congestion, round-trip latency, packet loss, the TLS handshake, transport encapsulation, and local routing rules. If changing the core also changes the node, the result cannot demonstrate core performance.

A reproducible comparison should keep the server, port, user parameters, and test window fixed. For example, on a 300 Mbps local connection with 42 ms baseline round-trip latency and less than 0.3% packet loss, five consecutive tests of the same VMess + WebSocket + TLS node might produce 184–197 Mbps and 181–195 Mbps. The ranges overlap, so they cannot prove that either core is always faster.

If you switch to Xray-only VLESS + Vision + REALITY, the comparison is no longer equivalent because V2Fly cannot run the same configuration path. Xray’s advantage is that it supports the capability, not that it delivers a fixed percentage gain under identical functionality. Meet protocol requirements first, then discuss throughput and resource use.

Client compatibility: choosing among v2rayN, v2rayNG, and v2flyNG

v2rayN is a graphical desktop client that handles subscriptions, node management, system proxy settings, routing, and core invocation. Modern VLESS, Vision, and REALITY nodes generally run with the Xray core. On Windows, check the core-related options under “Settings” → “Parameter settings” in v2rayN, then confirm the loaded core name and version in the startup log. Do not infer them from the client name alone.

v2rayNG is a popular Android client built around the Xray core, suitable for importing VMess, VLESS, and subscriptions containing REALITY parameters. The first connection also requires system VpnService authorization. If the node shows as connected but the browser has no traffic, check the VPN status in the notification shade first, then verify that per-app proxy settings have not excluded the target app.

v2flyNG follows the V2Fly core line and suits Android environments that rely on the V2Ray core system, VMess, and established transport configurations. Its interface may resemble v2rayNG, but that does not make the underlying capabilities identical. Importing a REALITY share link into v2flyNG may show the node successfully, but that does not mean the core accepted its critical parameters.

1. Desktop: check the node protocol first: When a subscription contains VLESS, REALITY, or Vision, confirm that v2rayN is using the Xray core.
2. Android: choose by core family: Use v2rayNG for Xray features; use v2flyNG when you specifically need the V2Fly configuration system.
3. Expand node details after importing: Check the address, port, user ID, transport, TLS, SNI, Flow, public key, and short ID.
4. Check the runtime log after connecting: Confirm the core version, configuration load result, and actual outbound in the log instead of treating the latency shown in the interface as proof of connectivity.

A subscription imports but will not connect? Troubleshoot it in this order

A subscription only distributes node information; it does not remove core differences. After fetching it, the client must parse share links or structured data and convert the parameters into a core configuration. If any step does not recognize a field, the result may be “the node is listed, but the connection fails.” Troubleshoot the four stages in order: subscription parsing, core loading, network connection, and protocol handshake.

First, open the node details. If the protocol is VLESS, the security setting is REALITY, and Flow is `xtls-rprx-vision`, confirm that the client is actually using Xray. Next, check the logs for `unknown field`, `failed to load config`, `failed to dial`, or handshake errors. Configuration-load errors usually point to a field or core mismatch; dial timeouts are more likely related to the address, port, network path, or server status.

Third, check the local proxy ports. v2rayN commonly listens on 10808 for SOCKS and 10809 for HTTP, but after changing the settings, use the actual values under “Settings” → “Parameter settings.” If the browser is manually set to 10809 while the client now listens on 10808, the core may be connected normally but browser traffic will not enter the correct inbound.

Fourth, temporarily test with basic routing. Complex rules may send the test domain through a direct outbound, creating the illusion that the node is not working. Switch to global proxy mode or the simplest rule set to verify the connection, then restore domain-based routing and review the rules in order. Routing usually matches rules sequentially, so an overly broad direct rule placed first can intercept traffic before later proxy rules.

• The log fails during configuration loading: check the core type, configuration version, and node fields.
• The log shows a timeout connecting to the remote: check the server address, port, firewall, and current network path.
• The connection drops immediately after the handshake: check the user ID, SNI, Flow, REALITY public key, and short ID.
• The core is running normally but webpages have no traffic: check the system proxy, VpnService status, and local listening ports.
• Some websites work while others fail: check DNS, domain rules, address rules, and rule order.

What to consider when upgrading and migrating configurations

Upgrading a core is more than replacing an executable. As versions evolve, configuration fields, default behavior, routing resources, and protocol implementations may change. Long-term environments should record the working version, client version, node type, and custom rules, then rerun the same test checklist after an upgrade instead of merely confirming that the core starts.

As a fixed test baseline, you might record Xray 25.6.8 and V2Fly 5.30.0 as two independent release lines, along with the test date, configuration source, and enabled protocols. These numbers make the experiment reproducible; they do not imply that the releases correspond in date or feature level. Xray’s date-based versions and V2Fly’s 5.x versions cannot be compared by number to determine which is newer.

When migrating from a V2Fly environment to Xray, VMess, basic inbounds, and conventional routing can be converted item by item, but DNS, policies, transport parameters, and resource files still require review. Reverse migration requires removing or replacing Xray-specific configuration first; outbounds containing REALITY or Vision fields cannot be handed to V2Fly unchanged. The safest approach is to keep the original configuration, create a copy for migration, and change one module at a time.

Common questions

Most users do not need to maintain two cores at once. Choose based on the most demanding capability in the subscription: select Xray if REALITY or Vision is present; if every node is verified VMess with conventional transports and the existing V2Fly setup has been stable, continuing with it is reasonable. Switching cores frequently only increases configuration differences and troubleshooting overhead.

In short, the key difference between Xray and V2Fly is their feature direction, not a simple brand swap. Xray is better suited to environments requiring VLESS, XTLS Vision, REALITY, and compatibility with modern subscriptions. V2Fly suits continued maintenance of the V2Ray configuration system and established VMess deployments. For clients, use v2rayN with the Xray core on desktop, and choose v2rayNG or v2flyNG on Android according to the same core family.

The reliable basis for choosing is always the node fields, runtime logs, and reproducible tests. Confirm protocol support first, verify transport, security, and routing next, and compare performance under identical conditions last. This avoids two common mistakes: assuming an imported node is automatically compatible, and assuming a core change must make it faster.