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

The short answer: choose the core based on the node protocol

Xray and V2Fly are not simply “new” and “old” versions. They use similar configuration structures and share core concepts such as VMess, VLESS, SOCKS, HTTP, local routing, and DNS, but their maintenance paths have diverged. When choosing, don’t rely on the core name—or latency alone. Check the node’s protocol, transport, security layer, and flow fields, then confirm which core the client actually runs.

If the node uses VLESS with REALITY and XTLS Vision, choose Xray. REALITY and xtls-rprx-vision are key capabilities in the Xray ecosystem; V2Fly cannot establish an equivalent connection with the same parameters. If the configuration mainly uses VMess, standard VLESS, WebSocket, gRPC, TLS, and traditional routing rules, either core may work, but verify support for the exact version and fields.

How the two cores relate and differ

V2Fly continues Project V’s original technical direction. Its configurations typically revolve around inbound and outbound settings, routing, DNS, policies, and transports. Common top-level JSON objects include inbounds, outbounds, routing, dns, and log. Once you understand these structures, Xray configurations will also feel familiar.

Xray evolved from the same technical lineage and retains many similar concepts, while continuing to expand around VLESS, XTLS, REALITY, transport mechanisms, and routing. Two configurations may share large sections, yet a single security-layer field, flow value, or transport parameter can make them incompatible.

“The configuration file can be read” does not mean “the connection behaves identically.” Some unknown fields may be ignored during parsing, some trigger a startup error, and others accept different values or have different defaults depending on the core version. When migrating, check runtime logs and connection results—not just whether the client starts successfully.

The core and the client interface are different layers

v2rayN is a desktop client that manages subscriptions, node selection, the system proxy, routing modes, and core processes. The core called by the client handles the actual connection. Different versions or packages may offer different core-management options, so check the core name and version in Settings or at the start of the log instead of guessing from the window title.

The distinction is clearer on Android: v2rayNG follows the Xray core line, while v2flyNG follows the V2Fly core line. Their interfaces may look similar, but protocol extensions, import results, and available parameters depend on the core. If the provider specifies REALITY or Vision parameters, consider those parameters together with the matching core.

Protocol support: check VLESS, XTLS, and REALITY first

VMess: shared foundations do not guarantee identical combinations

VMess is common to both cores. A typical VMess node may also combine TCP, WebSocket, HTTP/2, or gRPC transports and may use TLS at the outer layer. Seeing “VMess” alone is not enough to judge compatibility; also verify the transport type, TLS serverName, path, Host, port, and user ID.

For more traditional VMess configurations, Xray and V2Fly generally have solid support. During migration, still watch for legacy fields, transport-name changes, and subscription conversion results. If the node appears after import but fails to connect, open its details and compare each field instead of repeatedly toggling the system proxy.

VLESS: the same protocol name can hide different extensions

VLESS separates authentication from the transport and security layers. Nodes typically include an address, port, user ID, transport, and encryption or security parameters. Standard VLESS configurations may have some cross-implementation compatibility, but Xray has more concentrated maintenance for VLESS extensions, especially in VLESS, Vision, and REALITY combinations.

A subscription entry containing only vless:// does not prove that both cores can use it directly. Check the query parameters security, flow, type, sni, fp, pbk, and sid as well. Some of these parameters are required for the REALITY handshake. Missing values commonly cause a handshake failure, an immediate disconnect after connection, or an incomplete-configuration error.

XTLS Vision: not just a regular TLS switch

XTLS Vision is commonly identified by flow=xtls-rprx-vision. It is not a single UI option that simply changes “TLS” to “XTLS”; the client, server, protocol, and transport must all match. When a node specifies Vision, preserve the complete flow value and do not remove it during subscription conversion or manual editing.

Vision is primarily part of the Xray ecosystem. Even if the address, port, and user ID are identical, switching the same node to V2Fly does not mean the connection will work. Without matching the handshake and flow-control behavior expected by the server, the client may show a timeout, connection reset, or TLS-related error.

REALITY: verify the parameters as a set

REALITY is a commonly used security and handshake solution in Xray, often paired with VLESS, TCP, and Vision. On the client side, verify the serverName, public key, shortId, fingerprint, and flow. The server’s private key is not included in the client subscription; the client receives the public parameters required for the handshake.

serverName must match a name allowed by the server configuration; one extra or missing character in the public key or shortId is enough to cause failure. The fingerprint describes the client handshake profile and must be supported by the core. If a REALITY node is unavailable, compare these fields first, then check the system clock, network egress, and server status.

Configuration compatibility: easy-to-miss differences in similar JSON

Both Xray and V2Fly commonly use JSON configurations. Inbounds receive local traffic, outbounds connect to the destination or a proxy server, and routing rules decide which outbound handles the traffic. Because the structures are similar, many users copy an entire configuration and replace the executable core. This is safe only when the fields clearly belong to capabilities shared by both cores.

Difference one: security layers and flow

Check the security type under streamSettings. Standard TLS configurations usually include values such as serverName and ALPN; REALITY configurations include dedicated settings. Then check the flow in the VLESS user or node data. If you keep an Xray-specific value but switch to V2Fly, the configuration may fail to start—or start without completing the connection.

Difference two: transport parameters and versions

WebSocket paths and Host values, gRPC service names, and TCP header settings can differ because of configuration formats, version changes, or subscription conversion. Even when both cores support a transport, the final JSON generated by the client may not be identical. During troubleshooting, inspect the actual configuration written by the client rather than only the original subscription text.

A large version gap between the server and client can also cause new fields to go unrecognized, legacy syntax to change, or defaults to shift. Before upgrading, record working nodes, the routing mode, and the core type. After upgrading, test one node before restoring complex split-routing rules. This separates protocol issues from routing issues.

Difference three: DNS and split routing

Routing rules usually select an outbound by domain, IP, port, network type, or inbound tag. Both cores support these concepts, but rule fields, matching behavior, and available extensions change by version. During migration, pay special attention to domainStrategy, rule order, outbound tags, and the DNS query path.

When rules are matched from top to bottom, a broad rule near the top may capture traffic before more specific rules can run. If a node connects but some sites use the wrong egress, temporarily switch to a simpler global test mode. Once the core and node are confirmed working, restore domain and IP split routing one rule at a time.

Difference four: tag references

The tag in a configuration is an internal reference name. Outbound tags referenced by routing rules must exist, and DNS or inbound rules must point to the correct objects. If you copy only the outbounds and omit a referenced tag, the core may report a missing target or send traffic through the default outbound. The tag name does not determine the protocol, but a broken reference can look like protocol incompatibility.

Performance comparison: one speed test is not enough

The name Xray or V2Fly does not determine speed by itself. Actual throughput and latency depend on the server route, round-trip distance, congestion, device performance, protocol combination, transport layer, encryption overhead, split-routing rules, and test target. Results from different nodes, times, or networks are not directly comparable.

With the same route and broadly similar settings, Xray options such as Vision may reduce overhead in specific combinations and optimize modern connection patterns. That does not mean every Xray configuration is faster than every V2Fly configuration. If a standard VMess or VLESS node is limited by server bandwidth or network path, switching cores may make little or no difference.

How to compare them properly

1. Use the same device, local network, and test window.
2. Use the same server route and ensure the port and transport conditions are comparable.
3. Disable complex routing rules first to eliminate DNS and split-routing variables.
4. Test each combination multiple times, recording connection setup time, latency, download throughput, and long-connection stability.
5. Review reconnects, timeouts, and handshake errors in the client log instead of recording only the highest speed.

Observe memory and CPU usage in a real workload. Many concurrent connections, complex domain rules, and frequent DNS queries all increase resource use. Desktop and Android devices handle background activity differently, so their figures should not be compared directly.

If the connection drops every few minutes, check network switching, system battery-saving limits, server idle timeouts, and the client’s background status first. Replacing the core may temporarily change the symptoms without addressing the real cause.

Subscription compatibility: successful import does not guarantee complete parameters

Subscriptions distribute node information in bulk, but formats differ in how well they express extension fields. A node name appearing in the client only means the entry was recognized; it does not prove that the REALITY public key, shortId, serverName, fingerprint, and flow were all written correctly to the final configuration.

After importing a subscription in v2rayN, open the node details and verify the protocol, transport, security type, and flow. Fields edited manually before an update may be overwritten during the next update. Parameters that must persist should be supplied correctly by the subscription source rather than re-entered after every update.

When v2rayNG handles nodes on the Xray path, confirm that the app version matches the node parameters. v2flyNG is better suited to configurations explicitly targeting V2Fly. Importing the same advanced VLESS link into both clients may generate a node in each, but that does not prove that their underlying capabilities are identical.

Subscription conversion may also rename fields, remove unrecognized parameters, or map a transport to legacy syntax. If the original shared information works but the converted subscription does not, compare the node details generated by both. Look for missing fields first; do not start by changing the port or disabling security settings.

Choosing Xray or V2Fly by use case

Case 1: the node explicitly uses REALITY or Vision

Choose Xray. Do not change REALITY to standard TLS or remove the Vision flow for superficial compatibility. The security layer and flow control are part of the server configuration, so the client must connect as required by the server. On desktop, confirm the active core in v2rayN; on Android, use v2rayNG and verify the imported fields.

Case 2: an existing V2Fly configuration is stable

If the current configuration uses standard VMess, VLESS, WebSocket, gRPC, TLS, DNS, and routing rules, and the server and client have remained stable, there is no need to migrate just to change the core name. If you continue using V2Fly, record the current version and configuration structure, then verify nodes, DNS, and routing in that order after an upgrade.

Case 3: one subscription mixes several node types

Classify nodes by capability first. Put standard VMess and regular VLESS nodes in one group, and REALITY and Vision nodes in another. Switch cores and test each group separately instead of blaming every failure on the subscription. If the client supports choosing a suitable core per node, regenerate the configuration after switching and inspect the logs.

Case 4: the configuration depends on complex split routing

Choose a core that fully supports the node protocol before migrating routing rules. Until the node layer connects, complex routing only adds variables. Start with one local proxy inbound and one node outbound to verify the basic connection, then add direct routing, domain rules, IP rules, and DNS policies.

Case 5: low latency and stable connections are the priority

Prioritize a combination that matches the server configuration, is actively supported by the client, and provides clear logs. When latency differences are small, stability is more useful than a peak from one speed test. Use the setup continuously for a while, observe disconnects, reconnects, DNS failures, and background persistence, then decide whether to migrate.

Checklist for switching from V2Fly to Xray

1. Record the current environment. Note the client version, core name, working nodes, listening ports, system proxy mode, and routing mode.
2. Back up the configuration. Save the subscription URL and custom routing rules so they can be restored after an upgrade or core switch.
3. Confirm the node protocols. Mark VMess, VLESS, transport, security layer, and flow for each node instead of classifying nodes by name alone.
4. Check local ports. Make sure the SOCKS and HTTP inbound ports are not occupied by another process, and ensure the old core is not still running in the background when switching.
5. Test one node first. Disable complex split routing and use a node with complete parameters to verify the basic connection.
6. Check the runtime log. Distinguish configuration parsing, DNS, handshake, authentication, timeout, and routing errors. Each points to a different troubleshooting path.
7. Restore routing rules. Add direct, proxy, and blocking rules from simple to complex, testing representative domains after each change.
8. Update the subscription and recheck. Confirm that the update did not overwrite manual parameters, especially fields required by REALITY and Vision.

When switching back from Xray to V2Fly, first remove dependencies on Xray-specific capabilities instead of simply replacing the core files. As long as a node still requires REALITY or Vision, V2Fly cannot provide an equivalent connection. To keep using the original node, retain Xray; to use V2Fly, prepare a configuration combination explicitly supported by the server.

Frequently asked questions

The final selection rule

Xray’s clearest advantages are XTLS, REALITY, and continued expansion around VLESS. V2Fly focuses on continuing the original configuration model and established feature path. Both have valid use cases; the deciding factors are the server requirements, node fields, client support, and the cost of changing an existing configuration—not brand preference.

Make the choice in three steps: first check whether the node includes REALITY or Vision; next confirm which core the client actually runs; then test the basic connection with complex split routing disabled. Once it works, restore subscription updates, DNS, and routing rules. This order keeps core compatibility, missing subscription fields, and routing errors separate.