Project V is the broader project ecosystem. V2Fly and Xray represent separate core development paths, while v2rayN, v2rayNG and v2flyNG are graphical clients for managing configs and running a core. This guide is for users importing subscriptions across devices or checking VLESS and REALITY support: understand the naming first, verify node settings and core capabilities, then choose a client.
How Project V, V2Ray and the two core branches fit together
Project V began as a set of modular network proxy tools, with V2Ray becoming its best-known software. In early documentation, “V2Ray” sometimes referred to the project as a whole and sometimes to the core program that handles network connections. When troubleshooting today, identify the specific implementation and version. “Supports V2Ray” alone doesn't tell you which configs are supported.
V2Fly is a community project that continues V2Ray development; “V2Ray core” and “v2fly core” usually refer to this branch. Xray-core branched from the V2Ray codebase and has since developed its own features and release cycle. The projects share a history, but that doesn't mean their newer features, config fields or defaults are always the same.
- Project ecosystem: Project V describes the origins of the ecosystem; it isn't the name of a connection button on your phone.
- Core programs: V2Ray maintained by V2Fly and Xray-core handle runtime logic such as protocols, transport, DNS and routing.
- Graphical clients: v2rayN, v2rayNG and v2flyNG import subscriptions, edit settings, manage processes and provide system integration.
- Connection settings: Server address, port, user ID, transport and security options. These are separate from all of the projects listed above.
So “v2rayNG is installed” and “the Xray core is running” can both be true. The first identifies the interface; the second identifies the program handling the connection. When reporting an error, include both the client and core versions. The app name alone often isn't enough to tell whether a config field is supported.
Which core does each client manage?
v2rayN is for desktop platforms, while v2rayNG and v2flyNG are for Android. The capitalization in these names matters: v2rayN and v2rayNG are different apps, and v2flyNG isn't v2rayNG with a different interface. Choose based on your platform first, then check which core the client uses.
| Client | Platform | Core | What to check |
|---|---|---|---|
| v2rayN | Windows, macOS and Linux desktop | A desktop config manager with support for multiple cores; the core in use depends on the version, config and core settings. | The core used by the active config, components included in the installer, and the system proxy or TUN integration method. |
| v2rayNG | Android | Uses the Xray core. | Xray features required by the node, the core version bundled with the app, and VPN permission. |
| v2flyNG | Android | Uses the V2Ray core maintained by V2Fly. | Whether the core version supports the node settings, especially extension fields from another branch. |
The name v2rayN doesn't mean it can only use the V2Fly core. Likewise, desktop support for choosing a core doesn't mean an Android client can replace its bundled core by importing a file. Installers, graphical interfaces and core programs each have their own version boundaries.
v2rayNG: the Xray path on Android
RecommendedIf a node explicitly requires Xray features such as VLESS, REALITY or Vision, start by checking this combination. This recommendation applies to those node requirements; it doesn't mean you'll get faster speeds on every network.
Best for: Android users whose server documentation specifies Xray settings.
v2flyNG: the V2Fly path on Android
A good fit for environments configured according to V2Fly documentation. Common combinations such as VMess, WebSocket and TLS still depend on the specific versions and settings; protocol names alone don't guarantee compatibility.
Best for: Existing V2Fly configs that don't rely on Xray-specific extensions.
v2rayN: desktop config and core management
Manage subscriptions and routing in one place on desktop. When moving a node, check which core the active config uses instead of assuming it works just because it appears in the list.
Best for: Windows, macOS or Linux desktops where you need to manage the system proxy and local listeners.
VMess, VLESS, WebSocket and REALITY operate at different layers
A single node config often includes several of these terms. “VLESS + WebSocket + TLS,” for example, isn't a choice among three protocol buttons; it's a combination of an authentication and proxy protocol, a transport method and a security layer. Leaving out any layer during import can result in a node that appears in the list but fails to complete the handshake.
| Layer | Common names or fields | What to check |
|---|---|---|
| Proxy protocol and identity | VMess、VLESS、UUID | The protocol must match the server. VLESS doesn't encrypt payloads on its own; assess security together with the security layer in use. |
| Transport | TCP、WebSocket、gRPC | The transport type and its associated settings, such as WebSocket path, Host or gRPC serviceName. |
| Connection security | TLS、REALITY、serverName | The name and security settings required by the server; REALITY isn't a general-purpose transport type. |
| Flow control and extensions | flow、xtls-rprx-vision | Whether the core supports the specified value and whether it's valid for the current transport combination. |
The name VLESS alone doesn't prove that a config is Xray-only; what matters is which extensions it uses. VLESS + REALITY has different requirements from a basic VLESS config. In v2flyNG, changing the security type to TLS isn't an equivalent migration. If the server doesn't offer a matching TLS endpoint, changing the client settings won't make the config compatible.
Bottom line: choose a core based on the complete settings
Open the node editor and note the protocol, transport, security type and flow. If you see REALITY or xtls-rprx-vision, check the requirements for the corresponding Xray version. Don't choose a client based on the word “VLESS” alone.
Can share links, subscriptions and full configs be used across clients?
Successful import only shows that a client recognized the input format; it doesn't prove that the target core supports every field. When migrating, distinguish between a single share link, subscription content and a full JSON config: each carries different information.
- Single share link: Usually describes one outbound connection. VMess share links often contain Base64-encoded data; VLESS links commonly use URI query parameters for transport and security settings. After importing, reopen the editor and confirm that no critical settings are missing.
- Subscription URL: Points to a collection of configs. The server may return multiple Base64-encoded share links or different content depending on the client. Using the same URL on both clients doesn't guarantee identical entries or fields.
- Full JSON: May include inbounds, outbounds, DNS, routing, logs and tags. Even when two cores use a field with the same top-level name, its meaning, accepted values and version requirements may differ. Don't overwrite a running config without checking compatibility.
For example, loading a full JSON config with Xray-specific security fields in a V2Fly environment may fail immediately with an unsupported-config error, or cause problems only when connecting. A safer approach is to migrate one node first, keep the target client's own inbound and routing settings, and move other features over one at a time after confirming the connection works.
Set up one subscription for desktop and Android
For use across devices, start with the same source of nodes, then configure access separately on each device. v2rayN's system proxy mainly serves apps that follow system proxy settings; v2rayNG and v2flyNG typically route traffic through Android's VPN service. That's a difference in system interfaces, not core quality.
Setup plan: share the node source, configure system access separately
Desktop: v2rayN
- Go to “Subscription Group” → “Subscription Group Settings” to add the URL, then use the “Subscription Group” menu to update it. Labels may vary by version.
- Select a node, check which core it uses and verify its security settings, then connect.
- For browser traffic, choose “Set system proxy.” Check proxy environment variables separately for terminal apps.
Android: v2rayNG or v2flyNG
- In v2rayNG, for example, open “Subscription Group Settings” from the sidebar to add the URL, then return to the main screen and select “Update subscription.”
- Check the imported node's transport, security type and flow, select it, then tap the connect button.
- Approve the Android VPN permission the first time you connect. To proxy selected apps only, configure them individually from the app list on your device.
Sharing a subscription avoids entering nodes twice; update timing, routing, DNS and app access still need to be checked on each device.
When troubleshooting local access, distinguish the server port from the local listening port. The server port is the remote service entry point; the local port is where a browser or terminal connects to the proxy on your device. The sample values below illustrate the connection flow and aren't universal defaults for these three clients.
If your HTTP listener is set to 127.0.0.1:10809, a terminal can't use another machine's SOCKS port. In v2rayN, check the local listener options under “Settings” → “Parameter Settings.” Some versions offer a mixed listener that can share one port for HTTP and SOCKS. Check the current interface and runtime logs.
- First, confirm the core is running: Check the logs for config loading failures, port conflicts and other errors.
- Next, confirm app access: Check whether the desktop browser uses the system proxy or Android has an active VPN connection.
- Finally, check routing: Confirm that the request is assigned to the intended outbound. A “direct” rule won't switch to proxy just because you changed nodes.
Four common questions about choosing and migrating clients
Clients, cores and node settings each have their own boundaries. Here are checks for common issues, so you don't assume every connection failure is caused by an “incompatible core.”
v2rayN and v2rayNG have similar names. Can I copy the entire config folder between them?
Config folders aren't a cross-platform migration format. Export a single share link from the source client, then import it in the target client using an option such as “Import from clipboard.” You can also add the subscription URL again. Reconfigure local ports, system proxy and per-app settings on the target device.
The same subscription works in v2rayNG but fails in v2flyNG. What should I check first?
Open the same node in each client's editor and compare the protocol, transport, security type and flow. If the config includes REALITY or xtls-rprx-vision, don't remove fields just to force it to save. Use an Xray environment that supports the combination, or ask your service provider for separate connection settings compatible with V2Fly.
After switching cores, the latency test passes but web pages won't load. What should I do?
First, check what the test measures: a TCP connection test usually only shows that the target port is reachable, not that a full proxy request works. Then check whether the browser uses the local proxy, whether routing selects the right outbound, and whether the logs show handshake or DNS errors. Don't keep updating the subscription instead of troubleshooting each layer.
Does updating the client guarantee support for new server features?
No. Check the client and core versions in “About” or the startup logs, then see whether the editor can save the new fields. The graphical interface must recognize the settings, and the runtime core must implement them. Updating only one layer can still result in missing fields or a config load failure.
Narrow your choice down to three questions: Which operating system does the device run? What complete settings combination does the node require? Can the current version represent and run those settings? If your connection already works, there's no need to migrate just because the branch names differ. If you do need to migrate, keep the original config, test one node, then move on to subscriptions, DNS and routing rules.