Project V is the name of the broader project, V2Ray is its core software, V2Fly and Xray represent separate community-led development paths, and clients such as v2rayN provide graphical controls for those cores. New to subscriptions and core selection? Start by understanding what each layer does, choose a client based on your server settings, then check the logs to confirm the configuration is working.
Four layers to know: project, core, protocol, and client
A search for “V2Ray download” can turn up Project V, V2Fly, Xray, and v2rayN. These names refer to different layers. Project V began as a collection of modular network proxy tools, with V2Ray handling connections as its core software. In everyday use, “V2Ray” is also used as an umbrella term for the related ecosystem, which can blur the distinction between the project, protocols, and desktop apps.
| Layer | Examples | What it does |
|---|---|---|
| Project and community | Project V、V2Fly | Develop and maintain documentation, core software, and related components. |
| Core engine | V2Ray maintained by V2Fly; Xray-core | Reads configuration and handles inbound connections, routing, DNS, and outbound connections. |
| Proxy protocol | VMess、VLESS | Defines how the client and server communicate through a proxy. |
| GUI client | v2rayN、v2rayNG、v2flyNG | Manages servers and subscriptions, generates configuration, starts the core, and displays logs. |
For example, when you click the subscription update button in v2rayN, the GUI client fetches and parses the data. When a VMess connection is established, the core implements the protocol according to the configuration. Seeing a server in the interface does not guarantee that the selected core can run it. Check the protocol, transport, security layer, and whether the client generated the required fields correctly.
- A subscription is not a core: It distributes server details; the subscription URL alone does not tell you which core to use.
- A protocol is not a transport: VMess and VLESS are different configuration dimensions from TCP and WebSocket, so they are not interchangeable.
- A client is not a server: Changing software on your device does not automatically change the remote server’s listening port, user ID, or security settings.
From Project V to V2Fly and Xray: a brief timeline
The point of this history is not to memorize version numbers, but to understand why different maintainers can affect compatibility today. Early shared code and configuration concepts made the projects look similar. As each added features, however, they became less interchangeable.
- Around 2015: V2Ray takes shape. Project V builds around modular proxy capabilities, organizing configuration around inbound and outbound connections and routing. VMess becomes a widely used protocol in the ecosystem, while GUI clients make it easier to get started without writing configuration by hand.
- 2020: The V2Fly community takes over maintenance. After the original project’s maintenance changed hands, the community continued development of the V2Ray core, documentation, and related tools. “V2Fly” identifies the maintaining community; it is not a new name for VMess or a separate desktop app you must install.
- Late 2020: Xray becomes an independent branch. Building on related code, Xray develops its own core and maintenance path. It retains many concepts shared with V2Ray, while developing its own feature implementations, configuration support, and release cadence.
- Later: Clients support different cores. Desktop and Android clients continue to improve subscription management, routing rules, and status reporting. Their menus may look alike, but supported servers depend on both what the client can generate and what the core implements.
V2Fly and Xray: shared concepts don’t mean shared configurations
Both projects handle inbound and outbound connections, routing, and DNS, but having similar modules only means their architectures share concepts. VMess is commonly supported by both; VLESS is not a simple dividing line where only Xray provides support. For a VLESS server, check whether it uses REALITY, a specific flow, or other implementation-dependent settings.
REALITY is a security-layer feature, not a proxy protocol on the same level as VMess or VLESS. For a “VLESS + REALITY” setup, choose an Xray option that explicitly supports the combination, then verify the public key, server name, short ID, flow, and other settings supplied by the server. Switching the node type to VLESS alone won’t provide what’s missing.
| What to check | How to verify | Common pitfall |
|---|---|---|
| Standard VMess server | Check the address, port, user ID, transport, and TLS settings, then verify support in the selected core. | Blaming every connection failure on the core branch. |
| VLESS with REALITY | Use an Xray build that supports the combination and enter all settings provided by the server. | Assuming a successful import means the core supports it. |
| Full JSON configuration | Confirm the target core, configuration format, and field definitions; validate the configuration first. | Assuming similarly named fields are fully compatible. |
| Routing and DNS | Check rule order, outbound tags, and whether the referenced data files exist. | Copying rules without the outbounds and resources they depend on. |
Bottom line: choose a core based on server features
List the server’s protocol, transport, security layer, and flow, then match them to a client and core. Don’t replace a working, compatible configuration just because another project releases updates faster.
Three GUI clients: choose by platform and core
v2rayN is a desktop client with controls for subscriptions, server selection, routing, and system proxy settings. It’s not simply “a GUI for V2Fly”: the core it runs depends on the client version, configuration type, and selected server. When troubleshooting, record the client and core versions separately; the app name alone isn’t enough.
v2rayN: desktop client
RecommendedManage servers, check logs, and adjust routing on Windows, macOS, and Linux desktops. This article recommends it as a starting point for desktop use; it does not replace Android clients. Check the download page for installers that match your operating system and architecture.
Best for: everyday desktop use, subscription management, and split-routing troubleshooting.
v2rayNG: Android with Xray
An Android client that uses the Xray core to handle connections. If you need Xray-specific features, check both the client version and the bundled core version; an older package may not support newer features.
Best for: Android devices and servers that require Xray-specific protocol combinations.
v2flyNG: Android with V2Fly
An Android client that uses the V2Ray core maintained by V2Fly. If your servers and configuration are already set up for V2Fly, you can continue with this option. Check feature support before using specific extensions or parameters.
Best for: Android devices and configurations built around the V2Fly core.
On Android, the system VPN interface routes device traffic through the local proxy; it is not a protocol used by the remote server. Approving the VPN permission only enables local traffic routing. Whether the remote server works still depends on its settings, network reachability, and core logs.
Check the interface, core, and network with a single configuration test
The steps below follow the menus commonly found in v2rayN. Menu locations may differ between desktop versions. If your version doesn’t show a core option, use the available settings and runtime logs instead of looking for a switch that may have moved. Change one thing at a time so you can identify what made a difference.
-
Record the versions
Go to Help → About and note the client version, then find the core name and version in the core startup log. Keep the two records separate so you can tell whether a problem comes from the interface parsing the configuration or the core running it.
-
Check the core
Go to Settings → Parameter Settings → Core Type to check the core mapping for the current configuration. If the menu uses a different label or the option isn’t available, check the runtime log to see which core actually started—don’t guess from the installation folder.
-
Update the subscription
Check the subscription URL under Subscription Group → Subscription Group Settings, then update it from the Subscription Group menu. Afterward, open the target server’s edit window and check its address, port, protocol, transport, and security layer.
-
Confirm how traffic is routed
Check the local listening port under Settings → Parameter Settings, then check the System Proxy status at the bottom of the main window. Test with a browser that follows the system proxy, and avoid changing TUN mode and routing rules at the same time.
-
Check the runtime log
Try connecting and check whether the log shows the connection and its outbound route. If the core reports a field error on startup, fix the configuration first. If it starts normally but the connection times out, check the remote address, port, and network conditions.
Ports make the distinction between these layers easy to see. The three examples below illustrate what ports are used for; they aren’t universal defaults or results from a live network test.
The local 127.0.0.1:10808 and the remote server’s 443 don’t need to match. The browser sends traffic to the local listener, and the core connects to the remote server according to the node configuration. A mixed listener may accept more than one proxy protocol on a single local port. Don’t copy an old guide and add an HTTP port that isn’t actually listening.
Ecosystem FAQs: switching cores, subscriptions, and configurations
If I have v2rayN, do I need to install another V2Ray GUI?
No. You don’t need another interface for the same task. Start v2rayN and check the logs to confirm that it starts the required core. If it reports a missing core file, choose a package with the required components based on the download page or guide. Don’t rename an arbitrary core executable and use it as a substitute.
Can I use the same subscription in v2rayNG and v2flyNG?
You can try importing the same subscription, but check support for each type of server. Keep the original client installed, then test one server with clearly documented settings. If it uses a configuration that depends on Xray, such as REALITY, don’t expect it to work unchanged with the V2Fly route.
Why can’t I connect after a successful subscription update?
A successful update only confirms that the data was fetched and parsed. Open the server’s edit window and check its address, port, user ID, and TLS server name, then review the core log. If there’s no connection entry, check the system proxy or traffic routing first. If a connection appears but fails, troubleshoot the remote server based on the error.
Can I copy routing JSON from the web as-is?
Back up your current configuration first, then check the target core and configuration format. Verify outbound tags, rule order, and any referenced data files. Copy one test rule and confirm it matches before adding more gradually; don’t overwrite the entire configuration.
Think of Project V as the broader ecosystem, V2Fly and Xray as separate core maintenance paths, and the three clients as different ways to manage them on different platforms. When troubleshooting, include the client version, core version, server configuration, and stage where the error occurs. That’s more useful than saying “V2Ray doesn’t work.” Before sharing logs, remove subscription URLs, user IDs, and other access credentials.