Choose a core based on your node’s requirements first, then consider which client you prefer. If a node uses REALITY or xtls-rprx-vision, check Xray compatibility first. For VMess, standard TLS, and similar configurations, don’t switch cores based on the name alone. This guide is for anyone comparing desktop and Android clients, seeing unsupported-configuration errors after importing a node, or planning to migrate between cores.
Project history: V2Fly and Xray are not two client skins
Project V provides the project context for the development of related tools and protocols, with V2Ray among its widely used proxy cores. The V2Fly community continued maintaining the V2Ray core and related projects, which is why you’ll see both “V2Ray core” and “V2Fly core.” For compatibility discussions, specify the project, version, and configuration format rather than saying only “V2Ray.”
Xray forked from the V2Ray codebase in 2020 and has developed independently since. The split was connected to disagreements over XTLS-related technology and the direction of project maintenance at the time. Their shared origins mean some protocols and routing fields remain similar, but features and configuration semantics have since diverged. Don’t assume a complete JSON config for one project will work unchanged with the other.
- Core: Handles low-level tasks such as protocol handshakes, inbound and outbound connections, routing, and DNS.
- Client: Provides the node list, subscription import, system proxy controls, and logs, then passes the configuration to the core.
- Subscription: Distributes node parameters. A successful import only means the client read the data; it does not mean the core supports every feature.
So “v2rayNG can import it” and “V2Fly can run it” are not the same thing. A client may parse a share link but still fail when generating the runtime config, starting the core, or completing a handshake with the server.
Protocol overview: What VLESS, XTLS Vision, and REALITY do
The same protocol name doesn’t guarantee the same security layer, transport, or flow-control settings.VLESS defines a proxy protocol but does not encrypt traffic on its own; typical deployments need TLS, REALITY, or another mechanism. XTLS Vision is a flow-control mode, while REALITY is a separate connection security mechanism. They are not interchangeable options.
| Configuration feature | Xray | V2Fly | What to check |
|---|---|---|---|
| VMess | Supported | Supported | Transport, TLS, and system time still need to be checked |
| VLESS base protocol | Supported | Basic support | Does not guarantee compatibility with later extensions |
| VLESS + TLS + WebSocket | Supported in compatible combinations | Check the version and configuration format | The path, Host, and server requirements must match |
| xtls-rprx-vision | Supported | This Xray flow-control mode is not supported | Don’t remove the flow field to force compatibility |
| REALITY | Supported | This Xray feature is not supported | Use an Xray client that can run this configuration |
“Supported” in the table does not guarantee compatibility with every legacy version. Older cores and share-link parsers in older clients may lack parameters added later. When troubleshooting, note both the client version and the core version actually in use. Updating the client interface alone doesn’t necessarily update the core binary.
Bottom line: Check security and flow first
If you see security=reality or flow=xtls-rprx-vision, first verify that Xray and your client support them. If they don’t, switch to a compatible client or ask your provider for a node configuration with different settings. Don’t delete parameters just to get the core to start.
Choosing a client: v2rayNG or v2flyNG?
On Android, v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. Choose based on your node’s configuration, not on which app name or icon looks familiar. The recommendations below assume your subscription may include REALITY or Vision; they don’t mean one core is faster on every network.
v2rayNG: Xray-based
RecommendedIf your subscription includes VLESS + REALITY or Vision, this is the first client to try. Confirm that your installed version can parse all the required parameters. Existing VMess nodes may also work—test their actual configuration rather than buying a new subscription just to change cores.
Best for: Android as your primary client, especially if your subscription requires Xray features.
v2flyNG: V2Fly-based
If your existing nodes use V2Fly configurations and your usual protocols have been tested, you can keep using them. Before migrating, check the protocol, transport, and security layer. Don’t treat v2flyNG as a universal replacement for clients that run Xray configurations.
Best for: Users with an existing V2Fly setup who need to keep their current configuration consistent.
v2rayN: Desktop client
On desktop, check which cores are included in your current release, then confirm which one the selected node actually uses. Core selection options vary by release package and version, so don’t infer the available core from the client name alone.
Best for: Desktop system proxy use, log inspection, and checking which core is running.
If you install both Android clients for comparison, don’t enable their VPN connections at the same time. Usually, only one app can claim the VPN service for a user at a time. Starting the second connection may replace the first, making it look as though switching cores caused the disconnection.
Using desktop and Android: Share subscriptions, check runtime settings separately
You can import the same subscription on desktop and Android, provided your provider allows the number of devices and both clients can read the subscription format. Even with the same node list, routing groups, per-app proxy settings, local listening ports, and DNS behavior may differ between devices.
Recommended approach: Check the full node configuration on each device
Desktop: v2rayN
- Check the selected node and the core actually running, not just the name in the list.
- Check the system proxy status and distinguish browser proxy settings from apps that connect directly.
- Use the runtime log to record core startup results and connection errors.
Android: v2rayNG or v2flyNG
- Choose a client based on whether the node requires REALITY or Vision.
- Confirm VPN permission before connecting, and run only one client during testing.
- Check per-app proxy settings and make sure the test browser isn’t excluded.
Updating a subscription only fetches the content published by your provider. Check each device’s local runtime settings separately.
If desktop connects but Android doesn’t, compare the same node’s address, port, transport, security layer, and flow-control settings. Don’t blame the core right away: the devices may have selected nodes with the same name but different parameters, or only one may have received the latest subscription.
Ports and fields: Break connection failures into checkable settings
The two ports below are troubleshooting examples, not universal client defaults. Your provider supplies the remote port; the client settings determine the local listening port. They serve different purposes, so don’t enter the local SOCKS port as the node’s remote port.
For example, a browser or test tool connecting to the local proxy can use 127.0.0.1:10808 if that port is enabled. The core then connects to the node’s remote port. These are two separate connections—app to local proxy, then core to remote server—so a successful local connection doesn’t confirm that the remote handshake worked.
- Basic connection: Check the remote address, port, user ID, and system time. VMess is sensitive to clock skew, and TLS certificate validity checks also depend on the correct time.
- Transport: For WebSocket nodes, check the path and Host. Don’t mix WebSocket settings with raw TCP configuration.
- Security layer: For standard TLS, check the server name and certificate validation. For REALITY, verify the server name, public-key parameters, and shortId provided by your provider.
- Flow control: If your provider specifies
xtls-rprx-vision, use that exact value. Changing flow won’t make the server switch protocols automatically. - Runtime results: Distinguish “unknown field,” “handshake failed,” and “connection timed out.” Check compatibility, authentication parameters, and network reachability accordingly.
Before and after switching cores: Change one variable at a time
To test whether switching cores makes a connection faster, use the same node, test target, and roughly the same time. TCPing mainly checks whether a TCP connection can be established; it doesn’t confirm a successful proxy handshake. A real connection test is closer to an actual proxy request, but doesn’t guarantee sustained download speeds or how every website will perform.
- Back up first: Save the subscription source, current node parameters, routing, and DNS settings. Hide your user ID and subscription URL in screenshots.
- Confirm the core starts: Start it first and check the logs for configuration parsing errors. If startup fails, don’t keep switching nodes to mask a configuration problem.
- Test a proxied request: Run a real connection test with the same node, then use the same browser to visit the same destination. Confirm that the system proxy or VPN connection is actually active.
- Test routing separately: Once connected, check the direct and proxy rules. If a website is routed directly, that doesn’t mean the new core failed to handle traffic.
- Record changes and roll back if needed: Note the client and core versions, error type, and settings changed. If things get worse, restore the previous settings. Don’t change DNS, routing, and transport parameters all at once.
Bottom line: Establish compatibility before comparing performance
If your current configuration works reliably, there’s no need to migrate just because of a core’s name. If you need REALITY or Vision, choose an Xray-based client that supports the configuration and test the connection under the same conditions. Core selection doesn’t replace checking node quality and network routing.
FAQ: Import success, legacy nodes, and migration problems
Why can v2flyNG import a VLESS link but still fail to connect?
Expand the node details and check whether it uses REALITY or Vision. Recognizing basic VLESS fields doesn’t mean the core can run these extensions. If the node requires features the core doesn’t support, switch to a compatible client such as v2rayNG, or ask your provider for a node configuration with a different protocol combination.
Do I have to move my old VMess nodes from V2Fly to Xray?
No. Both core families support VMess, but the result also depends on the transport, TLS, server configuration, and version compatibility. If your current nodes work reliably, keep the settings. Check the logs when a specific error occurs; switching cores isn’t a universal fix.
Can I give V2Fly an entire Xray JSON configuration as-is?
Don’t assume that will work. Some structures look similar, but extension fields, transport settings, and configuration options can vary across projects and versions. When migrating, adapt the configuration to the target core’s format. First test a minimal connection, then add routing, DNS, and other settings gradually.
Will updating my subscription give the client support for new core features?
No. Subscription updates refresh node data; they don’t make an unsupported core support new features. If a new node requires additional functionality, check both the client’s ability to parse the configuration and the core’s implementation. After updating, confirm the selected node and the version actually running.
Choose a client and platform
Use v2rayN on desktop. On Android, choose v2rayNG or v2flyNG based on the node requirements. Check protocol and security-layer support before importing your subscription and testing the connection.