V2Ray Configuration Concepts Index

V2Ray Terminology Guide: Protocols, Cores, Subscriptions and Routing

From VMess, VLESS and REALITY to subscriptions, nodes, TUN mode, GeoSite and runtime logs, this guide explains common terms in the order they appear in configuration. Each entry defines the concept, its layer and its practical use in troubleshooting, helping connect the interfaces and documentation of v2rayN, v2rayNG and v2flyNG.

6 categories 28 terms Protocols and configuration explained side by side

READING GUIDE

Identify the layer first

A GUI client, core, protocol, transport, subscription and routing are different concepts. When a connection fails, first determine whether the issue occurs during configuration import, core startup, protocol handshake, DNS resolution or traffic capture. Then check the relevant term; this is usually faster than repeatedly changing settings.

Configuration management layer

Clients, subscriptions and nodes

The GUI client stores and organizes configuration, subscriptions provide nodes in batches, and a node is one specific connection record. A successful list update only means that configuration data reached the client; the core must still load it and the connection must be tested.

Connection execution layer

Cores, protocols and transports

The Xray or V2Fly core reads the configuration generated by the client and creates connections using protocols such as VMess, VLESS and Trojan. REALITY, TLS and other transport parameters are part of the same connection design and must be configured as a matching set.

Traffic decision layer

Inbound, routing and outbound

Application traffic first enters the client through the system proxy, TUN or another method. Routing rules then evaluate the target and hand it to a direct, proxy or block outbound. A failure at any layer can affect the final access result.

PROTOCOLS

Protocols and encryption

The protocol determines how the client and server authenticate and exchange data, while transport security adds handshake and outer-connection parameters. Treat the full set of fields as one solution when importing configuration; the protocol name alone cannot show whether two profiles are equivalent.

VMess: A client-to-server communication protocol in the Project V ecosystem. Both sides must use matching user identifiers, transport settings, ports and security parameters. A client recognizing shared content does not mean every parameter is still valid; test the connection before use.

VLESS: A lightweight protocol commonly combined with TLS, REALITY or other transport-layer settings. VLESS is not a complete connection solution by itself. Check the address, port, user identifier, transport type and outer security fields together when troubleshooting. Changing only one field can break the original combination.

Trojan: A proxy protocol that uses a password as its primary authentication method and is often configured with TLS. The server address, port, password, server name and transport settings in the client must match the server. A certificate-name, time or authentication mismatch can terminate the connection during setup.

REALITY: A transport security solution in the Xray ecosystem, commonly used with VLESS. Check the server name, public key, short ID and fingerprint rather than entering only an address and port. Incomplete link parsing or an outdated client core can prevent these parameters from loading correctly.

CORE & CLIENT

Cores and clients

The client is the user interface; the core is the program that performs network tasks. They may be updated independently, so the interface version, core version and configuration format should be considered separately. Not every problem is a “client version” problem.

Xray: One of the core implementations in the V2Ray ecosystem. It parses configuration, creates connections, applies routing and handles DNS. GUI clients such as v2rayN and v2rayNG convert interface settings into configurations the core can read. Availability depends both on whether the interface exposes the required fields and whether the selected core supports them.

V2Fly: A community-maintained continuation project and core family from Project V. It shares technical origins with Xray, but protocol support, feature implementation and release cadence must be evaluated separately. v2flyNG generally follows the V2Fly core path and suits configurations that explicitly require that core.

GUI client: A desktop or mobile interface for managing subscriptions, nodes, routing and the system proxy. It typically generates configuration and calls the core rather than handling all network processing directly. v2rayN targets desktop platforms, while v2rayNG and v2flyNG target Android; interface labels and menu locations may differ.

Core: The core program that performs inbound listening, outbound connections, DNS queries and route matching. The interface and core are separate layers: even when the interface opens normally, the core may fail to start because of invalid configuration. Runtime logs show whether the configuration was passed to and accepted by the core.

SUBSCRIPTION

Subscriptions and nodes

A subscription handles bulk distribution and configuration updates, while a node is one selectable connection record. Updating, selecting, testing and connecting are separate but continuous steps; success at one step does not replace validation of the next.

Subscription: A set of node details published by a configuration provider. The client fetches and updates it through a subscription URL. Updates change the local node list but do not necessarily switch the selected node. Matching group names before and after an update do not prove that the node contents stayed the same.

Node: A single server connection profile in the client, usually containing an address, port, protocol, authentication details and transport settings. A node appearing in the list only means its configuration was read, not that the connection works. After selecting a node, start the relevant proxy mode and verify the traffic path with a real request.

Subscription group: A client-side structure for organizing nodes from multiple subscription sources. Groups distinguish configuration sources and allow updates, enabling or filtering to be performed separately. Deleting a group often removes its local nodes as well, so confirm where the nodes came from first.

Subscription URL: The address a client uses to retrieve subscription content. Preserve the complete string when importing it; an incomplete copy, stray spaces or an expired URL can cause updates to fail. If the address opens in a browser but the client update fails, check the client's network path and the specific response in its logs.

ROUTING

Routing and traffic splitting

Routing rules decide where traffic that has already entered the client should go. Rule matching and traffic capture are separate stages: if an application has not entered the client, even a complete routing configuration cannot evaluate its traffic.

Routing rule: A matching rule that determines where traffic goes based on conditions such as domain, IP, port, protocol or process. Rules are usually evaluated in order, so a broad rule placed too early may override specific conditions later. After editing rules, reload the configuration and use logs to confirm which outbound matched.

Traffic splitting: A configuration method that sends different requests through direct, proxied or blocked outbounds. Results depend on rule order, DNS resolution and whether application traffic enters the client. When one site's path behaves unexpectedly, identify the matched rule before rewriting the entire configuration.

GeoIP: A data set matched by the geographic region associated with an IP address. It applies to an already resolved IP, and accuracy depends on the database version and changes in address ownership. For domain-based requests, the DNS result also affects the later GeoIP decision.

GeoSite: A rule data set organized by domain categories, which routing rules can use to match groups of site domains. GeoSite handles domain rules and should not be confused with GeoIP, which matches IP addresses. If the core does not receive the original domain, some domain-based matches may not work as expected.

Inbound: The side where the core receives connections from local applications, such as a local SOCKS or HTTP listening port or a TUN interface. An application must enter the appropriate inbound before routing and outbound rules can take effect. Logs can confirm whether a request reached the specified listening port.

Outbound: The way the core sends traffic after processing it. Common actions include connecting directly, forwarding through the selected node or blocking the request. Routing rules ultimately pass each matched request to an outbound. The outbound name is only a configuration label; its actual connection method is determined by the node or action it references.

NETWORK

Networking basics

The system proxy, TUN and DNS bring application requests into the client while preserving enough target information. They are related but serve different purposes, so determine whether proxying works by checking the traffic entry point, domain resolution and final outbound separately.

TUN mode: A mode that takes over more application traffic through a virtual network interface. It helps with programs that ignore system proxy settings, but requires attention to permissions, routing tables, DNS and conflicts with other network tools. Restore related settings before closing the client to reduce confusion from leftover system network state.

System proxy: A proxy setting exposed by the operating system for applications to read. Browsers and similar programs usually follow it, while some command-line tools or apps with their own network stack may need separate configuration. When the client reports that the system proxy is enabled, also confirm that its listening port started successfully.

FakeDNS: A DNS handling method that first returns a mapped address from a reserved range for a domain, then lets the core restore the original domain and apply routing. It preserves domain information but must be coordinated with TUN, DNS and routing settings. The mapped address is not the target server's real address and should not be used directly to determine ownership.

DNS leak: A situation where an application's domain lookup does not follow the intended DNS path and is handled by another resolver. Check system DNS, browser secure DNS, the TUN capture scope and client rules together. Changing nodes alone usually cannot fix an inconsistent resolution path.

Latency: The time required for a probe to travel from the local machine to its target and complete, usually measured in milliseconds. Different tests measure different stages, so a basic network probe cannot fully represent protocol connectivity or real request performance. Lower latency does not necessarily mean better throughput, stability or reachability.

Real connection latency: The time measured after establishing a connection through the node's actual protocol and completing a target request. It is closer to the client's real usage path than a simple reachability probe, but remains affected by the local network, test target and current path conditions. Use it as a reference when selecting nodes, then verify with real access.

LOGS

Logs and troubleshooting

A single English word in a log usually describes only the result and cannot identify the cause on its own. Keep the surrounding lines and record the target address, outbound name, time and configuration changes made immediately beforehand.

Log level: A setting that controls how much detail the core records. Common levels distinguish general information, warnings and errors. Increase it temporarily to observe DNS, routing and connection steps, then restore the normal level so excessive detail does not obscure the important error.

timeout: Indicates that a connection or request did not complete within the allowed time. Possible causes include an unreachable server, a blocked port, DNS problems, mismatched transport parameters or a slow target response. Use the operation immediately before timeout to determine whether resolution, connection setup or response reading timed out.

rejected: Indicates that a connection was explicitly rejected by a client rule, remote service or target. Check the outbound name, target address and surrounding error text to identify the cause. If the log also shows a blocking rule match, inspect routing before changing protocol parameters.

invalid user: Usually indicates that the server did not accept the authentication details. Check the user identifier, password, system time and relevant protocol fields instead of repeatedly changing system proxy modes. After a subscription update, an old manually retained node may still use credentials that have changed.

NEXT STEP

Put the terminology back into the configuration workflow

After reading the terminology, follow this sequence: import a subscription, select a node, enable the system proxy or TUN, check routing, verify the connection and review logs. Match each concept to the operation: use update logs for subscription issues, the system proxy or TUN for capture issues, and routing plus DNS when traffic takes the wrong path.

View the setup guide Read the full documentation