Xray-core vs. V2Fly: Protocol Support, Config Compatibility & Client Choice

At a glance

The core determines whether node settings can run; the client handles importing, editing, and system integration. For VLESS, REALITY, and Vision, check Xray support first. If you already use VMess nodes and V2Fly configs, test your existing setup before switching—different names alone aren’t a reason to migrate. The sections below walk through protocols, config fields, client options, and troubleshooting.

1. How Project V, V2Fly, and Xray-core relate

Project V is an ecosystem of networking tools and technologies built around V2Ray. The V2Fly community continues to maintain V2Ray-core, while Xray-core branched from related code in 2020 and has developed independently since. The two share a common origin, but later additions to transports, config fields, and implementation details aren’t guaranteed to be compatible.

“V2Ray node” is often used as a catch-all term for a subscription service, but it doesn’t identify the core. A connection might use VMess or VLESS, with WebSocket or TCP transport. Check the actual protocol and settings—not the subscription group name.

Client layer: Manages subscriptions, selects nodes, and configures the system proxy or virtual network interface. Examples include v2rayN for desktop and v2rayNG or v2flyNG for Android.
Core layer: Parses config and handles protocol handshakes, DNS queries, routing, and traffic forwarding. Xray-core and V2Fly’s V2Ray-core operate at this layer.
Server layer: Defines the connection protocol, authentication parameters, and transport requirements. Changing the local core won’t automatically convert a server’s VMess setup to VLESS.

2. Protocol support: VLESS, REALITY, and Vision are different

VLESS is a proxy protocol, REALITY is a security transport, and xtls-rprx-vision is a flow-control option used with Xray. They’re separate settings, and none describes the entire connection on its own. A common combination is VLESS over TCP with REALITY, plus Vision if required by the server.

Capability or combination	Xray-core	V2Fly V2Ray-core	What to check
VMess with common WebSocket/TLS configs	Supports the corresponding config	Supports the corresponding config	Authentication parameters, path, Host, and TLS name
VLESS base protocol	Supported, with related capabilities continuing to expand	Don’t assume it’s entirely unsupported based on the name alone; check the version and implementation scope	The full transport combination, not just the protocol name
VLESS + REALITY	A primary use case	Don’t import and use an Xray REALITY config as-is	Server name, key-related parameters, and shortId
xtls-rprx-vision	Supports the corresponding flow-control combination	Not an equivalent capability you can swap in directly	Whether the client and server use the same flow
Basic DNS and rule-based routing	Supported	Supported	Field structure, rule order, and data file format

For VMess, check the authentication method too. Common AEAD nodes use alterId: 0; don’t apply non-zero values from old guides without checking. This is a protocol compatibility setting, not a performance knob to turn up for more speed.

Bottom line: choose a core for the complete connection setup

If a node specifically requires REALITY or xtls-rprx-vision, use an Xray setup that supports it. For VMess, WebSocket, or TLS alone, test your current setup first—there’s no need to migrate just to chase speed.

3. Config compatibility: both use JSON, but configs aren’t interchangeable

Both lines use concepts such as inbounds, outbounds, and routing, but similar fields only reflect their shared origins. New transports, security settings, DNS behavior, and differences among V2Fly config formats can all affect parsing and runtime behavior.

Subscription links use a separate format. Clients typically parse a share link into an internal node, then generate config for the corresponding core. So “subscription imported successfully” only means the interface accepted the content. It doesn’t prove the generated config is valid for the core—or that the remote handshake will succeed.

Check protocol fields first: Confirm whether protocol is VMess or VLESS and that the authentication ID matches the server. Don’t expose full credentials in screenshots or public logs.
Then check transport fields: Verify network and security under streamSettings. TCP and WebSocket aren’t interchangeable, and neither are TLS and REALITY.
Check flow control separately: If the server requires Vision, verify that flow in the generated config is set to xtls-rprx-vision. Don’t add it to a standard VMess node.
Finally, check routing: Make sure every rule references an outbound tag that exists. A tag is just an internal config reference; naming it “proxy” doesn’t make it proxy traffic.

Here’s a partial example of common routing fields to show how references work—not a complete, ready-to-run config. It assumes an existing direct outbound named direct and that the core can load a GeoIP data file containing the private tag.

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

4. Choosing a client: v2rayN, v2rayNG, and v2flyNG

On desktop, first check which core v2rayN is currently using, then consider node compatibility. On Android, choose by project line: v2rayNG uses Xray, while v2flyNG uses V2Fly. Similar names don’t mean identical protocol support, or guarantee that both apps will make the same nodes usable from a subscription.

Xray line: the Xray core in v2rayN or v2rayNG

Recommended

Prefer this option when nodes require VLESS, REALITY, or Vision. Check that the client’s bundled core supports the specific parameters used by the server.

Best for: Subscriptions with REALITY or Vision nodes that require these protocol capabilities.

V2Fly line: v2flyNG or an existing V2Fly setup

Keep using this option if you have validated VMess configs and depend on the V2Fly config system. Choose based on whether your existing config runs reliably—not on the assumption that older configs are automatically obsolete.

Best for: Maintaining an existing V2Fly deployment and reusing nodes and routing rules known to be compatible.

In v2rayN, check local listeners and core settings under “Settings” → “Parameter settings.” Option names and locations can vary between releases. If the expected core option isn’t shown, refer to the current release notes and runtime logs. Don’t replace executables in the program folder to guess at compatibility.

Setup plan: verify desktop and Android separately

Desktop: v2rayN

Record the core name and version from the startup log.
After importing a node, check its protocol, transport, and security settings.
Check the local port, then verify the system proxy and routing rules.

Android: choose a client by core

For REALITY/Vision, check v2rayNG first.
For an existing V2Fly config, test it in v2flyNG first.
Confirm system VPN permission and per-app settings cover the apps you need.

You can use the same subscription on both platforms, but check protocol parsing, routing policies, and app coverage separately.

5. Migration checks: confirm the core starts, then verify traffic is proxied

Change one variable at a time during migration. Keep a backup of your existing subscription and routing config, then test the new core with a node known to be compatible. Don’t change the node, DNS, routing mode, and local port all at once; if the connection fails, it’ll be hard to tell which change caused it.

Check startup: Open the client log and first rule out config parsing errors, unknown fields, and port conflicts. There’s no need to assess remote connection speed yet.
Confirm the listener: In v2rayN, check the local listening port under “Settings” → “Parameter settings.” The example below uses an enabled SOCKS listener at 127.0.0.1:10808; this isn’t a fixed value for every installation.
Specify the proxy explicitly: Send a request from the command line to rule out whether the browser reads the system proxy. The command below only applies if a SOCKS service is actually listening locally.
Verify routing: Temporarily route the test target through the proxy outbound and check the logs to confirm which outbound was used. A successful request alone doesn’t prove that a direct rule didn’t handle it.
Test your apps: Then enable the system proxy or relevant traffic-routing mode and test your everyday apps. On Android, make sure per-app rules haven’t excluded the app.

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

In a Windows terminal, use curl.exe to avoid command alias conflicts. Here, socks5h sends the destination hostname to the proxy for resolution; it doesn’t guarantee that traffic ultimately uses the remote proxy outbound, since core routing rules still apply. The 10-second connection timeout and 20-second total timeout are test settings, not speed guarantees.

Symptom	Check this layer first	Next step
Core exits immediately on startup	Config parsing, file paths, local listener	Find the first error in the log; don’t switch remote nodes yet
Connection refused on local port	Core process, address, and port	Confirm the listener is enabled and the test port matches its settings
REALITY handshake fails	Parameter match, system time, server reachability	Check the server name, key-related parameters, and shortId
Command-line request succeeds, browser fails	System proxy, browser policy, extension settings	Check where the proxy applies first, then compare DNS and routing behavior

6. Performance: core names don’t replace like-for-like tests

You can’t compare Xray and V2Fly performance without accounting for the protocol and network path. Egress congestion, round-trip latency, packet loss, server load, and frequent device sleep can all matter more than the core itself. Vision’s reduced processing overhead for supported traffic doesn’t mean every webpage will load noticeably faster.

Keep test conditions constant: Use the same device, network, server, and destination address. Don’t compare a result over Wi-Fi with one over a mobile network.
Compare like with like: Use the same protocol combination supported by both cores. Comparing VMess/WebSocket with VLESS/REALITY measures differences between complete setups, not just cores.
Separate the metrics: Track connection success rate, time to first response, sustained transfer, and device CPU usage. Don’t use a single latency reading as a measure of reliability.
Repeat the test: Alternate five requests with each setup and record the results to reduce the impact of brief network fluctuations. This is a testing method, not a performance ranking from this article.

Bottom line: migrate only when there’s a clear reason

Switch cores only when a required feature is missing, a compatibility issue is confirmed, or a reproducible fault occurs under the same conditions. If the node itself is unreachable, troubleshoot the connection and parameters first.

7. FAQ: successful imports, failed switches, and mixed subscriptions

The subscription updates, but why won’t the REALITY node connect?

A successful update only means the subscription request returned content. Open the node editor and check VLESS, REALITY, server name, key-related parameters, shortId, and flow in order. Then check the startup log to confirm that the running Xray core supports the required settings.

If I switch from v2rayNG to v2flyNG, will all my existing nodes still work?

Don’t infer compatibility from the number of nodes. First test nodes with protocols and transports known to be compatible. Nodes requiring REALITY or Vision aren’t standard VLESS nodes. Keep the original client config and migrate your daily setup only after the tests pass.

After switching cores, I get a port-in-use error. Should I change 10808?

First close any other client instance or leftover core process, then check the listening address and port under “Settings” → “Parameter settings.” If you do need a different port, update the test command and any app settings that use it too—not just one of them.

My subscription has both VMess and VLESS. Do I need to install two clients?

A mix of protocols alone doesn’t mean you need two clients. Check whether one client and its current core support the combinations you actually need. Manage compatible nodes in one setup; keep a second only if there’s a specific feature or compatibility requirement.

Choose in this order: check the server requirements, then core capabilities, then the client and system traffic-routing method. To troubleshoot subscriptions, DNS, or proxy coverage, follow the steps in Troubleshooting. For definitions, see the Glossary.