V2Ray Glossary: Protocols, Cores, Routing and DNS Concepts

Protocols & Security

Protocols and encryption

Protocols define how clients and servers authenticate and exchange data, while the transport security layer handles connection encryption and server identity checks. When importing a node, these fields must match the server configuration; they cannot be swapped based on their names alone.

VMess: VMess is an earlier client–server communication protocol in the Project V ecosystem. It authenticates users with an identifier and a time-based mechanism. Nodes commonly specify transports such as TCP, WebSocket, or gRPC, with TLS optionally layered on top. If the system clock is significantly inaccurate, authentication may fail, so checking the device time is an important first step when troubleshooting a connection.

VLESS: VLESS uses a more streamlined authentication structure and does not provide transport encryption itself, so it is commonly paired with TLS or REALITY. Its configuration typically includes a user identifier, flow control, transport, and security type. Its fields differ from VMess; changing the protocol name does not convert one node into the other.

Trojan: Trojan is a protocol built on TLS connections and authenticated with a password. Client settings usually include the server address, port, password, server name, and certificate-validation options. If the system time, SNI, or certificate chain is incorrect, the connection may stop with a failed TLS handshake before an authentication request is sent.

REALITY: REALITY is a transport security solution provided by Xray and is commonly used with VLESS. On the client side, settings may include a public key, server name, short ID, and client fingerprint, all of which must match the server configuration. REALITY is not a standalone node protocol; in most interfaces it appears under transport security rather than protocol selection.

TLS: TLS is a general-purpose encryption protocol for protecting network connections. It establishes an encrypted channel and verifies the server’s identity. The server name, certificate domain, and system time in a node configuration all affect validation. When a certificate error occurs, check the time and SNI before disabling certificate verification.

Cores & Clients

Cores and clients

Graphical clients manage subscriptions, edit parameters, and display status; the core parses the configuration, establishes connections, and applies routing. Distinguishing these layers helps identify whether a problem comes from the interface, the generated configuration, or the core at runtime.

Xray: Xray is one of the core implementations in the V2Ray technology ecosystem, supporting VMess, VLESS, Trojan, REALITY, and a range of routing and DNS features. Common v2rayN and v2rayNG configurations can invoke Xray. When the interface shows “Core type: Xray,” it means the current connection configuration will be parsed and run by that core.

V2Fly: V2Fly is a community core implementation that continues the Project V technology stack, providing proxy protocols, transports, DNS, and routing. It shares a common technical origin with Xray, but its protocol coverage and some configuration fields are not identical. Before choosing a core, confirm that the required node features are supported by the relevant version.

v2rayN: v2rayN is a graphical client for Windows, macOS, and Linux that manages subscriptions, nodes, the system proxy, TUN, and routing rules. It turns interface options into a configuration the core can read and starts or stops the core process. A successful client connection only confirms that the process is running; logs and routing results are still needed to determine whether the target is reachable.

v2rayNG: v2rayNG is a graphical Android client that typically uses the Xray core to run node and routing configurations. During a connection, it receives application traffic through the system’s VPN service interface, but this does not change the node protocol itself. Battery-saving policies, background restrictions, and permission status can all affect connection persistence.

Core: Core refers to the network engine actually invoked by the client. The graphical interface collects parameters, while the core listens on local ports, establishes outbound connections, resolves DNS, and applies routing rules. When investigating crashes or startup failures, core logs usually contain more useful detail than the interface’s brief status message.

Subscriptions & Nodes

Subscriptions and nodes

A subscription is an updatable list of nodes, while a node is a set of specific connection parameters. Latency results reflect response behavior under a particular test condition and cannot alone indicate protocol compatibility, bandwidth, or long-connection stability.

Subscription: A subscription usually appears as an updatable URL. After accessing it, the client receives a node list or configuration data. Updating a subscription fetches the remote data again, so local node names, parameters, or ordering may change. If the import succeeds but the list is empty, check that the URL is complete, the system time is accurate, and the update log contains no parsing errors.

Node: A node is a set of server parameters that a client can connect to, typically including the protocol, address, port, authentication details, transport, and security settings. The node name is only a label for identification and is not used for authentication. Two nodes with the same name may have completely different addresses, protocols, or routing behavior.

Subscription group: A subscription group distinguishes different subscription sources and keeps their related nodes in one management unit. The client can update, filter, or view nodes by group, preventing multiple sources from being mixed into one list. Deleting a group usually also affects the locally stored nodes from that source, so confirm the scope before proceeding.

Latency test: A latency test estimates a node’s response speed under current network conditions, but different methods measure different stages. A port-only test generally shows only that the server port is reachable; it does not prove that the proxy protocol completed authentication. Results are also affected by the local network, DNS, target address, and concurrent tasks.

Real-connection latency: Real-connection latency establishes an actual proxy connection through the node, accesses a test target, and records the response time. It is closer to the complete usage path than a simple TCP port test and is more likely to reveal protocol or TLS configuration errors. Even so, one result is only a snapshot; judge performance using repeated tests and real connection behavior.

Routing

Routing and traffic splitting

The routing system selects an outbound using conditions such as the domain, IP, port, or protocol. Rules must not only match correctly but also be ordered carefully: when multiple rules can match a request, the first effective rule usually determines how it is handled.

Routing rule: A routing rule maps a set of conditions to a target outbound and can match traffic by domain, IP, port, network type, process, or other attributes. After a match, the core sends the request to the specified proxy, direct, or block outbound. Poor ordering can let a broad condition override more specific rules that appear later.

Traffic splitting: Traffic splitting assigns different network requests to different outbounds. For example, one group of domains can connect directly while another is sent through the current node. The result depends on whether the core can obtain the domain, the resolved IP, and the rule priority, making traffic splitting closely tied to DNS settings.

GeoIP: GeoIP is a dataset organized by the geographic or network classification of IP addresses, which routing rules can reference by category. It matches the IP resolved or used as the connection target, not the domain text itself. The data must be updated regularly; otherwise, newly assigned or changed address ranges may be classified incorrectly.

GeoSite: GeoSite is a collection of domain rules organized by purpose or category, allowing related domains to be referenced at once. Its matching target differs from GeoIP: GeoSite handles domains, while GeoIP handles IP addresses. Confirm that the rule-set name exists and check whether the data comes from the client’s built-in set or a custom source.

Outbound: Outbound describes the direction in which traffic is sent after core processing. Common outbounds include connecting through the current node, connecting directly through the system network, and blocking matching requests. Every routing rule must point to a valid outbound tag; inconsistent spelling prevents the rule from linking correctly.

Network & DNS

Networking and DNS

The system proxy and TUN determine how the client receives application traffic, while DNS converts domain names into addresses and participates in traffic splitting. When a connection fails, check separately whether the application entered the client, how the domain was resolved, and which outbound ultimately handled the request.

System proxy: A system proxy is a way for the operating system to publish a local proxy address and port to applications that support proxy settings. Once enabled, browsers and other compliant programs send requests to v2rayN, but applications that manage their own network connections may ignore it. After switching modes, existing connections may continue using the old path, so reconnect when necessary.

TUN mode: TUN mode receives system traffic through a virtual network interface and can cover applications that ignore system proxy settings. It usually involves the routing table, DNS interception, and system permissions, making it more complex than a standard system proxy. If networking stops after enabling it, check the virtual interface, routing rules, DNS settings, and conflicts with other network tools in that order.

FakeDNS: FakeDNS first returns reserved addresses for domains, then restores the original domain name after traffic enters the core so routing rules can match it. This can reduce cases where an application performs a real lookup through the system first while preserving domain-based routing information. Some applications that require real-IP validation, special UDP behavior, or direct access to resolution results may not work well with this mode.

DNS leak: A DNS leak occurs when resolution requests do not follow the expected path and instead reach another resolver. Common causes include applications specifying their own DNS, browsers enabling independent encrypted DNS, incomplete TUN interception, or missing routing rules. Diagnosis requires checking the resolver, query path, and final outbound together rather than relying on a single result shown by a website.

SNI: SNI is the field in a TLS handshake that identifies the target server name. In client node settings, it often appears as serverName or server name. It generally needs to match the certificate and server configuration and should not simply be copied from the node address. An incorrect value can cause a certificate-name mismatch, handshake rejection, or timeout.

Mux: Mux is a multiplexing mechanism that carries multiple logical requests over fewer underlying connections. It may reduce the overhead of repeatedly opening connections, but it will not make every network faster. Enable it only after testing against the protocol support, server configuration, long-connection stability, and actual application workload.