If a node uses REALITY or xtls-rprx-vision, check Xray support first. For common settings such as VMess, WebSocket, and TLS, either core may work. This guide helps you choose a client, switch cores, or migrate a configuration by checking protocols, transports, security layers, and logs—rather than relying on the client’s name to determine compatibility.
First, distinguish V2Ray, V2Fly, Xray, and the client
The core handles proxy connections, protocols, DNS, and routing. The client manages node lists, subscription imports, settings, and processes. Seeing a node in v2rayN does not mean the active core can parse every field in its configuration. Before choosing a core, check the node’s requirements and which executable the client actually runs.
Project V is the broader ecosystem behind these projects, and V2Ray is its proxy software. The V2Fly community continues V2Ray’s development. Xray split from V2Ray-related code in 2020 and has developed as an independent core project. The two share many configuration concepts, but they are not two interfaces for the same program, and their shared origins do not guarantee full configuration compatibility.
- V2Fly: The community maintaining V2Ray and its core project. The V2Ray name still appears frequently in the software and documentation.
- Xray: An independently developed proxy core. REALITY and XTLS Vision are key features to consider when choosing a core.
- v2rayN: A desktop client. Available cores depend on the installation package, client version, and configuration type.
- v2rayNG / v2flyNG: Android clients. v2rayNG uses the Xray core, while v2flyNG uses V2Fly; they are separate apps, not a switch within one app.
Feature differences: Check REALITY and Vision first, then transport combinations
The clearest distinction is whether a node requires Xray-specific features. REALITY is a security layer, not an alternative name for VMess or VLESS. xtls-rprx-vision is a flow-control setting, not a standalone transport protocol. A connection works only when the protocol, transport, security layer, and flow-control combination are all supported.
| Check | Xray | V2Fly | What to verify |
|---|---|---|---|
| VMess | Supported | Supported | Also verify the transport, TLS, and authentication settings; the protocol name alone isn’t enough. |
| VLESS | Supported | Supported, but feature combinations differ | Basic VLESS support does not imply support for REALITY or Vision. |
| Trojan | Supported | Supported | Check the password, TLS server name, and transport settings used by the server. |
| REALITY | Supported; match the version and fields | Xray REALITY configurations cannot be used as-is | If a node requires REALITY, choose Xray from the two core projects compared here. |
| XTLS Vision | Supports the corresponding VLESS configurations | Does not support Xray’s Vision flow control | If you see xtls-rprx-vision, check the Xray and transport requirements. |
| WebSocket + TLS | Supported | Supported | You still need to verify the path, Host, server name, and server settings. |
| DNS and routing | Relevant modules are available | Relevant modules are available | Check each project’s documentation for fields, default behavior, and extended features. |
Older guides may use “XTLS” to refer to an earlier configuration; it is not interchangeable with today’s Vision. Don’t change security from reality to tls just to make a configuration parse: that changes the handshake, but does not change the server. Use a compatible core, or ask the server administrator for another node configuration that is actually available.
Choosing a client: Match the core to the node’s requirements
If you already have a working subscription, open a node’s settings and check its key fields. “VLESS” alone is not enough—verify the transport, security layer, and flow control too. The recommendations below apply to nodes that require REALITY or Vision; they don’t mean every standard node needs to be migrated.
Xray core
RecommendedUse for nodes that explicitly require REALITY or xtls-rprx-vision. On desktop, check which core v2rayN actually runs. On Android, v2rayNG is an option; verify that its bundled core meets the node’s requirements.
Best for: Existing REALITY or Vision nodes that need a compatible feature combination.
V2Fly core
Use in environments already configured and tested with V2Fly. Common VMess, VLESS, and Trojan nodes still require checks of their transport and security settings. The corresponding Android client is v2flyNG.
Best for: Maintaining an existing V2Fly configuration when the server does not require Xray-specific features.
In some versions of v2rayN, core options are under Settings → Parameter Settings; names and support vary by version. If the interface does not offer a core, don’t assume renaming an executable will switch it. Check the client’s supported cores, package contents, and startup logs. If needed, install a client that matches your existing configuration.
Choose for both platforms: Test nodes from the same subscription separately
Desktop: v2rayN
- Confirm the node’s protocol, transport, and security layer.
- Check the core settings for the configuration type.
- After startup, check the core name and version in the logs.
Android: v2rayNG / v2flyNG
- For REALITY or Vision nodes, use a compatible version of v2rayNG.
- For an existing V2Fly setup, use v2flyNG to check the configuration.
- On the first connection, confirm the system VPN permission and which apps are routed through the proxy.
The same subscription URL may work in different clients, but parsing, supported fields, and update times can vary. Check the node list and connection results in each client separately.
Before switching cores: Keep local and remote ports straight
If websites stop loading after a switch, the remote protocol isn’t necessarily incompatible. An app may still be using the old local port, the listen address may have changed, or the port may be occupied. The example below shows what to check; it is not a client default or a measured result.
- Note the local entry point. If an app uses SOCKS, connect it to the example
127.0.0.1:10808, not the server’s443port. For HTTP proxying, use an HTTP or mixed entry point that is actually enabled. - Record the node settings. Keep the server address, port, user ID or password, transport, server name, and flow control. For REALITY, also check the public key, short ID, and other parameters provided by the server.
- Record routing and DNS settings. Export or back up the client configuration before switching. Keep subscription data, custom routes, and custom JSON separate; backing up only the node list is not enough.
- Switch one setting at a time. First pause TUN and other traffic-capture modes. Test the connection through a known local proxy entry point, then restore your original routing and capture settings.
A server listening on 443 does not mean the node uses ordinary TLS, nor can you send arbitrary browser requests directly to that port. The port is only part of the connection target; the protocol and security layer determine the handshake.
Can you reuse the JSON? Similar structures don’t guarantee compatible fields
The two core projects share concepts such as inbounds, outbounds, routing, and dns, but their extended fields, configuration formats, and default behavior can diverge as they evolve. A client also converts imported share links into a runtime configuration, so successfully importing a link and starting the generated JSON are separate steps.
- Check the outbound: Verify the combination of
protocol, authentication settings, andstreamSettings; don’t copy just one field. - Check routing: Each rule’s
outboundTagmust match an existing outboundtag. Preserve the original rule order and intent. - Check DNS: Distinguish system DNS, DNS settings generated by the client, and how the core resolves destination domains. They are not a single switch.
- Check resources: If routing uses domain or IP data files, verify that the new core can read their format and that the client passes the correct resource paths.
For most users, the safer migration path is to back up the original configuration, re-import the nodes in the target client, and check their settings—not to overwrite the entire generated configuration. If you use custom JSON, verify each field against the target core’s documentation. Check the current executable’s help output for the correct configuration test command instead of copying command-line options from the other core project.
Troubleshooting: Check startup, then the handshake, then routing
Read logs in connection-stage order. If the core hasn’t started, changing the remote server name won’t help. If the remote handshake succeeded, repeatedly switching cores may not fix a routing or DNS issue. Change one related group of fields at a time, and note the timestamps in the logs before and after each change.
The node imports, but startup reports an unknown field. What now?
Check the core name and version in the startup log, then identify the field named in the error. If the node requires REALITY or Vision, use an Xray core that supports the configuration. If you’re already using Xray, check that its version and the client-generated configuration match. Don’t simply delete the field reported in the error.
Still getting timeouts after switching to Xray? What should you check first?
First verify that the server address and port are reachable. Then check the TLS server name or REALITY settings, user ID, and flow control. A timeout alone does not prove the core is wrong; the remote server may not be listening, the network path may be down, or a local firewall may be blocking the connection.
The log says address already in use. Which port should you change?
Check the local listen address named in the error. If another process is using the example port 10808, stop the duplicate core process or change the local listen port—and update the settings of any apps using that proxy. Don’t change the remote port 443 at random.
The core starts and the test passes, but some websites still won’t load. What should you check?
First confirm that the app is actually using the proxy. Then check which routing rule matches the destination domain and which outbound it selects. With the same node, compare a temporary proxy rule with your original rules, then check DNS. On Android, also make sure per-app proxy settings haven’t excluded the target app.
Choosing a core: Keep a configuration you can verify
If you need REALITY or XTLS Vision, choose a compatible Xray core from the options compared here. If your existing V2Fly configuration works reliably and the node does not require those features, there’s no need to migrate just for a different name. For VMess, VLESS, and Trojan, still verify the transport, security layer, and authentication settings.
- Start with the node: Record the transport, security layer, flow control, and server requirements—not just the protocol name.
- Check the running process: Confirm the active core in the startup log; don’t rely on the client icon or node name.
- Then verify: Keep the network, node, and destination the same while testing the connection, DNS, and routing. Restore your usual settings afterward.
For configuration field details, see the V2Ray JSON Configuration Manual. If you’re unsure how inbounds, outbounds, and routing differ, start with the Glossary. Choose a version based on the actual installation package and node requirements; menu locations shown in older guides may not match every client version.