Xray-core vs. V2Fly-core: XTLS, REALITY Support and Config Compatibility

Where the projects split: clients, cores, and node configs

V2Fly is a community project that continues development around V2Ray; its core program is commonly called V2Fly-core. Xray-core branched from the V2Ray codebase in 2020 and has since followed its own feature development and release cycle. The two share common origins, so many config structures look alike—but that does not mean their features, defaults, or field names are always compatible.

v2rayN is a desktop client that manages subscriptions, edits nodes, generates configs, and launches the selected core. The core process itself establishes the proxy connection. On Android, v2rayNG uses Xray, while v2flyNG uses V2Fly. Similar names do not mean the clients support exactly the same node features.

A share link in a subscription is not a complete config that any core can use as-is. The client converts node parameters into an outbound object for the selected core, then adds local inbounds, DNS, and routing. Successful import only means the client recognizes the link format. To confirm the connection can start and complete its handshake, check both the generated config and the server requirements.

Feature comparison: VLESS, XTLS Vision, and REALITY operate at different layers

VLESS is a proxy protocol, Vision is a flow-control mode used with VLESS in Xray, and REALITY is a connection security layer. A typical “VLESS + TCP + REALITY + Vision” setup combines four types of settings. REALITY is not another name for VLESS, and a VLESS node does not necessarily require Xray.

Vision is typically configured as flow: "xtls-rprx-vision" in the user object; do not set security to “Vision.” REALITY is typically configured with streamSettings.security: "reality" and a corresponding realitySettings object. Vision is commonly paired with TLS or REALITY. Do not add Vision flow to a WebSocket node indiscriminately.

Config compatibility: check flow control, security, and transport settings one by one

The two cards below are parameter-check examples, not complete connection configs. The first highlights key settings for nodes using Xray-specific features; the second shows common ground between the two cores. Get the address, credentials, and security parameters from the actual server config or subscription—never infer them from a node name.

• User object: Check id, flow, and protocol-specific fields. VLESS encryption: "none" does not mean the entire connection lacks a security layer; TLS or REALITY is configured separately.
• REALITY parameters: Check serverName, fingerprint, shortId, and the key parameters supplied by the server. Field names and aliases accepted can vary between Xray versions. Check legacy forms such as publicKey against the version actually running; do not assume V2Fly accepts them.
• Transport object: Check network and its corresponding settings object. Newer Xray docs or generated configs may use names such as raw; do not assume V2Fly accepts the same values. Preserve the WebSocket path and request headers too.
• TLS checks: For standard TLS nodes, verify the certificate domain and SNI. Disabling certificate verification is not a general migration fix: it cannot resolve a protocol mismatch and changes the security boundary.

Older guides may refer to a standalone “XTLS” setup that is not the same as the current Vision mode. During migration, check the actual flow value and security layer instead of copying legacy config verbatim into a newer version. After updating the client, verify the version of the core that actually starts—not just the client version.

Switching cores in v2rayN: back up first, then run a minimal test

Menu names and core-selection settings can change between v2rayN versions. Look for core-related options under Settings → Parameter settings. If your version lets you choose a core by node type, use the “Core type” field or its equivalent in that version. Do not switch every protocol to one core and then change DNS, routing, and system proxy settings all at once.

1. Record your baseline. Back up the current client config and note the client version, core version shown in the logs, selected node, and local listen address and port. Keep sensitive subscription URLs stored locally.
2. Start with a node both cores support. Use an existing VMess + WebSocket + TLS node to test the switch. If you only have a REALITY node, you cannot perform an equivalent test with V2Fly.
3. Change one thing at a time. Change the core selected for the relevant protocol, then stop and restart the connection. Confirm the new process has started and check the logs for the core actually in use; an old process may still be holding the port.
4. Check the local proxy endpoint. Keep the app's proxy type and port unchanged, then make a real web request. A latency test returning a number does not prove that the browser is using the correct system proxy endpoint.
5. Restore features in stages. Once the basic connection works, restore custom routing, DNS, and other advanced settings one at a time, testing after each change to pinpoint compatibility issues.

These numbers distinguish the local entry point from the remote endpoint; they are not fixed client defaults. Use the ports configured in your client, and check whether the local listener is HTTP, SOCKS, or mixed. A remote server on port 443 does not mean the browser should point its system proxy to local port 443.

Startup and connection troubleshooting: a valid config does not guarantee a successful handshake

When maintaining a full config manually, start with the core's built-in config check. The commands below show common command-line usage for Xray and V2Fly v5; client.json refers to a complete config file saved locally. For other versions, check the arguments with the help command first. Before checking a temporary file generated by the client, make a backup copy for offline validation.

xray version
xray run -test -config client.json

v2ray version
v2ray test -c client.json

A config check can catch syntax errors, some invalid fields, and unsupported combinations, but it cannot confirm that the remote server is reachable or that credentials are correct. Once the core starts, make a real connection and check whether the outbound handshake and request complete. The table groups issues by failure stage so you can narrow down the cause instead of blaming every problem on a “dead node.”

Routing rules using geosite: and geoip: also depend on the data file contents and load path. Both cores recognizing a rule syntax does not mean the corresponding category exists in your local data. During migration, check domainStrategy, DNS servers, outbound tags, and the final fallback rule together; otherwise, the core may start while routing traffic differently.

FAQ: choosing a core and evaluating performance