V2Ray Terminology Explained - Protocols, Cores, Subscriptions & Routing | V2Ray for Android

PROTOCOLS & TRANSPORTS

Protocols and transports: how connection parameters work together

Protocols define identity verification and data encapsulation, while the transport layer determines whether data travels over channels such as TCP, WebSocket or HTTP/2. Both sets of parameters must match the server configuration; a protocol name alone is not enough.

VMess: VMess is a proxy protocol in the Project V ecosystem. It uses user identifiers, time validation and encryption parameters for client-server communication. Client settings typically include the address, port, user ID, transport and security layer. If system clocks are significantly out of sync, identity verification may fail.

VLESS: VLESS is a lightweight proxy protocol that does not provide data encryption itself and is commonly paired with security layers such as TLS and REALITY. Confirm the protocol, transport and security parameters separately; VLESS is not a complete transport solution. Common combinations include VLESS over TCP and VLESS over WebSocket.

Trojan: Trojan relies on TLS to establish a secure connection. The client needs the server address, port, credentials and server name. The certificate name, system clock and server configuration all affect the handshake. After importing a link, check that the transport security options are complete.

Shadowsocks: Shadowsocks processes data with a pre-shared password and a selected encryption method. Client and server must use exactly the same method or communication cannot be established. Its configuration is relatively compact, but plugins, transport extensions and port details must still match.

REALITY: REALITY is a transport security scheme in the Xray ecosystem, commonly combined with VLESS and TCP. Typical client fields include the public key, short ID, server name and fingerprint. Any mismatch with the server can leave the connection stuck during the handshake.

WebSocket: WebSocket establishes bidirectional communication through HTTP connection upgrades and is usually written as ws in configuration. The path and request headers are transport parameters and must match the server. When a reverse proxy is involved, confirm that upgrade requests are forwarded correctly.

gRPC: gRPC is an HTTP/2-based remote-call transport used in V2Ray configuration to carry protocol data. The client and server must use the same service name and correctly configure TLS and other security options. Its fields differ from WebSocket, so changing only the network type is not enough.

CORE & ECOSYSTEM

Cores and ecosystem: low-level capabilities and graphical interfaces

The core handles protocols, transports, routing and DNS, while the graphical client manages configuration and system integration. A UI name and a core name are different concepts, and the same client version may offer multiple core choices.

Project V: Project V is an open-source technology ecosystem built around proxy cores, protocols and tools. It is not the name of a specific Android app or a single installer. V2Fly continues related core capabilities, while Xray has developed its own protocol and transport extensions.

V2Fly: V2Fly is a community-maintained V2Ray core project that handles protocols, inbound and outbound connections, routing and DNS. Graphical clients invoke the core to read configuration and establish connections. v2flyNG primarily provides an Android interface around this core.

Xray: Xray is a proxy core closely related to the V2Ray configuration model, supporting VLESS, REALITY, routing, DNS and multiple transport combinations. v2rayNG typically uses the Xray core, and v2rayN can also manage the corresponding Core. If a configuration field is not recognized, first check the active core and its supported version.

v2rayN: v2rayN is a graphical client for Windows, macOS and Linux. It manages subscriptions, servers, system proxy settings, routing modes and cores; it is not the V2Ray core itself. If desktop apps connect normally but do not use the proxy, check the system proxy or TUN settings.

v2rayNG: v2rayNG is a graphical Android client that typically uses the Xray core. After connection, it takes over selected network traffic through the system VPN interface and chooses outbounds according to routing rules. Subscription imports, per-app proxy settings and battery background policies are all client-level settings.

v2flyNG: v2flyNG is an Android client built around the V2Fly core. It can import subscriptions and standard share links and suits scenarios that use the V2Fly configuration model. Before choosing a client, confirm that its core supports the protocols and transport parameters used by the subscription.

SUBSCRIPTIONS & NODES

Subscriptions and nodes: how configurations reach the client

Subscriptions distribute configurations in batches; a node is an individual server entry available after parsing. Speed-test results describe only the current probe conditions and cannot replace protocol checks or a real connection test.

Subscription: A subscription is a server-provided URL containing a set of configurations. The client requests the URL and parses its server entries. Updating a subscription syncs added, changed or removed configurations, but usually does not resolve local routing conflicts. An expired link, denied access or invalid response format can make the update fail.

Node: A node is a server configuration entry in the client, typically containing an address, port, protocol, identity parameters, transport and security settings. Its name is only a label for identification and does not determine how the connection works. Check every field and run a real connection test to assess usability.

Latency: Latency is the time a probe takes to travel from the client to the target and receive a response, usually shown in milliseconds. Clients may use TCP, HTTP or other probe methods, so results are not directly comparable. Local network conditions, the target address and temporary server load also affect the value.

Real connection latency: Real connection latency is the response time measured after establishing an actual proxy connection through the target node. It covers protocol handshaking, transport security and proxy egress, making it more representative than a basic port-connectivity test. Results can still vary substantially between test targets.

Subscription group: A subscription group organizes subscription sources and their nodes in the client. Groups can be updated, filtered and assigned an active server separately, keeping multiple subscriptions from becoming one undifferentiated list. Before deleting a group, check whether local manual configurations are included.

ROUTING & DNS

Routing and traffic splitting: where connections ultimately go

Routing matches domains, IPs, ports or processes to select an outbound. DNS affects how domains are resolved and whether routing receives the correct target information. Rule order, data files and sniffing settings together determine the result.

Routing rule: Routing rules select a proxy, direct or blocked outbound based on conditions such as domain, IP, port, network protocol or process. When several rules apply, matching usually follows the order defined by the core. The default outbound after no rule matches is equally important and should be checked with the intended mode.

Traffic splitting: Traffic splitting sends different connections to different outbounds through routing rules. It can divide traffic by domain category, destination IP, port or application process. When it misbehaves, first confirm that the client has domain information, then check rule order and the default outbound.

GeoIP: GeoIP is rule data organized by the region or network category associated with an IP address. Once the core obtains the destination IP, it can use the relevant category to choose an outbound. GeoIP data must match the format supported by the core, and outdated data may misclassify newer address ranges.

GeoSite: GeoSite is rule data organized by purpose or domain category, and routing configurations can reference its category tags directly. It contains domain sets rather than GeoIP address classifications. If only the destination IP remains during connection setup, sniffing or DNS information may be needed to restore domain-based matching.

TUN mode: TUN mode receives system traffic through a virtual network interface and can cover programs that do not actively read system proxy settings. It generally requires additional system permissions and involves routing tables, DNS and network-interface configuration. After enabling it, avoid having another virtual networking tool take over the same traffic.

FakeDNS: FakeDNS answers domain queries with virtual IPs from a reserved address pool and restores the original domain during the subsequent connection. This lets routing classify traffic by domain earlier and can reduce repeated resolution. It usually needs to work together with TUN, sniffing and a correctly configured DNS flow.

DNS leak: A DNS leak occurs when some domain queries bypass the intended DNS path and are sent directly to another resolver. Common checks include the system resolver, browser secure DNS, TUN settings and the client's built-in DNS. Identify which app issued the query before standardizing its resolution path.

CLIENT FEATURES

Client features: what interface switches actually do

Client switches mainly control how traffic enters the core and how configuration is applied to the operating system. A normal connection status only shows that the core is running; whether an app uses the path also depends on the system proxy, TUN or per-app scope.

System proxy: A system proxy is the proxy configuration exposed by the operating system for applications to read. v2rayN can write its local HTTP or SOCKS listening address to the system settings, after which compatible programs hand connections to the client. Programs that ignore this setting may require TUN or their own proxy option.

Global proxy: Global proxy usually means that every connection entering the client uses the proxy outbound instead of normal category-based routing. It is useful for determining whether complex routing causes a connection problem. This mode affects only traffic that reaches the client; it does not make every app read the system proxy automatically.

Traffic sniffing: Traffic sniffing identifies the target domain or protocol characteristics from a connection's initial data, supplying information for domain routing and FakeDNS mapping. It is not a UI feature for capturing complete communications, but a core-level identification mechanism used during routing. Enable it only after considering the protocol, DNS and traffic-splitting rules.

Mux: Mux multiplexes multiple logical requests over one underlying connection to reduce the cost of repeatedly opening connections. It does not improve performance for every network and protocol combination, and frequent mobile-network changes may increase reconnection impact. Confirm server support and compare real applications before changing it.

Per-app proxy: Per-app proxy specifies which Android apps hand their connections to the client. Configuration usually uses either include mode or exclude mode, whose logic is opposite. After changing the app scope, reconnect and check whether the target app uses a separate network process.