Project V refers to the ecosystem and ideas surrounding V2Ray, while V2Fly and Xray maintain their own cores and related components. v2rayN, v2rayNG, and v2flyNG are GUI clients for importing configurations, switching nodes, and managing proxy scope. Choose by operating system first, then check the protocols, transports, security layers, and client features in the subscription. Do not decide based only on whether the name contains “V2Ray.”
First separate the ecosystem, core, and GUI client
Project V commonly refers to the project vision and technical ecosystem built around V2Ray, not a Windows application that can simply be launched by double-clicking. Over time, the V2Fly community continued maintaining v2ray-core and related documentation, while Xray developed its own independently evolving Xray-core. They share technical roots, but their release cycles, configuration capabilities, and protocol extensions are not fully synchronized.
The proxy core parses configuration, establishes outbound connections, applies DNS and routing rules, and exposes local SOCKS, HTTP, or mixed listening ports. The GUI client sits above the core and handles subscription management, node editing, core startup, system proxy switching, and log display. When the client shows “Started,” it only means the local process has entered its run state; it does not mean every application is using the proxy.
Proxy configuration is a third layer. VMess, VLESS, server names, transports, TLS parameters, and routing rules are all configuration data. Importing different configurations into the same client can produce very different capabilities; placing the same subscription into different cores can also produce different results depending on field support.
| Layer | Common names | Primary responsibility | What this does not tell you |
|---|---|---|---|
| Project ecosystem | Project V、V2Fly、Xray | Sets technical direction, develops cores, and maintains specification documents | Whether a device is actually using the proxy |
| Proxy core | v2ray-core、Xray-core | Handles protocols, connections, DNS, and routing | It is not the same as a subscription management interface |
| GUI client | v2rayN、v2rayNG、v2flyNG | Manages configurations, invokes the core, and switches proxy modes | Similar names do not guarantee identical features |
| Proxy configuration | Subscriptions, individual nodes, and routing rules | Describes server parameters and traffic handling | It cannot replace the client or core at runtime |
How to understand the differences between V2Fly and Xray
V2Fly and Xray can both handle common proxy configurations, but they should not be treated as two download names for the same core. Their configuration formats have many similarities, yet specific protocol fields, transport options, and extensions must be checked against the current core documentation and client support. A subscription being importable only means the client recognized its text structure; it does not guarantee that the core can establish a connection.
If an existing subscription mainly uses common combinations such as VMess, WebSocket, and TLS, both v2ray-core and Xray-core may meet the need; the actual choice also depends on the server parameters. If the configuration clearly includes VLESS, Reality, or Xray-specific fields, first confirm that the client is using Xray-core, then check the core log for unknown fields or unsupported protocols.
Xray-core
RecommendedA good fit for configurations that need VLESS, Reality, or other Xray capabilities, while still handling common VMess configurations. After importing, check the transport, server name, and security parameters.
Best for: subscriptions that explicitly require Xray or need broad modern protocol support
v2ray-core
Maintained by the V2Fly community and suited to VMess and similar setups that follow its configuration conventions. Before choosing it, confirm that the subscription fields match the current core version.
Best for: servers that explicitly provide V2Fly configuration requirements or configurations already verified as compatible
Choosing by name alone
A client name containing v2ray does not mean it can use only one core; likewise, a subscription name does not prove the actual protocol type.
Best for: not a selection method; check node fields and core logs instead
Bottom line: check the configuration requirements before choosing a core
Listing the protocols, security layers, and transport fields in a subscription is more reliable than choosing by project name. When an import succeeds but the connection fails, first check whether the core supports the relevant fields instead of repeatedly deleting and re-importing the subscription.
Which devices are v2rayN, v2rayNG, and v2flyNG for?
v2rayN is a desktop GUI client primarily used on Windows, with desktop builds also available for macOS and Linux. It brings subscriptions, server lists, routing rules, system proxy settings, and TUN controls into one desktop interface. Windows users typically start with v2rayN, then choose the package matching their system architecture and preferred interface.
v2rayNG and v2flyNG are both Android clients, but they follow different default technical directions. v2rayNG primarily uses Xray capabilities and suits subscriptions containing VLESS or explicitly requiring Xray; v2flyNG targets v2fly-core configurations and fits cases where the server explicitly requires V2Fly compatibility. Both require permission to use Android's VPN service. That permission creates a local traffic-capture path; it does not change the server configuration itself.
Desktop and Android clients can use the same subscription, but their local proxy mechanisms differ. v2rayN can route traffic through the core using the system proxy, manually configured application proxies, or TUN. Android clients usually capture traffic through the system VPN service and can support per-app proxying. Therefore, a node working on a phone but not on a computer does not by itself prove that the node parameters are wrong.
| Client | Platform focus | Core direction | What to check first |
|---|---|---|---|
| v2rayN | Windows, macOS, and Linux desktop | Choose the available core according to the client version and settings | System architecture, core type, system proxy, and TUN |
| v2rayNG | Android | Xray-core | VPN permission, per-app proxying, and battery settings |
| v2flyNG | Android | v2ray-core | Node fields, core compatibility, and VPN permission |
Choose by protocol, transport, and feature requirements
Before choosing a client, expand one real node and record its protocol, address, port, transport, security layer, server name, and user identifier. VMess and VLESS are protocol-layer fields; TCP, WebSocket, and gRPC are transports; TLS and Reality involve the security layer and handshake parameters. These belong to different layers, so saying “this is a TLS node” is not enough to make a decision.
Next, check whether the client offers the traffic-capture method you need. When a browser can read the system proxy, enabling the system proxy on Windows is usually enough. Terminal tools, games, and applications that ignore system proxy settings may need a manually configured proxy address or TUN after the routing rules are confirmed. On Android, if only selected apps should use the proxy, check the per-app list instead of changing the server protocol.
- Choose the platform first: use v2rayN on desktop systems, then compare the core requirements when choosing between v2rayNG and v2flyNG on Android.
- Check the protocol next: record the actual protocol, such as VMess or VLESS, rather than relying on the subscription group name.
- Check the transport: verify TCP, WebSocket, or gRPC, along with the path, service name, and server name.
- Confirm the traffic scope: decide between the system proxy, a manually configured application proxy, TUN, or Android per-app proxying.
- Keep a diagnosable test case: test one node and one application first, then expand to the full subscription and other programs.
Selection checklist
Platform: Windows / macOS / Android / Linux
Client: v2rayN / v2rayNG / v2flyNG
Protocol: VMess / VLESS
Transport: TCP / WebSocket / gRPC
Security layer: TLS / Reality / according to the configuration requirements
Local access: system proxy / manual proxy / TUN / per-app proxy
Test scope: 1 node + 1 browser + 1 terminal applicationIn common v2rayN 7.x interfaces, open “Settings” → “Parameter settings” to check the core, inbound ports, and other runtime options. Menu names may vary slightly between builds, so follow the labels shown in the current interface. If the SOCKS port is set to 10808 and the HTTP port to 10809, browser extensions, terminal environments, and other manually configured proxy applications must use the corresponding ports. Changing the client's listening ports does not automatically update old ports in external applications.
Bottom line: a minimal test setup locates problems faster
Start by testing one node, one access method, and one application. Confirm that the core starts, the local port is listening, and the target application is actually using that port before adding routing rules, TUN, or more subscriptions. This prevents several variables from changing at once.
What to check after importing a subscription
A subscription distributes configuration; it is not proof that a connection will succeed. After updating a subscription, the client usually creates a server list. You still need to select an active node, start the core, and decide the scope of system proxy or VPN access. If the subscription URL opens but the list is empty, check whether the client reports a parsing failure, empty content, or an unsupported format; each requires a different response.
When troubleshooting on desktop, first confirm the local listener. Using 127.0.0.1:10808 as an example, 127.0.0.1 means local-machine access only and 10808 is the port; both must match the proxy settings in the application. If the log says the port is already in use, check whether the client was started twice or another program is using it instead of switching to a different remote node.
On Android, distinguish between “the client is connected” and “the target app is included in the proxy.” With per-app proxying enabled, list mode may mean proxy only the selected apps or exclude the selected apps. Recheck the target app's scope after switching modes. For background disconnections, check Android VPN permission, conflicts with other VPNs, and battery optimization settings.
The subscription imported successfully. Why can’t it connect?
Select one node and start the core first, then check the log for unsupported protocol fields, a mismatched server name, or a connection timeout. A successful import only means the client read the subscription content.
Should v2rayN use Xray or the v2ray core?
Open the node details and check the protocol and security fields. Choose Xray when the configuration includes VLESS, Reality, or an explicit Xray requirement; choose v2ray-core according to the server's instructions when the server explicitly requires a V2Fly configuration.
The browser works. Why isn’t the terminal connected?
The terminal application may not read the system proxy. Confirm the client's local port, then set an HTTP or SOCKS proxy separately in the terminal tool, or consider whether TUN is needed.
Can v2rayNG and v2flyNG run at the same time?
On Android, only one app can usually occupy the system VPN channel at a time. Stop the current client before starting the other one during testing, so a VPN service conflict is not mistaken for a node failure.
Do I need to buy a new subscription after switching clients?
Not necessarily. First confirm that the existing subscription allows the target client to read it and that its protocol and transport fields are supported by the target core. Client selection and the subscription service itself are separate issues.
Common misconceptions and the final selection order
The first misconception is treating “V2Ray” as the name of one specific application. In practice, it may refer to the Project V ecosystem, v2ray-core, a configuration format, or proxy clients in general. When a guide only says “open V2Ray settings,” confirm the exact client, operating system, and interface version; otherwise, the menu path may not match.
The second misconception is comparing only the client interface without checking core capabilities. The interface turns user actions into configuration; the core actually handles the protocols. A client displaying a node name does not mean the current core understands every field in that node. Unknown configuration fields, handshake failures, and routing errors in the log are more useful for diagnosis than the node color in the interface.
The third misconception is confusing the system proxy with traffic routing. The system proxy determines which applications may send traffic to the local proxy; routing rules determine which exit handles traffic that has already entered the core. If the former is not connected, a complete set of routing rules will still have no effect on that application.
- On Windows desktop, start with v2rayN, then choose the core and proxy method required by the subscription.
- On Android, choose v2rayNG when the subscription explicitly depends on Xray capabilities; choose v2flyNG when it explicitly requires the v2fly core.
- Before using a v2rayN desktop build on macOS or Linux, check the CPU architecture and package format.
- When a connection fails, check in this order: core startup, local listener, application access, remote handshake, and routing result.
- When migrating clients, keep the original configuration, test one node first, then import the full subscription and routing rules.