Project V was the early project ecosystem; V2Fly is the community-maintained continuation of the V2Ray core, while Xray is a separate core line that extends protocol and transport capabilities while retaining compatibility with many existing configurations. By the end, you can distinguish project, core, and client names and choose a client based on subscription fields such as VMess, VLESS, XTLS Vision, and REALITY.
Project V is a project ecosystem, not a single client
Project V originally referred to a set of open-source tools and specifications built around network proxying. V2Ray Core is the component responsible for connections, protocols, routing, and outbound traffic. In everyday discussions, Project V, V2Ray, and a graphical client are often used interchangeably, but they belong to different layers.
After receiving a configuration, the core establishes inbound and outbound connections. It reads the listening address, port, user identifier, transport, TLS parameters, and routing rules, then determines which exit handles the traffic. The client wraps the core with subscription updates, node lists, latency tests, system proxy controls, and log viewing. Whether a button performs an operation depends on the interface; whether a protocol connects depends mainly on the core being used.
- Project layer: Project V describes the early ecosystem and its development history; it is not the name of an application you click after installation.
- Core layer: V2Ray Core, V2Fly Core, and Xray Core parse configurations, handle protocols, apply routing, and establish connections.
- Client layer: v2rayN, v2rayNG, and v2flyNG provide interfaces for subscriptions, nodes, logs, and system proxy controls.
- Service layer: A subscription supplies node parameters, which the client imports and passes to the relevant core; the subscription itself is not a core.
V2Fly and Xray: why they became two separate paths
As the project moved to community maintenance, V2Fly continued the existing V2Ray codebase, configuration structure, and general proxy capabilities. For users relying on common inbound or outbound methods such as VMess, VLESS, Shadowsocks, SOCKS, and HTTP, V2Fly remains an actively maintained core path. It is not merely a rename, but a community project with its own release cadence and documentation.
Xray evolved from the V2Ray codebase and retains many similar JSON configuration structures while expanding capabilities around VLESS, XTLS, Vision, and REALITY. Because their historical foundations are related, the two often understand the same basic fields, but protocol parameters, transport options, and routing behavior are not necessarily identical.
| Comparison | V2Fly Core | Xray Core |
|---|---|---|
| Development relationship | Community-maintained continuation of the V2Ray ecosystem | Independent branch developed from the V2Ray foundation |
| Base configuration | Uses JSON to describe inbounds, outbounds, DNS, and routing | Retains a similar structure while adding its own extension fields |
| Common protocols | VMess, VLESS, SOCKS, HTTP, and more | VMess and VLESS, with a focus on combinations such as XTLS Vision and REALITY |
| How to choose | The subscription explicitly requires V2Fly, or the existing configuration runs reliably on that core | Nodes include Xray extension fields, or explicitly require Xray Core |
| Compatibility limits | Cannot directly execute parameters implemented only by Xray | Can read many existing structures, but behavior is not guaranteed to match V2Fly field by field |
Bottom line: identify the core from the node fields
When a subscription contains security=reality, flow=xtls-rprx-vision, a server public key, or a short ID, prefer Xray Core. If it contains only common fields such as VMess, WebSocket, and TLS, choose based on the existing client and server documentation.
Judge the version in the context of the specific failure. If a node works on a newer version but an older version reports “unsupported security” or “unknown field,” the configuration likely contains fields that the older core does not implement. Do not simply replace the client interface; also check the Core name and version recorded in the startup log.
v2rayN, v2rayNG, and v2flyNG: which core does each use?
All three are client shells, not protocols. v2rayN targets the Windows desktop and manages subscription groups, server lists, routing rules, system proxy settings, and core processes. v2rayNG and v2flyNG target Android devices; their most visible difference is the default core path.
The versions below illustrate how to inspect the interface and logs, not a version limit: the test records use v2rayN 7.12.5, v2rayNG 1.10.16, and v2flyNG 1.10.13. Later releases may change menu labels, but the separation between client-managed configuration and core-executed connections remains the same.
| Client | Platform | Core relationship | Best suited for |
|---|---|---|---|
| v2rayN | Windows desktop client | Typically uses Xray Core and can manage core types in supported packages | Subscription groups, batch testing, system proxy controls, and granular routing |
| v2rayNG | Android client | Uses the Xray Core path | Nodes containing VLESS, XTLS Vision, or REALITY parameters |
| v2flyNG | Android client | Uses the V2Fly Core path | Subscriptions explicitly adapted for V2Fly, or verified V2Fly configurations that must be reused |
- Similar names do not mean identical cores: v2rayNG and v2flyNG may have similar interfaces, but each core determines how extension protocol fields are handled.
- Successful import does not mean a connection will work: the client may parse a link into a node card, while the core can still fail to start because it does not support the protocol, transport, or authentication parameters.
- A successful latency test does not prove correct routing: a latency check only shows that one probe path responded; system proxy settings, DNS, and split-routing rules still require separate checks.
- The same port does not mean the same node:
10808and10809are usually local listening ports; the common remote port443is part of the server connection parameters.
Confirm the active core in the client
Before troubleshooting, create a reproducible record: note the client version, Core name, Core version, node protocol, local port, and first error in the log. “It won’t connect” alone cannot distinguish an expired subscription, an incompatible core, a port conflict, a DNS problem, or a server-side rejection.
v2rayN exposes the Core type in its menus; on Android, confirm it through the app information and runtime logs. Stop the current connection before switching cores to prevent an old process from occupying 127.0.0.1:10808 and causing the new core to fail to bind.
Record the version
Open the client’s “About” or version information page and record the client version. Then find the Xray Core or V2Fly Core version line near the beginning of the runtime log.
Check the type
In v2rayN, open “Settings” → “Parameter Settings” → “Core Type” and confirm that the Core for the target node is selected.
Verify the protocol
Edit the node and check the address, remote port, user identifier, transport, TLS, SNI, and Flow. For REALITY nodes, also verify the public key, short ID, and fingerprint fields.
Restart the core
Save the settings, stop the service, and start the core again. Confirm that the log contains no
address already in use,unknown field, or authentication errors.Verify the exit
Enable the system proxy and visit the target site, then check the connection log to confirm that the expected outbound tag was used. With split routing, also verify that direct and proxy rules do not override one another.
If the menu offers no Core type switch, do not copy a core file from another platform over the client directory. Use v2rayNG and v2flyNG according to their respective core paths. If you need to switch paths, first export or retain the subscription URL, then install the matching client and import it again.
Configuration compatibility does not mean identical protocol support
V2Fly Core and Xray Core both use structured configurations to describe connections, so common fields such as inbounds, outbounds, routing, and dns look similar. This makes basic configuration migration easier, but compatibility is determined by the meaning of fields inside each protocol object and the transport combination actually enabled by the server.
Take VLESS as an example: the protocol name alone is not enough. Check whether the transport is TCP, WebSocket, or gRPC; whether the security layer is TLS or REALITY; and whether Flow is xtls-rprx-vision. Two nodes can both say VLESS while requiring completely different core capabilities.
| Subscription or log clue | Layer to inspect | Action |
|---|---|---|
vmess:// |
VMess user information and transport | Verify the user identifier, remote port, Host, Path, and TLS settings |
vless:// |
VLESS encryption, security layer, and Flow | Check whether Vision or REALITY parameters are also present |
security=reality |
Xray extensions | Use Xray Core and verify the public key, SNI, short ID, and fingerprint |
unknown field |
Configuration structure or core version | Confirm the import target and Core type; do not delete unknown fields blindly |
address already in use |
Local listening port | Close duplicate processes and check whether 10808 and 10809 are occupied |
Bottom line: validate handshake parameters before testing speed
Latency figures are meaningless for client selection when the core does not support the node’s security layer. First let the log complete protocol initialization and the handshake, then compare real-connection latency, packet loss, and routing results.
Routing rules also differ in implementation details. Basic matching by domain, IP, port, and inbound tag usually migrates easily, but complex DNS splitting, rule-set loading, and specific outbound parameters should be checked against the target core’s documentation. After migration, test at least one proxied domain, one directly connected domain, and one DNS query; do not rely only on the client status bar saying “Connected.”
Common misconceptions and practical fixes
The most common mistake is not confusing one project name with another, but treating a successful client import as proof of complete core support. The subscription carries parameters, the client parses and displays them, and the core executes them; losing fields at any layer can make the final connection fail.
The subscription says V2Ray—which client should you choose?
Do not rely on the subscription name alone. Open the node details and check the protocol and security layer first. If it contains REALITY or xtls-rprx-vision, use v2rayN with Xray Core on Windows and v2rayNG on Android.
Do VMess nodes require V2Fly?
No. Both V2Fly Core and Xray Core can handle common VMess configurations. Continue by checking the transport, TLS, Host, Path, user identifier, and server requirements, then choose a client that is well maintained on your platform.
Can v2rayNG switch directly to V2Fly Core?
Do not replace the core manually inside the app directory. For the V2Fly path, use v2flyNG, import the subscription again, check the node fields, and confirm from the runtime log that V2Fly Core actually started.
Why does the port fail after switching cores?
First stop the old core and any duplicate client processes, then check whether 10808 or 10809 is still occupied locally. After changing the listening port, update the browser or system proxy settings as well.
Imported successfully, but the REALITY node will not connect?
Confirm that Xray Core is in use, then check the server address, port, user identifier, SNI, public key, short ID, fingerprint, and xtls-rprx-vision one by one. Any missing field can cause the handshake to fail.
Choose by platform and node protocol
You do not need to study the entire project history before choosing. Follow a fixed order: check the device platform, then the subscription protocol and extension fields, and finally whether you need desktop routing, batch latency tests, or a persistent Android connection. Project history explains the differences; node parameters determine the practical choice.
- Windows desktop: Choose v2rayN. After importing the subscription, open “Settings” → “Parameter Settings” → “Core Type”; use Xray Core for REALITY and XTLS Vision nodes.
- Android with Xray-based subscriptions: Choose v2rayNG and pay close attention to VLESS, REALITY, SNI, the public key, short ID, and Flow.
- Android with explicit V2Fly support: Choose v2flyNG, keep the node fields consistent with the server documentation, and do not apply Xray-specific parameters.
- VMess or standard VLESS only: Either core path may work. Prefer a combination already verified to connect, then use the logs to decide whether to switch.
- Handwritten JSON configuration: Back up the original configuration before migrating, check the inbound, outbound, DNS, and routing fields individually, and do not treat “the file loads” as proof of compatibility.