Xray vs. V2Fly: Core Differences, Configuration Compatibility, and Which to Choose

1. Background: Shared Roots, Different Development Paths

V2Ray began as a proxy tool in the Project V ecosystem. The V2Fly community continued maintaining the related code and documentation, and the core executable is still commonly named v2ray. Xray forked from the V2Ray codebase in 2020, initially in connection with XTLS development, and has since evolved independently. The two projects share a history, but release schedules, implementation changes, and configuration interfaces are maintained separately. A common origin doesn’t mean that every feature added later will be shared.

Keep the client and core distinct, too. v2rayN provides a desktop interface, subscription management, and config generation; the selected core handles the actual connection. v2rayNG is an Android client that uses the Xray core, while v2flyNG uses V2Fly. A node appearing in the client only means its details were saved—it doesn’t mean the running core supports every parameter it contains.

• Client layer: Imports share links, saves subscriptions, selects nodes, and converts interface options into core configuration.
• Core layer: Establishes connections, handles protocols, applies DNS and routing rules, and writes runtime logs.
• Server layer: Determines which protocols, transport methods, and security settings are accepted. Changing the local core won’t change what the server supports.

2. Protocol Support: VLESS and REALITY Operate at Different Layers

VMess and VLESS are proxy protocols; TCP and WebSocket describe how a connection is carried; TLS and REALITY concern connection security. These categories describe different functional layers, not a compatibility matrix where any combination will work. The client must support the server’s specific combination and be configured with the matching parameters.

So, “VLESS requires Xray” is too broad, and “supports VLESS, therefore supports REALITY” is also incorrect. If a node requires security=reality or specifies flow=xtls-rprx-vision, you can’t replace its core just because another one supports basic VLESS. Check the protocol, transport, security settings, and flow together.

REALITY configurations typically also involve the server name, server-provided public-key parameters, a short ID, and a client fingerprint. Field names can vary by version and client interface; changing only security from tls to reality does not complete a migration. Conversely, if a standard VMess + WebSocket + TLS node is working reliably, there’s no need to change the server just to switch cores.

3. Config Compatibility: Similar JSON Doesn’t Mean Drop-In Compatibility

Both cores commonly use structures such as inbounds, outbounds, and routing, but that similarity only reflects shared design roots. Whether a particular field is accepted, what its default is, and whether it depends on a specific transport implementation all depend on the core version parsing the config. Don’t assume V2Fly’s different config formats and the JSON commonly used by Xray can be swapped without checking.

1. Check the config format first: Identify the file format and how it’s loaded. Don’t pass an object in one format to a parser expecting another.
2. Then check outbound parameters: Verify the protocol, address, port, user ID, transport, SNI, path, and security options one by one—not just the node name.
3. Next, check core-specific fields: For REALITY, Vision, or transport options added by a particular core, consult the target core’s documentation. Don’t just delete an unrecognized field and carry on.
4. Finally, check runtime dependencies: Rule data files, certificate paths, and the working directory used to resolve relative paths can all affect startup.

Share links and subscriptions aren’t complete core configurations. After importing vmess:// or vless://, the client still has to map those parameters into its actual config. Updating a subscription usually updates node entries; it won’t automatically verify your DNS, routing, and custom templates. During migration, inspect the generated config or startup log to confirm the client passed the selected options to the core.

4. Choosing a Core: Start with Your Nodes and Maintenance Setup

The recommendations below apply specifically to setups that require REALITY or Vision; they don’t mean the other core is universally behind. If your nodes, config templates, and operations workflow are built around V2Fly, keeping a proven setup usually means less troubleshooting than migrating. If the server explicitly requires an Xray feature, prioritize compatibility with that requirement.

Don’t rank performance by core name alone. Latency and throughput depend on server load, network route, transport, device performance, and concurrency. For a fair comparison, keep the device, node, test window, and routing policy constant. If you also change VMess + WebSocket to VLESS + REALITY, you can’t attribute the result simply to switching cores.

5. Switching Cores: Keep a Baseline and Change One Variable at a Time

Back up your client config and custom templates, and note which nodes currently work and which core version they use. v2rayN menus and core-selection options vary by version and interface branch, so check the current interface and startup logs. The ports below are examples for reproducible checks, not universal defaults across the three clients. Replace them with the ports actually listening on your device.

1. Record a baseline: Confirm a node works with the current core, then note the local listening address, port, system proxy state, and routing mode.
2. Change only the core: Keep the node, DNS, and rules unchanged. Don’t enable TUN, replace rule files, and modify transport parameters in the same test.
3. Inspect the generated config: Confirm the target core receives all protocol and security fields. If the client can’t generate a required field, fix the client compatibility issue first.
4. Check startup and connectivity: First confirm the config parses, then verify the local port is listening, and finally check the server connection and target request.
5. Restore the full setup: Once basic proxying works, restore split routing, system proxy, or TUN settings one at a time, checking the logs after each change.

For standalone configs you manage yourself, start by testing the config. The commands below are for Xray and V2Fly versions that support the corresponding command interface. Use the one for your installed core; on Windows, use the matching executable name. If an older version uses different options, check its help output first.

# Xray: test local config.json
xray run -test -config config.json

# V2Fly: test local config.json
v2ray test -c config.json

A successful config test only means the current core accepts the file; it doesn’t prove the server is reachable. If a SOCKS endpoint is actually listening at 127.0.0.1:10808, use this command to test the proxy path separately. socks5h sends the target hostname to the proxy for resolution, making it easier to distinguish from local DNS resolution.

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 -I https://v2ray-home.com/

If this command succeeds but your browser fails, check which proxy endpoint the browser actually uses, the system proxy state, and the browser’s own settings. If the first log error is address already in use, check for a port conflict first. There’s no point changing remote DNS or the server port before the config loads successfully.

6. Common Issues: Imports, Handshakes, and Rollbacks

The goal is a reproducible compatibility setup: the server determines the required capabilities, the client determines whether it can express the parameters correctly, and the core executes the connection. When your existing config is stable, keep a baseline you can roll back to. When you need a new feature, verify it alongside client support and server parameters. For more on config fields, see the Protocol Reference. For basic imports and connection steps, see Getting Started.