Xray vs. V2Fly Core: VLESS, XTLS Vision, and REALITY Support

Core vs. client: know what each does

Xray-core and the V2Ray-core maintained by V2Fly are separate core projects. They share technical roots but have evolved independently. The core handles inbound connections, matches routing rules, and establishes proxy outbound connections. The client manages subscriptions and the UI, and generates the configuration. A node appearing in the client does not mean the selected core can use all of its fields.

v2rayN is a desktop client; its actual connection capabilities depend on the selected core and its version. On Android, this guide covers v2rayNG with the Xray core and v2flyNG with the V2Fly core. The app version and core version are separate details. Record both when troubleshooting, and don't use the client version as a proxy for protocol support.

• Parsing: Whether the client recognizes subscription fields determines whether all parameters make it into the configuration.
• Loading: Whether the core accepts the field names, values, and their combination determines whether it starts successfully.
• Connecting: The handshake succeeds only if the server settings, certificates, system time, and network path all match.

Each stage can fail independently. For example, the client may import a node successfully but omit the REALITY public key from the generated configuration. Or the core may start, while the client's shortId doesn't match the server's. Verify that a node can connect separately from confirming that it appears in the list.

Protocol guide: VLESS is not REALITY

VLESS is a proxy protocol, XTLS Vision is a specific flow-control mode, and REALITY is a security layer used by Xray. They operate at different layers. A subscription URL starting with vless:// alone doesn't tell you whether V2Fly can use the node. Check the transport, security layer, and flow as well.

“Supported” does not mean every configuration is interchangeable. A protocol being available in both cores only means they share some capabilities. Check the specific versions for newer transports, configuration formats, and extension parameters. In particular, don't copy new Xray transport fields directly into a V2Fly configuration.

XTLS, Vision, and REALITY: know what each setting means

Don't assume XTLS in older guides maps directly to the Vision settings commonly used today. Don't copy historical flow names such as xtls-rprx-direct into a new configuration. A common Vision setup uses flow: xtls-rprx-vision with either TLS or REALITY as the security layer. Vision doesn't require REALITY.

REALITY doesn't disable TLS certificate checks. The client must verify settings such as the server's public key, allowed serverName, shortId, and fingerprint. Keep the server private key on the server; never send it to clients as a subscription field. Standard TLS typically relies on certificate chain and hostname validation. If certificate validation fails, check the hostname and system time first.

Don't add a Vision flow to a WebSocket node at random, or change a TLS node's security setting to REALITY and expect it to work. These changes alter the connection protocol, and the server must be configured to match. If subscription details are incomplete, get the missing parameters instead of copying a public key or shortId from another node.

Configuration migration: the same port doesn't mean the same configuration

Before switching cores, back up the current configuration and test one node first. A subscription URL, a node saved by the client, and core JSON are three different data formats. Even when both use JSON, their configuration formats may differ. Don't assume V2Fly configuration formats are compatible with the JSON commonly used by Xray just because the file extensions match.

These values are configuration examples for troubleshooting, not defaults for every version. Server port 443 and local port 10808 serve different sides of the connection. If the local port is already in use, changing the server port usually won't help. If the server isn't serving the expected connection on port 443, a working local inbound still won't establish a proxy connection.

1. Document the current setup: Note the client version, core version from the startup log, node transport, and security layer. Keep a restorable copy of the configuration.
2. Test a shared protocol first: Establish a baseline with a fully configured combination supported by both, such as VMess + WebSocket + TLS. Don't migrate all extension-based nodes at once.
3. Review the generated configuration: Check protocol, transport settings, the TLS hostname, and outbound tags. Remove credentials before sharing logs.
4. Check routing rule dependencies: Make sure the running core can find geosite.dat and geoip.dat, and that the categories referenced by your rules exist.
5. Restore features one at a time: Re-enable DNS, split routing, and TUN in sequence to avoid compounding errors across multiple settings.

Routing and DNS aren't optional extras. The same hostname can use different outbound connections depending on where DNS resolution happens, IPv6 availability, and rule order. Keep these settings constant when comparing cores; otherwise, a speed difference may simply mean traffic switched from proxy to direct, not that one protocol is more efficient. See DNS settings in the advanced configuration guide for more on routing rules.

Choosing a client: v2rayNG or v2flyNG?

When choosing an Android client, start with what your subscriptions require, then consider your workflow. For nodes using REALITY or Vision, choose a v2rayNG version with the corresponding Xray capabilities. If you already have V2Fly configurations, use protocols supported by both, and want to stay on the V2Fly core, consider v2flyNG. Node count and a similar-looking interface are no substitute for checking protocol support.

• v2rayNG: Best for nodes that need Xray extensions. After importing, make sure an older parser hasn't dropped settings such as flow, fingerprint, or public key.
• v2flyNG: Suited to nodes and configurations built for V2Fly. A successful import doesn't prove that REALITY is supported.
• v2rayN: On desktop, check which core the node actually uses. After updating the client, review the startup log to confirm the core itself has been updated and is running.

If a node connects after you fill in missing fields manually but fails when imported from the same subscription, the issue may be in the client's parser, not the core. Conversely, if the UI saves every field but the core reports that a flow isn't supported, the subscription URL may not be the problem. Distinguishing between the two helps avoid repeated reinstalls that don't address the actual cause.

Troubleshooting: check fields, then the handshake, then the network

“Failed to start” and “can't connect after startup” are different problems. For startup failures, check the configuration format, supported fields, and port conflicts first. For connection failures, check name resolution, handshake parameters, and routing. The exact error message matters. The examples below describe common causes; they aren't guaranteed messages from every version.

Keep testing conditions consistent, too. A successful TCP handshake only means the destination port was reachable at that moment; it doesn't confirm VLESS authentication or a completed TLS or REALITY handshake. To compare Xray and V2Fly, use the same protocol combination supported by both, the same exit, and the same test address. Record request latency and download throughput separately instead of combining them into a single “speed” score.

The choice comes down to a simple rule: use Xray for REALITY or Vision; for protocols supported by both, choose based on configuration compatibility and how you maintain your setup. The core name alone doesn't determine stability. Complete parameters, compatible versions, and correctly configured DNS and routing are what make connections reproducible.