Project V Explained: V2Fly, Xray, v2rayN and v2rayNG

Project V, V2Fly and Xray: Understanding the Project Landscape

These names are not different skins of the same app. Project V began as an ecosystem of network proxy tools built around V2Ray. In everyday use, “V2Ray” can mean either the project or, more specifically, the core that handles connections. Keep these meanings distinct when installing software or troubleshooting.

Around 2020, community maintenance of the original project gradually shifted to V2Fly, which continued development of the V2Ray core. Xray forked from the V2Ray codebase in 2020 and has since developed independently. The two share a common origin, but their release schedules, features and configuration support differ. Documentation for one should not be assumed to describe the other's current behavior.

Project V / V2Ray project ecosystem
└─ V2Ray codebase
   ├─ V2Fly: continues development of the V2Ray core
   └─ Xray: independent core forked in 2020

Graphical clients
├─ v2rayN: desktop client; runs supported cores depending on version and node type
├─ v2rayNG: Android client; primarily uses the Xray core
└─ v2flyNG: Android client; uses V2Fly's V2Ray core

The diagram shows code lineage and roles; it does not mean all three clients are released by a single project. Client and core versions are numbered separately, too. Updating the client interface does not necessarily update the core currently in use. Check the actual version in the startup log rather than relying on the window title.

Client and Core: How Settings Become Network Connections

Graphical clients manage subscriptions, node lists, settings, system proxy options and processes. The core handles local listening, protocol handshakes, DNS and routing. When you click “Connect,” the client typically generates a runtime configuration and then starts or invokes the core. On Android, the client also routes device traffic through the system VPN service; that is separate from the protocol used by the remote node.

v2rayN supports multiple cores, but the available options depend on the current release. Before switching, check Settings → Parameter Settings for entries related to Core. Subpage names may differ between versions. Renaming one executable to match another core's filename does not convert the configuration format or add protocol support.

• Client won't open: Check the runtime environment, directory permissions and application logs first; the problem may occur before the core starts.
• Core exits on startup: Check configuration parsing, supported fields and whether the listening port is already in use.
• Core runs, but the node times out: Check the remote address, port, transport, TLS and authentication settings.

VMess, VLESS and REALITY: Protocol Support Doesn't Guarantee Full Compatibility

VMess and VLESS are proxy protocols, not client names. WebSocket and gRPC are transport methods; TLS and REALITY are security-layer settings. Whether a node works depends on the combination of protocol, transport, security layer and version—not simply on whether “VLESS” appears in a list.

Be sure to distinguish VLESS from REALITY. VLESS does not provide encryption by itself, so deployments need a suitable secure transport. For a VLESS + REALITY node, use a core that explicitly supports the combination and preserve all required settings, including serverName, publicKey, shortId and the server's flow value. It is not the same as importing ordinary VLESS + TLS and toggling an extra option.

Subscriptions, JSON and Routing: What Can Be Migrated

A subscription is a way to retrieve node information in bulk, not a proxy protocol. It may contain a collection of share links or a complete configuration. Whether a client can read it depends on the content format and its parser. Base64 is just an encoding; it does not make configurations compatible across clients.

1. In v2rayN, check the subscription URL under Subscription Groups → Subscription Group Settings. In v2rayNG, open Subscription Group Settings from the side menu. Labels may vary slightly by version.
2. After updating, open a node's edit window and check the address, port, user ID, transport type and TLS settings one by one. Don't stop at confirming that the node name appears.
3. If parsing fails, make sure the response is subscription data—not a login page, expiration notice or web error. Subscription URLs contain access credentials; don't post them publicly in forums.
4. When migrating a full JSON configuration, first check the target core and configuration format. A successful subscription import does not guarantee that custom DNS, routing or local inbound settings will migrate too.

In common V2Ray / Xray JSON configurations, inbounds defines local entry points, outbounds defines connection exits, and routing.rules determines which exit matching traffic uses. The snippet below shows only a routing rule: it sends traffic from local-socks through the proxy outbound. It is not a complete, runnable configuration.

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "inboundTag": ["local-socks"],
        "outboundTag": "proxy"
      }
    ]
  }
}

The accompanying configuration must include an inbound with tag set to local-socks and an outbound with tag set to proxy. If the tags don't match, the routing rule won't work as intended. For the full fields and routing rules, see the routing configuration reference. Don't copy this JSON directly when switching to a core that uses a different configuration format.

System Proxy, TUN and Ports: Checking the Connection Path

A desktop system proxy sends traffic from apps that honor system proxy settings to a local listening port. TUN routes traffic through a virtual network interface and requires support from both the client and its core. Neither is a VMess or VLESS protocol, and importing a subscription does not necessarily enable either feature.

The three ports below illustrate a connection path; they are not guaranteed defaults for every version. Read the local listening ports in your current settings, then compare them with the app proxy and remote node ports. Don't enter the remote port 443 in a browser's local proxy port field.

• Local path: App → SOCKS listener at 127.0.0.1:10808 → core. With a mixed inbound, HTTP and SOCKS may share a port; check your current settings.
• Remote path: Core → node address and remote port → destination website. Changing the local listening port does not change the server's listening port.
• Android path: App traffic → system VPN service → client core. A VPN icon means local traffic routing is active; it does not prove that the node is reachable.
• TUN troubleshooting: Check the virtual interface, permissions, DNS and traffic routing before checking the node handshake. Don't assume the TUN toggle corresponds to a JSON field supported by every core.

Choosing or Switching Clients: Frequently Asked Questions

Choose in this order: platform, node settings, core support, then interface preferences. On desktop, check core support in the current v2rayN release. On Android, choose between v2rayNG and v2flyNG based on node requirements. Back up subscription groups and custom rules before migrating, and change one setting at a time when testing.

Keep a record of three things: client version, core version shown in the logs, and node settings with sensitive details removed. When reporting an issue, include these and the relevant error lines. That's more useful than saying only “V2Ray won't connect” and helps identify whether the problem is in the interface, configuration, protocol or network.