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

Project Background and Client Roles

Xray-core and the v2ray-core maintained by V2Fly share a common project history, but have since followed different development paths. Project V provides context for this proxy ecosystem. V2Fly maintains the community continuation of v2ray-core, while Xray has developed independently. Both are core programs that handle proxy connections, routing, and DNS—not client interfaces.

Clients manage subscriptions, let you edit nodes, start the core, and display logs. The core reads the final configuration and handles connections. So being able to import a node in the interface does not mean the core can run it. A subscription parser may recognize certain fields without passing them to the active core for processing.

• v2rayNG: An Android client that uses the Xray core. A good fit for REALITY, XTLS Vision, or existing Xray configurations.
• v2flyNG: An Android client that uses the V2Fly core. A good fit for standard V2Fly configurations when Xray-specific features aren't needed.
• v2rayN: A desktop client. Its capabilities depend on the selected core and version, so don't infer protocol support from the client name alone.

When troubleshooting, note both the client version and the core version currently running. Updating the interface does not necessarily update the core files, and replacing the core does not mean the client's editor can generate every new field.

Protocol Support: XTLS and REALITY

REALITY and XTLS Vision are not synonyms for VMess or VLESS. VLESS is a proxy protocol; REALITY belongs to the transport security configuration layer; Vision is a flow control mode used with specific connection setups. If a subscription lists VLESS, REALITY, and Vision together, check each configuration layer—not just whether VLESS is supported.

Here, XTLS primarily refers to the commonly used Vision setup. Don't treat legacy flow control values such as xtls-rprx-direct from older guides as migrated simply by replacing them with xtls-rprx-vision. The server must also use a compatible combination; changing flow control on the client alone can cause the handshake to fail.

How REALITY and Vision Work in a Connection

During the handshake, REALITY lets the client verify key material held by the server and uses target-related settings to shape the TLS handshake. It does not route all proxy traffic through the target website or remove authentication. The server still needs correctly configured keys, a target, and allowed names, and the client must use matching settings.

Vision primarily handles how TLS traffic is identified and forwarded through the proxy tunnel, reducing redundant wrapping and processing overhead when conditions allow. It does not mean every connection skips encryption, nor can it eliminate physical link congestion, cross-region latency, or packet loss on the network. Any improvement in page load speed depends on the actual workload.

Configuration Compatibility and Field Migration

The traditional JSON configurations used by both cores share many structures, such as inbounds, outbounds, and routing. But fields that look alike may have different accepted values, defaults, or subfields. V2Fly also has multiple configuration formats, so identify the format your file uses before migrating it.

This example uses a common rule in traditional JSON routing to send private addresses through the direct outbound. It shows only the routing section, not a complete, runnable configuration. The actual file must include an outbound tagged direct and the data files required by the rule.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

• Migrate outbounds first: Check the protocol, user authentication, transport, security layer, and flow control one by one. An outbound using REALITY cannot be handed to V2Fly unchanged.
• Then migrate routing: Keep the rule order and confirm that every outboundTag points to an outbound with the same name. A tag is only a reference; it doesn't create direct or proxy capabilities.
• Finish with DNS: Check resolution policies, domain rules, and data file paths. Don't assume DNS option names in the client interface are core JSON fields.
• Distinguish subscriptions from full configurations: A node sharing link usually carries only the information needed for a single outbound. It does not include local inbound, DNS, routing, or logging settings.

Also distinguish a configuration loading successfully from its settings actually taking effect. Unknown fields may trigger an error or be ignored. A running process alone doesn't prove the migration worked—check the logs, active outbound, and connection results in the target app. For details on related fields, refer to the protocol configuration guide.

Port Checks and Troubleshooting Order

When a connection fails, check the local connection separately from the remote handshake. The ports below illustrate what to check; they are not defaults for every client. Use the current inbound configuration and node port, and don't change a working listener just to match a tutorial.

1. Check that the app is routed through the client. If the local SOCKS inbound listens on 127.0.0.1:10808, the app must use the matching address, port, and proxy type. The system proxy setting does not guarantee that every app will follow it.
2. Check that the core loads correctly. If it exits immediately, reports an unrecognized field, or doesn't support the flow control mode, check the core selection and configuration format first—not DNS.
3. Check remote reachability. If the local inbound works but the remote connection times out, check the node address, actual server port, network path, and server status. A reachable port does not guarantee successful authentication.
4. Check the handshake settings. For REALITY, verify the public key details, shortId, serverName, and time settings. For standard TLS, check the SNI, certificate validity period, and trust chain. Don't hide errors by disabling certificate verification.
5. Check routing and DNS resolution. If only some domains fail, inspect their DNS results and which outbound they match. Change one set of settings at a time during testing, and keep the original configuration so you can restore it.

Choosing a Client and Migrating Subscriptions

On Android, use v2rayNG if your nodes use REALITY or Vision. For standard VMess or VLESS nodes whose server documentation specifies V2Fly configuration, v2flyNG may be a better fit. On desktop, before choosing a core in v2rayN, check which features the node requires. The client name alone cannot tell you whether it's compatible.

When migrating a subscription, create a new group and keep the old one as a fallback. Import one node and verify its settings before updating the rest, then migrate routing. Subscription updates may overwrite manually edited node fields. If flow control or a security layer is missing after import, check the subscription format and the client's parsing support instead of repeatedly entering the settings by hand.