Choose a core based on the node’s configuration fields, not just whether it uses VMess or VLESS. If a node includes REALITY or xtls-rprx-vision, check Xray support first. For standard VMess, VLESS, and TLS setups, also verify the transport and configuration format. This guide is for users switching desktop cores, choosing an Android client, or troubleshooting connections after importing a subscription. It explains which fields are shared and which configurations cannot be transferred as-is.
1. Background: the client interface and proxy core are separate
V2Ray is a widely used name for a proxy project and its ecosystem. The core maintained by the V2Fly community is commonly called the V2Fly core, though its executable is still often named v2ray. Xray forked from the V2Ray project in 2020 and has developed independently since. The two share some configuration and protocol foundations, but similarly named features are not necessarily interchangeable.
v2rayN, v2rayNG, and v2flyNG are clients, not proxy cores. Clients parse subscriptions, let you edit nodes and routing, and launch processes; the core handles proxy connections. So, a node importing successfully only confirms that parsing worked—it does not mean the running core supports every field in that node.
- v2rayN: A desktop client. Support depends on the version, selected configuration type, and core in use—not just the client’s name.
- v2rayNG: An Android client that uses the Xray core. For REALITY or Vision, check that both the client and its bundled core support the required parameters.
- v2flyNG: An Android client that uses the V2Fly core. It suits setups where the server uses the V2Fly configuration system and the node features are supported.
2. Protocol support: VLESS doesn’t mean identical capabilities
VMess and VLESS are proxy protocols; TCP, WebSocket, and gRPC are transport settings; TLS and REALITY are connection security mechanisms. XTLS Vision is enabled through a VLESS flow-control field. Keep these layers distinct: “supports VLESS” does not automatically mean “supports VLESS + REALITY + Vision.”
| Feature | Xray core | V2Fly core |
|---|---|---|
| VMess | Supported; transport and security settings must also match | Supported; check authentication and version compatibility for older configurations |
| Basic VLESS | Supported | Supported, but this does not imply support for Xray extensions |
| XTLS Vision | Supports the corresponding VLESS flow-control options | Does not support Xray’s xtls-rprx-vision flow control |
| REALITY | Supported; client parameters must match the server | Does not support Xray’s REALITY configuration |
| WebSocket、gRPC | Common configurations work; check version and combination constraints | Common configurations work; use field formats documented for this core |
| JSON configuration | Uses its own configuration structure and extension fields | Distinguish between the legacy configuration format and the V5 format |
“Supported” in the table means the feature is available, not that every version accepts the same configuration. Transport names, fingerprint options, and extension fields in particular depend on the installed core version. If a client update still launches an older core, newly added fields in the interface may be rejected at startup.
3. XTLS Vision and REALITY: check the fields separately
The common XTLS Vision flow-control value is xtls-rprx-vision, set in the flow field of an Xray VLESS configuration. It is not a standalone node protocol or a general-purpose “speed boost” you can add to any transport. Don’t copy Vision flow control into WebSocket or gRPC nodes. Use only combinations explicitly provided by the server and supported by the core.
REALITY configures connection security; it does not replace VLESS user authentication. A typical VLESS + REALITY node still needs a user ID, as well as parameters such as the server name, public key, Short ID, and client fingerprint. Checking the certificate domain as you would for standard TLS is not enough to verify REALITY settings. Nor can you enable REALITY simply by selecting “skip certificate verification.”
- Check the protocol: Confirm that the node editor shows VLESS; don’t infer the protocol from the node’s label.
- Check flow control: If the server provides Vision, confirm that Flow is set to
xtls-rprx-vision. Don’t add it unless the server requires it. - Check the security type: Select REALITY when that is what the server uses; don’t leave the setting on standard TLS.
- Check each parameter: Match the server name or SNI, public key, Short ID, and fingerprint to the provider’s details. The server determines whether Short ID can be empty.
- Check the connection log: If it reports an unsupported field, address core compatibility first. If the handshake fails, check the parameters, system time, and network reachability.
4. Ports and JSON: easy-to-miss boundaries when switching cores
The local listening port and remote server port are different things. Here, 10808 is an example of a local proxy port and 443 an example of a remote server port; neither is a required default. Use the local listening setting under Settings → Parameter Settings and the server port in the node editor. Menu names may differ between interface versions.
When migrating configurations, inbounds describes local entry points, outbounds specifies where connections go, and routing determines which outbound handles traffic. Seeing these names in both files does not mean the full JSON configurations are compatible. V2Fly’s V5 configuration format differs structurally from its legacy format, and Xray extensions such as realitySettings cannot be passed directly to V2Fly.
- Keep the old configuration: Record the current core, local port, active node, and routing mode before switching so you can revert each setting if needed.
- Rebuild the node first: For most users, the client should generate the configuration from a subscription or the node editor. Avoid pasting an entire server-side configuration into the client.
- Preserve tag references: When migrating manually, each routing rule’s
outboundTagmust match an existing outboundtag. - Check for port conflicts: If two processes listen on the same address and port 10808, the core started second may exit. Stop the old process before starting the target core.
If the log reports an unknown field, check the target core and configuration format first; don’t keep changing the remote port. If it reports that the local address is already in use, resolve the listening-port conflict. Remote handshakes and connectivity tests are meaningful only after the core starts successfully.
5. Choosing a client: match node capabilities, not the name
For nodes that use REALITY or Vision, start with the Xray route. Either core may work for standard VMess or basic VLESS nodes. In that case, consider the server parameters, existing configuration, and maintenance workflow rather than assuming one core is faster. Speed also depends on the route, congestion, routing, and server load, so the core’s name alone cannot predict a specific performance gain.
Xray core
RecommendedIf a node explicitly uses REALITY or xtls-rprx-vision, choose an Xray version that supports those fields. On desktop, verify which core is actually running; on Android, consider v2rayNG and check the capabilities of its bundled core.
Best for: VLESS + REALITY, Vision nodes, and setups that already use Xray configurations.
V2Fly core
If the server provides a V2Fly configuration and does not rely on Xray extensions, you can stick with the corresponding configuration system. On Android, consider v2flyNG. Before migrating, check the configuration format, transport settings, and subscription parsing results.
Best for: maintaining existing V2Fly setups, standard VMess, or basic VLESS nodes.
Configuration workflow: check both clients against the same subscription
Desktop: v2rayN
- Add the subscription URL under Subscription Group Settings.
- After updating, check the node protocol, flow control, and security type.
- Start the node and confirm the active core in the log.
Android: choose by core
- Choose v2rayNG when you need Xray extensions.
- If keeping a V2Fly configuration, check what v2flyNG supports.
- After importing, open the node editor and check that all fields were retained.
The same subscription URL does not guarantee identical working nodes on both clients. The subscription format, parser, and bundled core can all affect the results.
6. Verify the migration: change one variable at a time
When switching from V2Fly to Xray or migrating the other way, start by testing one node with all required parameters. Don’t change DNS, routing rules, TUN, and the server address at the same time; otherwise, it’s hard to tell whether a failure is caused by the protocol or the traffic entry point. If the system proxy already works, you don’t need to enable TUN just to test a different core.
- Record the baseline: Note the original node’s protocol, transport, security type, remote port, and local listening port. Don’t share your user ID or subscription URL.
- Choose a compatible node: When migrating back to V2Fly, you can’t keep using parameters that depend on REALITY or Vision. Get a compatible node from the server provider.
- Rebuild and start: Enter the parameters in the target client’s node editor. Check the log to confirm the configuration is accepted and the core stays running.
- Verify the traffic entry point: On desktop, confirm the system proxy points to the current listening port. On Android, make sure the proxy service is running, then test access in a browser.
- Restore routing settings: Once the basic connection works, restore split routing, DNS, and per-app settings. Restore one group at a time and check the relevant logs as soon as an issue appears.
When sharing troubleshooting details, include only the error type and necessary field names. Never include subscription URLs, user IDs, private keys, or other authentication parameters in public screenshots. What others need to know is which core, which field, and where the failure occurred—not your full node credentials.
7. Common questions: troubleshoot importing, startup, and connections separately
Why can v2flyNG import VLESS but still fail to connect to a REALITY node?
VLESS support and REALITY support are separate. Open the node editor and check the security type. If the node requires REALITY, use an Xray client that supports it and recheck the public key, server name, and Short ID. Keeping only the address and user ID is not enough.
After switching cores in v2rayN, I get a “flow not supported” error. Can I clear the flow value?
First check whether the server requires xtls-rprx-vision. If it does, use an Xray core that supports it and verify the transport combination. Clearing flow may leave the client and server settings out of sync. Re-enter the settings from a standard VLESS configuration only if the server explicitly provides one.
Do VMess nodes need to use V2Fly for compatibility?
No. Both cores support VMess. In the node editor, check the address, port, user ID, transport, WebSocket path or gRPC service name, and TLS server name. For older nodes, also confirm that the authentication settings work with the current core. Don’t assume the core brand is the cause of every problem.
The log shows no errors, but websites won’t load. Did I choose the wrong core?
First check whether the log shows an actual connection attempt. On desktop, check the system proxy status in the tray menu and verify the local port; on Android, make sure the service is still running. If traffic is reaching the core, check DNS, routing matches, and remote handshake logs. Don’t keep switching cores just because a website failed to load.
A reliable way to choose is to follow this order: check the node’s protocol, transport, security type, and flow control; confirm the client preserves all those fields; then verify the core actually in use. REALITY and Vision point clearly to Xray. For standard VMess or basic VLESS, check configuration compatibility and logs instead of judging by name alone.