Project V provides the ecosystem context for these tools. V2Fly and Xray are independently maintained core branches, while v2rayN, v2rayNG, and v2flyNG are user-facing clients. Choose a core based on the node requirements, then pick a client for your platform. This guide covers project relationships, protocol capabilities, and configuration troubleshooting to help avoid the “subscription imported, connection incompatible” problem.
1. Project V, V2Ray, and cores explained
Project V is not a separate desktop app you need to install; it is an ecosystem of projects built around network proxy tools. V2Ray is a core project in that ecosystem. It accepts connections, applies routing rules, handles protocols, and establishes outbound connections. In everyday use, “V2Ray” can also refer more broadly to the client setup, so the term may mean the core itself—or simply a type of proxy node.
A core usually does not include a full subscription management interface. When you select a server, switch the system proxy, or edit routing rules in a client, the client turns those choices into a configuration the core can read and starts the corresponding process. Knowing where the client ends and the core begins helps you determine whether to check the UI settings or the protocol logs.
- Ecosystem and projects: Project V provides context about where these projects came from; it is not the name of a node protocol.
- Cores: V2Fly-maintained V2Ray Core and Xray Core handle connections and traffic.
- Clients: v2rayN, v2rayNG, and v2flyNG provide the interface, subscription management, and platform integration.
- Node configuration: Stores the server address, port, credentials, transport, and security settings. These must match the server.
2. V2Fly and Xray: shared roots, separate development paths
V2Fly is a community project that continues to maintain V2Ray. Around 2020, community maintenance began to take shape as the V2Fly branch familiar today. That same year, Xray developed as a fork based on V2Ray code, then continued evolving its own protocol implementations, transport options, and configuration capabilities. The projects share a history, but they are not two skins for the same program, and installing one does not automatically upgrade it to the other.
Compare specific capabilities, not just project names. VMess and VLESS are protocol names, WebSocket is a transport, TLS and REALITY relate to connection security, and XTLS Vision is an Xray flow-control option. These belong to different layers, so asking “Is VMess or REALITY better?” compares unlike things.
Xray Core
RecommendedIf a node explicitly requires a combination of VLESS, REALITY, and Vision, choose an Xray version that supports those capabilities. This recommendation is based on configuration compatibility, not a speed guarantee for every network.
Best for: Users whose server specifies Xray or whose node includes REALITY or Vision parameters.
V2Ray Core maintained by V2Fly
Suitable for setups built around the V2Ray configuration model. Whether existing VMess, WebSocket, or TLS nodes will work still depends on the core version, transport support, and server parameters. Protocol names alone are not enough to decide.
Best for: Users with a working V2Fly deployment who want to keep their existing configuration and maintenance workflow.
The name VLESS alone is not enough to distinguish between the two branches. Supporting the base protocol is not the same as supporting a specific combination: recognizing VLESS does not mean a core can handle REALITY or xtls-rprx-vision. Likewise, V2Ray v4-style configuration and the v5 configuration model should not be mixed. When you find a JSON snippet online, first check which core and configuration format it targets.
Choosing a core: check the node parameters first
If a node includes a REALITY public key, short ID, and Vision flow requirements, first confirm that the Xray version used by your client supports those fields. If your existing V2Fly configuration works, keep it as your baseline; there is no need to migrate just because a project name changed.
3. Which core does each client use?
Similar client names do not mean identical implementations. The desktop app v2rayN can manage multiple cores, depending on its version, platform, and installed components. On Android, v2rayNG uses Xray as its core, while v2flyNG uses the V2Ray core maintained by V2Fly. App and core versions have separate numbering, so track them separately when comparing capabilities.
| Client | Platform | Core relationship | Why choose it |
|---|---|---|---|
| v2rayN | Windows / macOS / Linux | Manages multiple cores; options depend on the specific version and installed cores | For desktop subscription management, system proxy, and routing configuration |
| v2rayNG | Android | Xray core | The node requires Xray capabilities, or you need to manage the corresponding configuration on Android |
| v2flyNG | Android | V2Ray core maintained by V2Fly | The node and configuration are maintained for the V2Fly branch |
In v2rayN, check both the protocol and transport fields in the node editor and the core name in the running logs. Seeing an option in the interface does not necessarily mean the selected core can use it. Conversely, even if the core supports a capability, the client must generate the configuration correctly for it to work.
- Record the full client version, then note the core name and version from the startup logs. Avoid recording only “latest.”
- Open the node editor and check the address, port, user ID, transport, and security layer. Make sure no fields were lost during import.
- Restart the connection and check whether the logs show a configuration parse error, a handshake failure, or an access problem after the connection is established.
4. Subscription compatibility does not guarantee node or configuration compatibility
A subscription link distributes node information; it is not a proxy protocol. A subscription may contain share links or use another format supported by the client. If two clients can read the same URL, that only means they accept its distribution format. Check separately whether all fields are preserved after parsing and whether each node is supported.
For example, a VLESS node might use remote port 443 and require a specific server name, public key, short ID, and xtls-rprx-vision. Even with the correct server address and user ID, leaving out one required parameter can cause the connection to fail. Port 443 does not automatically mean standard TLS; use the security type explicitly specified by the node.
Setup guide: test the same subscription on desktop and Android
Desktop: v2rayN
- Update the subscription and select a node with complete parameters as your baseline.
- Choose a core that meets the node requirements, then note its actual version in the startup logs.
- Check system proxy integration and routing rules separately. Do not enable multiple traffic-capture methods at the same time.
Android: v2rayNG or v2flyNG
- Choose a client with the capabilities the node needs, then import the subscription.
- Confirm system VPN permission and check whether per-app rules exclude the app you want to use.
- Retest with the same node, keeping local DNS and routing settings unchanged.
Sharing a subscription reduces the need to enter nodes manually, but update timing, local routing, DNS, and per-app settings are still managed independently on each device.
Do not assume a complete runtime configuration exported from desktop will work unchanged on Android. Local file paths, listening addresses, inbound ports, and traffic-capture methods can differ. When moving between devices, transfer the node information first, then configure local behavior in each platform’s interface. Subscription URLs contain access credentials, so do not include them in public screenshots or support requests.
5. Troubleshooting connection failures after switching cores
A connection failure after switching cores does not automatically mean “the new core is unstable.” The same node may have been generated with different parameters, or local entry points, system proxy settings, or DNS settings may have changed. Start with a repeatable test setup: use the same device, node, and destination URL, and change only one variable at a time.
- Check that the configuration loads. If the logs show unknown fields or a configuration parse error, check the core type and format first. Do not keep changing the server port and hoping for the best.
- Check the local listener. For example, if you explicitly set the local SOCKS entry point to
127.0.0.1:10808, the app must use that exact address. This is a troubleshooting example, not a claim about the default port in every version. - Check the remote handshake. Verify the server address, port, device time, and security settings. For Vision, check the flow field; for REALITY, check the public key and server name required by the server.
- Check how app traffic enters the proxy. A desktop system proxy affects apps that honor system proxy settings. On Android, also check the VPN connection and per-app scope.
- Check DNS and routing last. If the connection is established but some domains fail, check whether the rules route them directly or through the proxy, and distinguish local DNS resolution from resolution on the proxy side.
A latency test only reports results under specific test conditions; it cannot replace testing web pages, downloads, or long-lived connections. To compare the two core branches, repeat each test three times on the same network and record successful connections, time to first page load, and log errors. Do not use a single latency result to conclude that one core is generally faster.
6. Ecosystem FAQs
The node says “V2Ray.” Which client should I install?
First, ask the node provider about the protocol, transport, and security layer. Even with desktop v2rayN, you still need to check the core. On Android, if the node explicitly requires REALITY or Vision, choose a version of v2rayNG with the corresponding Xray support. Do not decide based only on the generic name shown on the subscription page.
v2rayN is up to date. Why does it still say the protocol parameters are unsupported?
Check the startup logs and record the client and core versions separately, then check which core the selected node uses. Updating the client interface does not necessarily replace every external core file. After confirming the core update, restart the connection and see whether the error still occurs while loading the configuration.
The same subscription works in v2rayNG but not in v2flyNG. What should I do?
Select the same node in both clients and compare the security and flow-control fields. If the node requires a specific Xray capability, use it with a compatible client. If both clients support the combination, check field parsing, device time, and VPN permission rather than deleting the entire subscription.
Will switching cores automatically improve DNS and routing?
No. Switching cores does not automatically provide rules suited to your network. Save your existing presets, then use a fixed test domain to check its matching rule and resolution path. On desktop, also follow the proxy mode guide to confirm that the app is actually using the proxy before adjusting DNS.
The final choice is straightforward: use a core that fully supports the node’s required capabilities and parameters, then choose a client for the access method your device needs. For a stable setup, make changes only to address a reproducible issue or a clear new requirement—not to treat project branch names as a performance ranking.