This guide is for anyone choosing a client, dealing with core compatibility after importing a subscription, or unsure how V2Ray, V2Fly, and Xray relate. You’ll learn how projects, cores, clients, and protocols fit together, then how to check the Core type, log version, listening ports, and actual runtime status in v2rayN.
How Project V, V2Ray, V2Fly, and Xray fit together
Project V was the early project name for the broader technology ecosystem, while V2Ray became its best-known proxy core. Many guides use the two names interchangeably. That rarely affects routine setup, but maintenance branches, configuration compatibility, and client selection require separating the project name from the specific core.
V2Ray began public development in 2015. Its core handles inbound listeners, protocol handshakes, routing, DNS queries, and outbound connections. It is not a complete desktop client with its own graphical interface. Subscription lists, latency tests, tray menus, and system-proxy controls usually come from graphical clients such as v2rayN.
Around 2020, the original ecosystem moved toward community-led maintenance, and V2Fly became the community project line continuing v2ray-core. In current documentation, V2Fly, v2fly-core, and V2Ray 5.x generally refer to this maintenance path. A name change does not immediately invalidate older configurations, but formats, modules, and supported versions continue to evolve.
Xray is another core family built on the same technical foundations. It retains many familiar configuration concepts, including inbounds, outbounds, routing, and dns, while following its own feature-development cycle. The two paths are historically related, but releases, implementation details, and available features should not be treated as equivalent.
Conclusion: identify the layer before comparing names
When you see “V2Ray,” first determine whether it means the ecosystem in general, the v2fly-core core, or a Core option inside a client. Protocol support and configuration compatibility are comparable only after the exact core and version are known.
What cores and graphical clients each do
The core is the program that actually processes network traffic. After an application sends a request to a local SOCKS or HTTP port, the core reads the destination domain or IP, chooses direct, proxied, or blocked routing, and performs the connection required by protocols such as VMess and VLESS. DNS splitting, domain sniffing, and connection logs are also handled mainly by the core.
The graphical client turns these capabilities into controls. It stores subscription URLs, converts subscription data into a node list, generates core configurations, starts or stops the core process, and changes system-proxy settings. Whether traffic continues after the window closes depends on tray settings and core-process status, not simply on whether the window is visible.
That is why client versions and core versions are separate numbers. For example, v2rayN 7.x identifies the interface version, while Xray 25.x or v2fly-core 5.x shown in the runtime log identifies the core currently in use. When troubleshooting, reporting only the client version is often not enough to determine whether configuration fields are supported.
| Layer | Primary responsibility | What you commonly see | Typical symptoms |
|---|---|---|---|
| Graphical client | Subscription management, node selection, configuration generation, and system-proxy switching | Server list, tray menu, and latency results | Subscription not updated, no node selected, or system proxy disabled |
| Proxy core | Protocol connections, traffic routing, DNS resolution, and traffic forwarding | Startup logs, listening address, and connection errors | Unsupported configuration fields, handshake failures, or an occupied port |
| Subscription data | Server address, port, user ID, and transport parameters | VMess and VLESS nodes plus group names | Missing fields, expired parameters, or fields the current core cannot recognize |
Configuration tip: “Started successfully” only means that the core process is running. Also confirm that the log shows 127.0.0.1:10808 or the actual listening port configured in the client, then check that the target app is using that port.
Which cores do v2rayN, v2rayNG, and v2flyNG use?
v2rayN is a graphical desktop client with broad configuration-management features. It can manage subscriptions, routing rules, system proxy settings, and TUN mode, while the Core type determines which core handles the selected node. Options vary across v2rayN releases, so the client name alone cannot tell you which core path is currently running.
v2rayNG is an Android client commonly distributed with the Xray core. After you import a VMess or VLESS node, it converts the sharing parameters into a runtime configuration that Xray can read. Connectivity also depends on the transport layer, security parameters, and server settings; seeing “Xray” does not guarantee compatibility with every node.
v2flyNG also targets Android, but follows the V2Fly community-core path more closely. It can be a better fit when you need to verify v2fly-core behavior, use its configuration capabilities, or keep the mobile and server sides within the same core family. The two Android clients work similarly at the interface level, but their implementations and feature-update pace must be assessed separately.
| Client | Platform | Typical core relationship | Best suited for |
|---|---|---|---|
| v2rayN | Desktop | Choose Xray or v2fly Core in supported versions | Subscription management, complex routing, system proxy, and TUN |
| v2rayNG | Android | Primarily based on the Xray core | Using Xray features and common sharing links |
| v2flyNG | Android | Follows the v2fly core path | Keeping V2Fly configuration and runtime behavior consistent |
- A single subscription can contain nodes using multiple protocols; the client name is not the subscription protocol name.
- The same VMess node may be supported by both core paths, but transport parameters and edge-case fields can still differ.
- VLESS is only a protocol identifier. You must also verify the transport method, security settings, server version, and client-core capabilities.
- Routing rules are local configuration. After switching clients, custom direct and block rules from the old client usually need to be imported or rebuilt.
Conclusion: choose a client by configuration capabilities
Use v2rayN when you need to switch cores and maintain complex rules on desktop. On Android, choose v2rayNG for an Xray-oriented setup, or v2flyNG when you specifically need v2fly core behavior.
Check and switch the Core type in v2rayN
Before switching cores, record the nodes and routing settings that currently work, then inspect the client log. The beginning of the log usually lists the core name, version, and configuration-load result. If it only reports a failed port bind, first stop the old process occupying 10808 or 10809 instead of repeatedly switching protocols and obscuring the real cause.
The steps below use the v2rayN 7.x settings layout as an example. Minor releases may move labels, but the order remains the same: confirm the Core type, reconnect, and verify the core that actually started through the log. Changing the dropdown without reconnecting may leave the old core process handling traffic.
Stop the current connection
Stop the active core from the v2rayN main window and wait for the status bar to change from running to stopped, so the old process no longer occupies the local port.
Open core settings
Go to “Settings” → “Parameter Settings” → “Core type” and review the core options for the current node type.
Select the target core
Choose Xray or v2fly Core for the test. If the option is unavailable, first check whether the current client version includes the corresponding core files.
Reconnect to the node
Save the settings, return to the server list, select the original node, and start it again. Do not change the protocol, routing, and DNS at the same time, or it will be difficult to identify the source of any difference.
Check the startup log
Open the log window and confirm that the core name and version have changed. Also check whether SOCKS port 10808, HTTP port 10809, or a custom port is listening successfully.
Note: The newest Core type is not always the best fit. If the subscription depends on specific fields and switching causes “unknown field,” “failed to parse config,” or outbound-creation errors, restore the previous core and check configuration support field by field.
Why protocols, subscriptions, and routing are different things
VMess and VLESS describe how a proxy connection is established between the client and server; a subscription describes how node parameters are distributed in bulk; routing describes which outbound should receive local traffic. They occupy different layers. A successful subscription update only means the client received the data—it does not mean every node can be parsed and connected by the current core.
For example, when a browser requests a domain, the request may first enter the local HTTP port 10809, then the core performs domain sniffing and a DNS lookup. If a routing rule matches direct access, the request does not use a subscription node; only a proxy match sends it through a VMess or VLESS outbound. The result still depends on the address, port, transport layer, and server configuration.
DNS is not just an auxiliary switch. If local DNS results do not match the assumptions in your routing rules, you may mistake the problem for core incompatibility. To compare V2Fly and Xray, use the same node, DNS setup, routing rules, and test target; change only the Core type in each round.
| Concept | Question answered | Typical configuration | How to verify |
|---|---|---|---|
| VMess、VLESS | Which protocol establishes the proxy connection | Address, port, user ID, transport, and security parameters | Review handshake and outbound logs |
| Subscription | How nodes are delivered to the client in bulk | Subscription URL, groups, and update policy | Check the update time and node count |
| Traffic routing | Whether a request uses direct access, a proxy, or a block | Domain rules, IP rules, and inbound tags | Review matched rules and outbound tags |
| DNS | Which resolver queries the domain | Server groups, query policy, and matching domains | Compare DNS results with core logs |
Conclusion: change one variable at a time
When comparing V2Fly and Xray, keep the node, DNS, routing, and local ports fixed. Switch only the Core type and repeat the same request to the same target. If you also update the subscription or change rules, the test cannot show which component caused the difference.
Five configuration facts to check before choosing
Most users do not need to take sides based on project history. What actually affects connectivity is whether the client generates the configuration correctly, whether the core recognizes the subscription fields, whether the server supports the same parameters, and whether local routing and DNS fit the use case. Choosing from configuration facts is more reliable than choosing by name alone.
First, check the protocol and transport parameters. After identifying a node as VMess or VLESS, verify its transport—such as TCP, WebSocket, or gRPC—and the related security settings. Second, check the core version; even older releases in the same core family may lack newer fields. Third, check the client’s conversion logic by opening the node editor after importing a sharing link and verifying the address, port, and transport parameters.
Fourth, check how local traffic is intercepted. System proxy settings affect only apps that honor them, while TUN mode uses a virtual network interface to capture more traffic. Fifth, check routing and DNS. Before testing a core, temporarily use simple rules; restore domain groups, IP rules, and custom DNS after basic connectivity works to reduce troubleshooting branches.
- Record the core name and version series in the client log, not just the graphical client version.
- Verify the server address, remote port, protocol, transport, and security parameters in the node editor.
- Confirm that the local listening address is
127.0.0.1, and record the actual SOCKS and HTTP ports. - Test the same target with direct and proxy rules separately, and check whether the outbound tags match expectations.
- When DNS resolution fails, inspect the DNS log separately instead of immediately blaming node speed or the core branch.
Testing tip: For an initial comparison, run the same task in three consecutive rounds. Record connection success, time to first response, and log errors each time. If all three rounds fail at the same step, check compatibility for that configuration field.
Common issues and practical fixes
Confusingly similar names usually cause three problems: mistaking the graphical client for the core, treating a successful subscription import as proof that nodes work, and switching the Core without checking the log. The client interface and local logs are enough for an initial diagnosis of all three.
If v2rayN is installed, does it always run V2Fly?
Not necessarily. Go to “Settings” → “Parameter Settings” → “Core type” to see the available choices, reconnect, and then confirm in the startup log whether Xray or v2fly Core is actually running.
Why do some nodes in the same subscription connect while others do not?
Open each node editor and compare the protocol, remote port, transport method, and security parameters. A subscription only distributes configurations in bulk; different nodes may depend on different core capabilities or server versions.
What should I do if switching cores reports that a port is already in use?
Stop the current core and exit any leftover processes, then check whether another program is listening on 10808 or 10809. You can also choose an unused port in Parameter Settings, save, and start again.
What if the node is connected but the browser has no traffic?
First confirm that the system proxy is enabled, then check whether the browser uses its own proxy settings. For manual setup, enter the HTTP port shown by the client for an HTTP proxy, or the corresponding SOCKS port for SOCKS5.
Should Android users choose v2rayNG or v2flyNG?
Test v2rayNG first when the subscription explicitly depends on Xray features; choose v2flyNG when you need behavior consistent with a v2fly-core environment. After importing, still verify the node fields and run an actual connection test.
In short, Project V is the entry point for understanding the ecosystem’s history; V2Fly and Xray are core families developed along different maintenance paths; and v2rayN, v2rayNG, and v2flyNG are the clients users operate directly. Start by identifying the platform and client, then check the core actually running, followed by the protocol, subscription, routing, and DNS. Once the names are clear, most compatibility issues can be traced to one setting or one log entry.