If client names, core names, and protocol names are getting mixed up, start with these three layers: Project V is the origin; V2Fly and Xray are independently developed core projects; and v2rayN, v2rayNG, and v2flyNG are graphical clients. After reading, you’ll be able to choose a tool based on your device, node requirements, and core support—not just the word “v2ray” in its name.
From Project V to two core projects
Project V was an early open-source project built around V2Ray. V2Ray originally provided proxying, routing, and transport through a core program and configuration files; a graphical interface was not part of the core itself. The V2Fly community later continued V2Ray’s development and maintenance, making V2Fly a key name associated with this community-maintained branch.
Xray developed independently under a different group of maintainers, building on related code. It shares historical roots with V2Fly, but the two projects have since released and maintained their features separately. Calling Xray “the new version of V2Fly” can lead to the wrong choice: check each core’s configuration options, feature development, and compatibility against your needs.
Xray core
RecommendedDeveloped independently. If you need Xray features such as REALITY, confirm that the client actually launches Xray.
Best for: everyday configurations where nodes explicitly require Xray features
V2Fly core
Maintained along the V2Fly community path as the V2Ray core. Check node parameters and feature support in the relevant version before use.
Best for: nodes and configurations supported by V2Fly
Here, “fork” describes how the projects evolved; it doesn’t mean the two programs can never connect to the same type of server. VMess, for example, is a protocol—not a marker exclusive to any one client. A protocol still has specific parameters, including transport and security settings. Conversely, a client’s ability to import a link doesn’t prove that its current core supports every option in that link.
What do the GUI client and core each do?
The GUI client displays server lists, saves subscriptions, selects active nodes, configures the system proxy, and shows logs. The core uses the configuration to establish connections, handle inbound traffic, and apply outbound and routing rules. When troubleshooting, first identify the layer where the problem occurs: if no servers appear in the interface, check the import or subscription; if a server is selected but the connection fails, check the core, node parameters, and logs.
| Name | Role | Core relationship | Maintenance |
|---|---|---|---|
| v2rayN | Desktop GUI client | Available cores depend on the client version and installed components; the name alone doesn’t tell you which core is currently in use | The client project is maintained independently; the selected core has its own maintainers |
| v2rayNG | Android GUI client | Uses the Xray core line | The client and Xray core are maintained separately |
| v2flyNG | Android GUI client | Uses the V2Fly core line | The client and V2Fly core are maintained separately |
One detail that’s easy to miss: client updates and core updates are separate. The app version shown in the GUI doesn’t necessarily tell you what the current core supports. If you’ve changed cores on desktop or carried over an older configuration, check the actual Core type in settings, then use the logs to confirm which core launched.
Check which core v2rayN is actually using
v2rayN puts server management and core selection in one desktop interface. Before choosing a core, check whether the node configuration has specific requirements. For example, a server configured for VLESS with REALITY needs a core and version that support those features. For a standard VMess node, check the address, port, user ID, transport, and security settings individually instead of guessing based on the protocol name.
Check the node requirements
Open the server editor and note the “Protocol,” “Address,” “Port,” and transport and security fields. If the server documentation explicitly requires Xray features, check that requirement along with the node parameters.
Check the core settings
In versions of v2rayN that offer this setting, open “Settings” → “Parameter Settings” → “Core Type” and check the current selection. If the menu changes between versions, use the core setting shown in your version.
Apply the setting and reconnect
Save the setting, select the server again, and reconnect. After changing the Core type, don’t rely only on the latency shown in the list; confirm that the core restarted and that the system proxy is in the expected state.
Check the logs
Review the client logs for startup messages and errors. If a configuration field is unsupported, return to the node editor and check the protocol and transport parameters. Don’t mask a core configuration error by repeatedly switching system proxy modes.
The local listening port is another useful troubleshooting clue. Some configurations use 10808 as the local SOCKS port, but it isn’t a fixed requirement for every setup. If you need to enter a proxy address manually in a browser or another app, check v2rayN’s current local proxy settings instead of copying someone else’s 10808. If another program is already using the port, the logs are usually more informative than a browser’s connection error.
Bottom line: trust the core’s startup status
After choosing a Core type, first confirm in the logs that the core started successfully, then test the target website. If the core didn’t start, neither a speed test result nor the system proxy toggle proves that the node configuration is correct.
v2rayNG or v2flyNG for Android?
Both are Android GUI clients, but they follow different core lines. v2rayNG is associated with Xray, while v2flyNG is associated with V2Fly; they aren’t the same app under different names. Choose based first on which core supports the server’s protocol, transport, and security parameters, then on the import and day-to-day management features you need.
There are at least two checks between importing a subscription and connecting successfully. First, can the client recognize the server entries in the subscription? Second, can the core connect using each entry’s full set of parameters? A successful subscription update only means the client retrieved and processed the list; it doesn’t prove that every node in it is reachable. When switching clients, don’t assume subscription groups, routing settings, or local rules will carry over automatically.
- Node requires REALITY: Check the complete parameters provided by the server, then choose a client that follows the Xray core line. Don’t copy only the address and port.
- Need to keep an existing V2Fly configuration: First confirm that the protocol and features are supported in the target version, then import it into v2flyNG and test your commonly used nodes one by one.
- Using the same subscription on two devices: You can add the same valid subscription URL to both, but check the group names, update method, and routing policy separately in each client.
If the server entries look fine but you still can’t connect, check the selected node first, then the client’s connection logs and system proxy status. Don’t choose a core based on the subscription provider. Compatibility depends on the protocol, transport, and security parameters used by each node, and whether the current core supports them.
Common mix-ups: projects, protocols, and maintainers
Project history answers “Where did the code come from?” Maintenance tells you “Who updates the client and core?” Protocols and configuration answer “What does this node need?” These are separate questions. Knowing that Xray comes from the same ecosystem doesn’t mean every V2Fly configuration can use Xray-specific fields. And knowing v2rayN is a GUI client doesn’t mean it launches the same core on every computer.
Does v2rayN only work with V2Fly because “v2ray” is in its name?
No. Go to “Settings” → “Parameter Settings” → “Core Type” to check the available options and current selection. The client version and installed core components determine which options are available.
Why can’t I connect even though the subscription imported successfully?
Open the server editor and check the protocol, address, port, user ID, transport, and security fields one by one. Then check the specific error in the logs. A successful import doesn’t mean the core supports every parameter.
Do I need to change my servers when switching from v2rayNG to v2flyNG?
Don’t change the server first. Check whether the target core supports the features used by the existing node, then import the configuration into the new client and test it. If the node depends on a core-specific feature, changing the client name alone won’t migrate it.
Are VMess and VLESS the names of two clients?
No. They’re node protocols. Keep client names, core names, and node protocols distinct, and check the transport and security settings in addition to the protocol when editing a server.
Will routing rules adapt automatically after switching cores?
Don’t assume they will. Check the routing configuration generated or used by the current client, then test destinations that should connect directly and those that should use the proxy. If a configuration parsing error appears, use the logs to identify the field causing it.
When organizing your configuration, keep a short record of the client on each device, the current core, node protocol, transport, and any special security settings. That’s more useful than simply noting “V2Ray node.” If something breaks, use the record to rule out version and parameter mismatches first, then check the network, subscription validity, and routing rules. This makes troubleshooting much more focused.