Choose a core based on node settings, not the client’s name. For VLESS + REALITY or XTLS Vision, use an Xray setup that supports the required features. If your existing V2Fly configuration works, there’s no need to migrate just for a different name. This guide separates clients, cores, protocols, and transports, then walks through desktop and Android choices, settings to check, and troubleshooting steps.
Where the branches came from: Xray and V2Fly
Project V is an ecosystem of network communication tools and related specifications, with V2Ray as one of its core projects. The V2Fly community continues to maintain v2ray-core. Xray-core forked from v2ray-core in 2020 and has since developed along its own path for protocols and transport implementations. The two share code history, but they are not two skins for the same program, and their version numbers cannot be compared directly.
The core establishes connections, handles protocols, and applies routing and DNS rules. The client displays nodes, stores subscriptions, provides settings, and passes configurations to the core. Seeing a field in the interface doesn’t mean the running core understands it; likewise, a core’s capabilities depend on the client generating the right configuration.
- v2rayN: A desktop client. Available cores and core selection depend on the package and configuration type. When troubleshooting, check which core actually handled the connection.
- v2rayNG: An Android client that uses the Xray core. Suitable for nodes that require Xray-specific features.
- v2flyNG: An Android client that uses the V2Fly core. Suitable for setups with existing V2Fly configurations and maintenance workflows.
Protocol support: VLESS isn’t the same as REALITY
VMess, VLESS, Trojan, and Shadowsocks are proxy protocols; TCP, WebSocket, and gRPC are transport methods; TLS and REALITY relate to connection security and handshakes. XTLS Vision is a flow-control mechanism used with specific combinations in Xray. Treating all these terms as a single “protocol” can obscure the compatibility requirements that matter when switching cores.
| Configuration or feature | Xray | V2Fly | What to check first |
|---|---|---|---|
| VMess | Supported | Supported | Authentication parameters, transport, and TLS settings must match |
| Basic VLESS | Supported | Basic implementation supported | Doesn’t imply support for all Xray extensions |
| VLESS + REALITY | Supported | Xray’s REALITY configuration isn’t supported | Service name, public key, short ID, and related client parameters |
| XTLS Vision | Supported with compatible combinations | Xray’s Vision flow control isn’t supported | The node’s required flow value and transport combination |
| Trojan、Shadowsocks | Supported | Supported | Check specific methods, extensions, and transport capabilities individually |
Basic VLESS doesn’t encrypt traffic on its own, so it needs suitable transport security in deployment. VLESS + TLS and VLESS + REALITY aren’t interchangeable configurations. If the server uses REALITY, changing the client security option to TLS will usually cause a handshake failure, not a compatible connection.
- If you see
security=reality, first check whether Xray and the client support REALITY. - If you see
flow=xtls-rprx-vision, keep the flow control required by the server; don’t remove it just to bypass an error. - If you see
type=ws, also check the WebSocket path, Host, and TLS server name. A matching protocol name doesn’t mean you can omit these fields.
Choosing a client: match the core to your nodes
There’s no “fastest core” independent of the node. Congestion, server load, transport settings, and your local network all affect connection performance. You can’t rank the two cores by speed based on their names alone, and REALITY doesn’t guarantee connectivity on every network.
Xray core setup
RecommendedFor configurations that need REALITY or Vision, this guide recommends an Xray setup. On Android, use v2rayNG. On desktop with v2rayN, make sure the node is actually handled by Xray. This recommendation is based on feature compatibility, not untested speed claims.
Best for: Users whose server explicitly requires VLESS + REALITY or XTLS Vision.
V2Fly core setup
If your existing V2Fly configuration, rule files, and maintenance workflow work, you can keep using them. On Android, the matching client is v2flyNG. Before migrating, confirm that you actually need a feature exclusive to the target core; don’t rebuild your setup just because the client has a different name.
Best for: Users with nodes compatible with V2Fly who want to keep their existing configuration workflow.
If a subscription includes VMess, Trojan, and VLESS + REALITY, assess each node individually rather than labeling the whole subscription “universal.” Successfully importing the list only means the client recognized some or all of its contents; it doesn’t mean every node has passed a connection test.
From import to migration: check settings, then test the connection
Before switching cores, back up your subscription source and manually added configurations. Record the protocol, transport, security settings, and local listening port for each working node. Don’t copy a complete JSON configuration straight into another core: shared history doesn’t mean their formats remain identical, so check DNS, routing, and transport fields carefully.
- Find the subscription settings. In v2rayN, the usual path is “Subscription Group” → “Subscription Group Settings.” In v2rayNG, look for “Subscription Group Settings” in the top-right menu. Labels can vary by version, so check your installed build. Enter the subscription URL in the group URL field, not as the server address for an individual node.
- Check the node details. Review the server address, port, user ID, transport type, security type, and server name. For REALITY nodes, also verify the public key, short ID, fingerprint, and other server-required parameters. Don’t copy only the address and user ID.
- Confirm which core is running. On desktop, check the startup log for the core name and startup errors. On Android, first confirm whether you installed v2rayNG or v2flyNG. Changing subscription groups does not change the core.
- Test one node. Start with a node that has all required fields, check the logs, then open the site you actually need. A successful latency test only means that a specific test request worked; it doesn’t mean all apps are using the proxy.
- Restore rules last. Once the basic connection works, migrate DNS, routing, and per-app settings. Change one layer at a time and keep a working configuration to roll back to.
Desktop and Android setup: same source, separate tests
Desktop: v2rayN
- Import a trusted subscription and check that node details are complete.
- Make sure REALITY nodes run on a compatible Xray core.
- After connecting, configure the system proxy and routing.
Android: v2rayNG or v2flyNG
- Choose the client that supports the required protocol.
- Import from the same source, then update and test separately.
- Approve the VPN connection request, then check per-app access.
Using the same subscription source doesn’t sync settings between devices. Nodes may differ depending on the subscription contents and update times; maintain local routing and per-app settings separately.
Ports and proxy access: a working core doesn’t mean apps are connected
Server ports and local listening ports serve different purposes. The examples below use 443 and 10808 to show where each port goes; they aren’t universal defaults or measured results. Use the port provided for the server and the port currently configured in the client for local access.
For example, an app may be configured to connect to 127.0.0.1:10808, while the client listens on a different port. The app will still fail to connect even if the remote node is working perfectly. If the port only provides SOCKS, the app can’t use it as an HTTP proxy port. For mixed listeners, follow the client’s displayed settings.
- Desktop system proxy: Routes apps that honor the system proxy settings through the client, but not every program. In v2rayN, check the current option in the “System Proxy” menu.
- Routing rules: Once traffic reaches the core, rules decide whether it uses the proxy, connects directly, or gets blocked. Switching cores won’t automatically fix incorrect routing rules.
- Android VPN access: The system must authorize the connection when it starts. Also check that per-app proxy settings haven’t excluded the app you’re testing.
- Port conflict: If the log shows
address already in use, stop the old process using that port or change the local listening port and the app’s proxy settings.
FAQ: import succeeds, handshakes fail, or you need to switch cores
Why can v2flyNG import a VLESS node but not connect?
Open the node editor and check the security type and flow. Basic VLESS and VLESS + REALITY have different requirements. If the node requires REALITY or Vision, switch to v2rayNG, which supports those features, and recheck the fields. Don’t just change the security option to something else.
Can I use my existing JSON configuration directly after switching to Xray?
It depends. Keep a copy of the original file, then import a single-node share link into the client and test the minimal configuration. If you need to migrate a complete JSON file, check each field against the current core’s configuration format. If you get an unknown-field or parsing error, use the log to identify the issue rather than deleting multiple fields at random.
Does a failed REALITY handshake mean the core is outdated?
Version support is only one thing to check. Verify the device time, server address and port, public key, short ID, server name, fingerprint, and flow in that order. Once the settings match, update the client through a trusted installation source. Updating the interface alone may not help if it still launches an old core.
The node test passes, but my browser won’t load sites. What should I check first?
First check whether the system proxy or Android VPN is routing the browser, then verify the local port and routing rules. If the log shows a domain resolution failure, check DNS separately. Don’t change the core, DNS, and routing all at once, or it’ll be hard to tell what affected the result.
The choice comes down to a simple sequence: read the node’s complete settings, match them to the core’s capabilities, choose a client, then verify proxy access and routing. If your VMess or other compatible setup works reliably, there’s no need to rebuild everything just for a different name. For REALITY or Vision, use a compatible Xray setup rather than assuming compatibility from a successful import.