Xray vs. V2Fly: Core Differences, Project History, and Config Compatibility

How the Fork Happened: Projects, Cores, and Clients Are Different Layers

Project V is the starting point for understanding this ecosystem, and V2Ray is its proxy software. The V2Fly community continues to maintain v2ray-core; Xray-core forked from the V2Ray codebase in 2020 and has since developed independently. The fork means the projects once shared code and configuration conventions—not that their later features, config formats, or release schedules remained aligned.

In everyday usage, “V2Fly core” usually means v2ray-core maintained by V2Fly, while “Xray core” means Xray-core. v2rayN, v2rayNG, and v2flyNG are client apps that manage nodes, provide interface settings, and launch a core. Client and core versions are separate details; record both when troubleshooting.

• Protocol layer: VMess, VLESS, and other protocols define how the client and server exchange proxy requests.
• Transport and security layer: TCP, WebSocket, TLS, and REALITY determine how a connection carries traffic and establishes a secure session.
• Core layer: Parses the config and handles DNS, routing, inbound, and outbound traffic.
• Client layer: Reads subscriptions, generates core configs, and handles system proxy settings or Android VPN interfaces.

So, “the client can import a link” and “the core can establish a connection” are two different things. A link parser may recognize VLESS but fail to retain a flow-control or security field required by the server. Seeing a node in the interface doesn’t prove the config is complete.

Feature Differences: Focus on the Vision and REALITY Combination

VMess is a common use case for both cores, but that doesn’t mean every feature is compatible. VLESS is a proxy protocol, XTLS is a related technology, Vision is a commonly used flow-control mode, and REALITY is a transport security solution. They belong to different layers and aren’t four interchangeable node types.

If your provider specifies VLESS + TCP + REALITY with the flow set to xtls-rprx-vision, choose a core that supports that exact combination. Replacing REALITY with TLS or removing the Vision field won’t automatically produce a working compatible node; the server must also support the corresponding connection method.

Config Compatibility: Nodes Can Be Migrated; Full Configs Need Care

“Will this node connect?” and “Can I use this exact JSON?” are different questions. The first is mainly about remote connection settings. The second also involves local listeners, DNS, routing rules, outbound tags, and core-specific options. Two files containing inbounds and outbounds aren’t necessarily interchangeable as-is.

1. Migrate node settings first: Match the address, port, user ID, transport, and security settings one by one. A share link usually doesn’t include all of the client’s local settings.
2. Then recreate your routing rules: Note which domains should connect directly, use the proxy, or be blocked. Recreate the rules in the new client and confirm their order.
3. Handle DNS separately: Check the resolver address, query route, and domain-matching method. The same remote DNS address doesn’t mean the DNS policies are the same.
4. Check core-specific fields last: Recheck XTLS fields from older guides, transport names used by different config formats, and REALITY parameters against the actual core version.

For WebSocket + TLS, using port 443 on both ends doesn’t prove the connection settings match. The WebSocket path belongs to the HTTP upgrade request, Host is a request header, and the TLS server name is used for the handshake and certificate verification. These values can differ; don’t replace them all with the server’s IP during migration. Disabling certificate verification isn’t a routine fix, either.

Enter the REALITY server name, public-key-related parameters, short ID, and fingerprint option using the provider’s details and the fields available in your current client. Interface labels, JSON fields, and share-link parameter names can vary by version; don’t rename fields by guessing from similar wording. Before sharing a config for troubleshooting, remove subscription URLs, user IDs, and other access credentials.

Choosing a Client: v2rayN, v2rayNG, and v2flyNG

On desktop, check which core the current node actually uses in v2rayN instead of relying on the window title. The client usually generates configs for standard nodes; custom configs may instead be passed as-is to the selected core. A setting missing from the node editor doesn’t necessarily mean the core lacks support—and the reverse is also true.

These recommendations are based on the protocol requirements discussed here, not speed rankings. Download performance on the same VMess connection also depends on server load, network path, congestion control, and client policies. Speed tests taken at different times can’t be attributed entirely to the core, and switching cores doesn’t guarantee lower latency.

Verification Order: Check Ports, Syntax, and Live Traffic Separately

Start troubleshooting with a repeatable baseline. The ports below are test examples, not defaults for every client. Suppose the server uses port 443 and you manually set the local SOCKS inbound to 10808: your test program must connect to the address and port actually configured. For other client versions that use a mixed inbound, check the listening address and port in the interface or generated config.

If you manage JSON directly, use the core’s built-in test subcommand to check the syntax. The examples below use common command formats for Xray and V2Fly v5, respectively; the executable name depends on how the software was installed. Check a copy of the config first, and don’t overwrite the original if it still works.

# Xray: check the config file in the current directory
xray run -test -config config.json

# V2Fly v5: check the config file in the current directory
v2ray test -c config.json

Passing a syntax check only means the config can be parsed. It doesn’t prove the remote server is reachable, the credentials are valid, or traffic will use the expected outbound. If an option isn’t recognized, check the program’s help output to confirm what the installed version supports. Don’t delete unfamiliar settings just to pass the check.

1. Check startup logs: First address unknown fields, config syntax errors, and local port conflicts. The connection hasn’t reached the remote handshake stage yet.
2. Check network connectivity: If timeouts persist, verify the server address, port, and network reachability before changing the user ID.
3. Check the handshake: For TLS or REALITY failures, verify the server name, security method, and key parameters. Also make sure the device clock is accurate.
4. Check actual requests: Use a program with an explicitly configured proxy to access the target, then check system proxy settings or Android’s VPN coverage. Don’t mistake requests that bypassed the proxy for core failures.
5. Restore routing and DNS: Once the basic connection works, restore settings one at a time and retest after each change to identify which policy affected the result.

Final Checks Before Migration: Keep a Fallback and Avoid Repeated Changes

If both cores support your current node, choose based on maintenance effort and how easily you can validate the config. A stable VMess + WebSocket + TLS setup doesn’t need to become VLESS just to use consistent terminology. If the server already requires REALITY, don’t simplify the connection settings just to keep using an older setup.

• Back up the original config separately and give the test config a distinct name to avoid subscription updates overwriting manual changes.
• Stop one app before starting the other to avoid local listening port conflicts.
• Clean up the old config only after migration succeeds; keep one tested fallback path in the meantime.