Choose a core based on your node settings first, then your client. VLESS is not the same as REALITY, and neither protocol name is exclusive to Xray. Configurations using REALITY or xtls-rprx-vision require a core that supports them, typically Xray. If your VMess setup works reliably, there’s no need to switch just for a different name. This guide covers project history, protocol combinations, Android clients, and migration checks.
The fork: Xray and V2Fly are separate cores, not two toggles for the same one
Project V is the ecosystem behind a range of related tools and protocols, with V2Ray being a commonly used core name. The V2Fly community continues to maintain v2ray-core, while Xray-core forked from the V2Ray codebase in 2020 and has developed independently since. The two share some history and configuration concepts, but their features, release cycles, and configuration fields have since diverged.
So “V2Ray client” doesn’t tell you which core is running. The client handles subscriptions, node selection, and the user interface; the core establishes connections, processes inbound and outbound traffic, and applies routing. A node appearing in the client doesn’t mean the active core can accept the configuration it generates.
- Project: V2Fly and Xray are maintained on separate branches. Their version numbers aren’t directly comparable.
- Core: Check the core name and version in the startup log, not the window title or installation folder.
- Client: v2rayN is a desktop client; this guide compares the Android clients v2rayNG and v2flyNG.
- Node: Compatibility depends on the transport, security layer, and additional fields—not just the protocol name.
Protocol support: distinguish VLESS, REALITY, and Vision
Check at least four layers for node compatibility: proxy protocol, transport, transport security, and protocol-specific behavior. VMess and VLESS are proxy protocols; WebSocket is a transport; TLS and REALITY are transport-security configurations. xtls-rprx-vision is a flow value used in specific combinations, not a standalone node protocol.
| Configuration item | Xray | V2Fly | What to check |
|---|---|---|---|
| VMess + WebSocket + TLS | Commonly supported combinations | Commonly supported combinations | Address, port, path, Host, and TLS server name |
| VLESS | Supported when the full configuration is compatible | VLESS is implemented, but that doesn’t imply support for Xray-specific extensions | Transport, security layer, flow, and version requirements |
| REALITY | Use with supported versions and combinations | Don’t assume compatibility with Xray REALITY configurations | Server name, public-key parameters, and shortId |
| xtls-rprx-vision | Use with the corresponding Xray combination and version | That flow can’t be copied over directly | Server-side flow and client transport combination |
For example, a VLESS node with both security=reality and flow=xtls-rprx-vision requires an Xray core that supports this combination. Conversely, a vless:// prefix alone doesn’t mean a node requires REALITY—or that every VLESS client can use it.
- Don’t replace REALITY with standard TLS as a compatibility fix. Unless the server configuration changes too, they aren’t interchangeable.
- Removing the flow doesn’t guarantee compatibility. Even if the configuration starts, the handshake may still fail.
- VMess also requires correct system time, a valid user ID, and matching transport settings. Protocol support alone doesn’t guarantee a valid configuration.
Choosing a client: match Android apps to node requirements; check the core on desktop
On Android, the key difference between v2rayNG and v2flyNG is the core each uses. Choose v2rayNG for nodes that require Xray features. If your setup already uses V2Fly and doesn’t rely on Xray-specific fields, you can keep using v2flyNG. These recommendations are about configuration compatibility, not a universal performance ranking.
v2rayNG · Xray core
RecommendedIf an Android node uses Xray features such as REALITY or Vision, choose a v2rayNG version that can import the required fields. After importing, check the node details and startup log.
Best for: Android setups using Xray configurations or subscriptions with REALITY nodes.
v2flyNG · V2Fly core
A good fit for V2Fly configurations that have already been tested. For protocols both cores support, such as VMess, check the actual transport fields; there’s no need to switch clients just because the projects have diverged.
Best for: Android users keeping an existing V2Fly setup, routes, and workflow.
On desktop, first check which cores are available in your v2rayN installer, configuration type, and client version. Don’t assume every version has the same core-switching option in the same place. After applying your settings, restart the selected configuration and check the log to confirm which core actually loaded. A core file in the download folder doesn’t mean the active connection is using it.
Choose based on your existing configuration
Nodes require Xray features
- Desktop: Use an Xray configuration supported by v2rayN.
- Android: Import a compatible subscription from the same provider into v2rayNG.
- Check the REALITY parameters and flow; keep the provider’s original values.
Existing V2Fly configuration works
- Android: Keep verified nodes in v2flyNG.
- Desktop: Check configuration support in your current version of v2rayN.
- Before migrating, back up subscriptions, routing, and DNS settings separately.
Using the same subscription only means the configuration comes from the same source. Check how each client parses fields and handles routing and DNS.
Before switching: check local ports, subscription conversion, and routing
If websites stop loading after a core change, protocol incompatibility isn’t the only possible cause. An old client may still be using a local listening port, or your browser may still be pointed at the old port. The two ports below are examples of a SOCKS and HTTP setup, not defaults for every client or version. Check your settings and startup log for the actual values.
- Save your original configuration. Note the subscription source, selected node, DNS, routing, and local ports. Subscription links may contain access credentials, so don’t share backups publicly.
- Stop the old connection. Disconnect the other client’s proxy. On Android, stop the existing VPN connection before starting the new client to avoid mistaking a connection handoff issue for a protocol problem.
- Re-import the subscription. Make sure the provider’s output format is compatible with the target client. Don’t assume one core’s full JSON configuration will work as a universal format for another.
- Check the active listening port. If the app points to
127.0.0.1:10809but the log shows only a different HTTP port, update the app’s proxy settings instead of repeatedly switching nodes. - Test routing separately. First confirm the connection works. Then check that traffic meant to bypass the proxy and traffic meant to use it take the expected routes. Restore custom rules last.
A successful subscription update only means the content was fetched and parsed by the client; it doesn’t guarantee every field was preserved. If the node details are missing a server name, WebSocket path, or REALITY parameter after migration, ask the provider for a compatible format instead of guessing the values. Custom DNS, domain-matching policies, and rule sets aren’t automatically equivalent just because the node lists match.
Reading the logs: diagnose startup failures separately from connection failures
A core starting successfully only means its current version accepted the configuration during loading. A connection can still fail during DNS resolution, TCP connection, or the TLS or REALITY handshake. Identify the failing stage before blaming a core change for slower speeds.
| Log clue | First check | Next step |
|---|---|---|
unknown field or a configuration parsing error |
Field, format, or core version mismatch | Check the import format, active core, and field named in the error. Don’t remove security parameters as a first step. |
address already in use |
Local listening port is already in use | Stop duplicate clients, or change the listening port and update the app’s proxy settings to match. |
timeout |
Use the surrounding log entries to identify where the timeout occurs | Check the server address, port, and network, then inspect the handshake parameters |
| Handshake-related error | Security settings don’t match the server configuration | Check the server name, system time, and authentication parameters; confirm the configuration with the provider |
Choosing a core: don’t infer speed or compatibility from its name
My subscription only has VMess. Do I need to switch to Xray?
Not just because of the name. First check that the current transport, TLS, and routing work properly. If your V2Fly setup is working, you can keep it. If you do migrate, compare features using the same node and avoid changing DNS and routing rules at the same time.
v2flyNG imported a VLESS node, but it won’t connect. What should I check?
Open the node details and check for REALITY or xtls-rprx-vision. If the node relies on these Xray features, switch to a v2rayNG version that supports the combination and re-import the configuration from the provider. Don’t simply delete fields the client doesn’t recognize.
Will Xray always be faster than V2Fly on the same node?
You can’t tell from the core name alone. Keep the server, transport combination, network, and test destination the same, then compare connection success rates and actual throughput. The node route, server load, and DNS differences may have a bigger impact than the core.
Do I need to turn TUN back on after switching cores?
First check how traffic was routed before. If your browser uses the system proxy, leave TUN off while testing the connection. If you need to route apps that ignore system proxy settings, enable TUN as required by the client and check its permissions and routing.
The choice comes down to three steps: check whether the node requires Xray features, choose a client that can represent the full configuration, then verify the logs and local traffic entry point. V2Fly and Xray’s shared history doesn’t replace compatibility checks, and similar-looking client interfaces don’t guarantee identical imported configurations.