Xray vs. V2Fly Core: REALITY, XTLS Vision, and Configuration Compatibility

Understand clients, cores, and node protocols

v2rayN is a desktop client for managing subscriptions, editing nodes, configuring the system proxy, and running core processes. Xray and V2Fly are the cores that handle proxy traffic. Having a particular client installed does not mean it is using a particular core for the current connection. Check the core name, version, and startup result in the logs.

The V2Fly community maintains the V2Ray project. Xray began as a fork of V2Ray and later developed along its own path, with differences in transport, security mechanisms, and configuration fields. The two share a common origin, but that does not mean new features appear in both at the same time—or that complete JSON configurations are interchangeable.

• Client layer: v2rayN, v2rayNG, and v2flyNG provide the interface, import subscriptions, and launch a core.
• Core layer: Xray or V2Fly parses the configuration, establishes inbound and outbound connections, and applies routing rules.
• Protocol layer: VMess, VLESS, and Trojan describe how proxy traffic is carried; they are not client names.
• Transport and security layer: TCP, WebSocket, TLS, and REALITY settings together determine connection requirements. Don’t rely on the protocol label in the node list alone.

On Android, v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. With v2rayN on desktop, check which cores your version offers and which one the node actually uses. Being able to save a node only means it passed the client’s checks; it doesn’t confirm that the core established a connection.

Compare REALITY, XTLS Vision, and common protocols

REALITY and XTLS Vision serve different purposes. REALITY is a transport security mechanism provided by Xray. Vision is a flow-control mode represented by xtls-rprx-vision, commonly used in VLESS configurations. They’re often used together, but they aren’t the same setting; Vision can also be used with compatible TLS configurations.

REALITY clients typically need server-provided public-key parameters, serverName, shortId, and a client fingerprint. Never put the server’s private key in the client. Field names can differ between share links, client forms, and core JSON. Match settings to the documentation for your version rather than copying field names blindly.

Choose Xray or V2Fly based on your node requirements

If your subscription includes REALITY or Vision nodes, choose an Xray client that supports them. If your existing setup runs reliably on V2Fly and uses protocols and transports supported by both cores, you can keep it and test before migrating. Core choice isn’t a speed ranking; real-world performance also depends on network congestion, server load, and your local connection.

A newer core doesn’t mean every old node can be imported unchanged. The client’s subscription parser also transforms data: different clients may parse the same share link into different fields, and some extra parameters may be dropped. After switching clients, review each field on the node edit screen. That’s often more useful for finding problems than repeatedly refreshing the subscription.

Check these five groups of settings when migrating

Start by importing a single node and testing it before importing the full subscription. A complete configuration includes local listeners, DNS, routing, and outbound tags as well as remote connections. Migrating only the node settings makes it easier to isolate variables. Replacing the entire JSON file can also change how apps connect and how traffic is routed.

1. Document your current setup. Note the core name and version in the client logs, and save a copy of the original configuration. In v2rayN, open “Settings” → “Parameter Settings” to review local listener options. Tab names may vary by version, so follow the labels in your current interface.
2. Check the remote server details. Verify the server address, port, and UUID or password. The port is set by the server; don’t change it to 443 just because another node uses that port.
3. Check the transport settings. The WebSocket path and Host, TLS serverName, and REALITY parameters must match the server. Host and serverName serve different purposes. Even if their values are the same, they must remain separate fields.
4. Check security and flow control. Verify whether the node uses TLS or REALITY and whether it requires xtls-rprx-vision. Seeing the VLESS label after importing doesn’t mean these additional settings were preserved.
5. Rebuild local policies. Review DNS, routing order, outbound tags, and the system proxy. A reference to a nonexistent outboundTag can prevent the configuration from starting or cause traffic to be routed incorrectly.

V2Fly has multiple configuration formats and its own development path; Xray also changes fields and validation rules. So “both are JSON” doesn’t mean they have the same structure. If you see errors for unknown fields, invalid transports, or unsupported flow settings, first confirm which core is reading the configuration and which format it expects. Then address the specific field named in the error—don’t delete every setting flagged by an error.

These three numbers represent different roles; they aren’t recommended values to copy. The remote port connects to the server, while a local port lets apps connect to the proxy. For example, if your browser points to a local HTTP port, the core must actually be listening there. If you use a mixed port, configure it according to the listener type in use; don’t rely on port notes from an older client.

Plan how to use subscriptions on desktop and Android

A single subscription can include multiple protocols. Successfully importing it on desktop doesn’t prove that Android supports every node it contains. Providers may also return different content depending on the client, so even nodes with the same name on both platforms should be checked for matching protocol, transport, and security settings.

On a Mac, the system proxy mainly affects apps that honor system proxy settings. Android clients typically route traffic through the system VPN interface. These are different ways of handling traffic, so being able to browse on Android doesn’t prove that the Mac system proxy is configured correctly. When troubleshooting, first confirm the core starts, then check whether app traffic reaches it.

Fix import-success, connection-failure issues

Check in this order: can the configuration start, does the remote handshake succeed, and is the app’s traffic going through the proxy? Change one group of settings at a time and keep the first specific error message. A node-list test only covers its particular test target; it doesn’t replace checking the browser, DNS, and routing end to end.