V2Ray Configuration Reference

V2Ray Glossary: Protocols, Cores, Subscriptions and Routing Concepts

Common terms are organized around real configuration paths, distinguishing protocols, cores, client features, and test metrics. Each entry explains the problem it addresses, the parameters it depends on, and nearby concepts that are easy to confuse.

5 Categories

28 Core Terms

4 Platforms

Quick Index

Pinyin and English Index

Jump directly to a known term. English protocol names retain their original spelling, while Chinese feature names are listed under their common English equivalents.

01

Protocols and Encryption

Protocols define how clients and servers authenticate, encapsulate, and transmit data. A protocol name in a subscription does not determine connection quality by itself; usability also depends on the security layer, transport, and matching server parameters.

VMess: A proxy protocol used in the Project V ecosystem. The client and server must use matching user IDs, ports, transports, and security parameters; any mismatch can cause the handshake to fail. VMess is a protocol name, not a client name, and does not indicate which graphical interface manages a node.

VLESS: A streamlined proxy protocol that does not provide additional data encryption by itself and is commonly paired with security layers such as TLS or REALITY. Besides the address, port, and user ID, verify flow control, security settings, and the server name. VLESS and VMess can coexist in one subscription, and the client processes each node according to its protocol.

Trojan: A proxy protocol that uses a password as its primary authentication credential and typically runs over TLS. Common client parameters include the server address, port, password, server name, and certificate-verification options. A Trojan node cannot directly reuse VMess or VLESS authentication fields; preserve the protocol type supplied by the subscription after importing it.

Shadowsocks: A proxy protocol that uses a pre-shared password and a specified encryption method. The server address, port, password, and encryption method must match on both sides. It is not the same as a local SOCKS proxy: the former describes the client-to-server protocol, while the latter is typically an interface applications use to connect to the local client.

REALITY: A transport-security solution in the Xray ecosystem, commonly paired with VLESS. Subscription nodes usually include the server name, public key, short ID, and fingerprint, all of which must correspond when entered manually. REALITY is not a standalone node protocol, so the complete combination is usually still identified as VLESS in the configuration interface.

02

Cores and Ecosystem

The graphical client handles the interface, subscriptions, and system settings, while the core handles protocol connections, DNS, and routing. Distinguishing project names, core forks, and client names helps identify which layer executes a particular setting.

Project V: An open-source technology ecosystem built around network proxy protocols, routing capabilities, and related tools. V2Ray’s configuration system, protocols such as VMess, and later core forks are all connected to its development. It describes a technical and project background, not a specific installer.

V2Ray: The name of a core program and configuration system commonly used in the Project V ecosystem, and often a collective term for related client projects. Strictly speaking, the V2Ray core and graphical clients such as v2rayN and v2rayNG are not the same software. Clients can wrap core capabilities and provide controls for subscription updates, node selection, and the system proxy.

V2Fly: A community-maintained project that continues the V2Ray technical approach and provides v2ray-core along with related specification implementations. The v2fly name in clients such as v2flyNG refers to this core ecosystem. When troubleshooting compatibility, check the client version, core fork, and protocol parameters together rather than relying only on the interface name.

Xray: A core fork closely associated with the V2Ray configuration system. It supports capabilities such as VLESS and REALITY and is used by some graphical clients. Xray is a core, not a subscription service or a connection mode. The protocols shown as supported in a client usually depend on the bundled core and the client’s configuration adapter.

v2rayN: A graphical client for Windows, macOS, and Linux that manages subscriptions, nodes, the system proxy, routing, and TUN features. v2rayN converts interface settings into runtime configuration that the core can read. When troubleshooting, check the client actions, generated configuration logic, and core logs separately.

03

Subscriptions and Nodes

Subscriptions handle the bulk distribution and updating of configurations, while a node is an individual connection record that can actually be selected. The local list changes with updates, so check whether a later update will overwrite manual edits before making them.

Subscription: A configuration-collection URL generated by a service provider. The client uses it to retrieve node information. The subscription URL is usually not a node that can be connected to directly; it is the source of the node list. After importing it, run an update so the client can request the content and write it to the local database.

Node: A selectable server connection profile in the client, containing the address, port, protocol, authentication, and transport parameters. The node name is mainly for identification; the internal configuration fields determine connection behavior. After selecting a node, start the core and enable the system proxy or TUN mode according to your use case.

Subscription Group: A client feature for managing subscription sources separately, with independent notes, update intervals, and filtering conditions. Groups help distinguish node sources and update only one subscription when needed. Deleting a group usually also affects nodes belonging to that source, so confirm the scope shown by the client before proceeding.

Subscription Update: The process of requesting a subscription URL again and refreshing the node list with the returned content. It is not the same as upgrading the client application and does not automatically fix server-side configuration. Changes in node count, names, or parameters usually come from the new content returned by the subscription source.

Node Filtering: A management method that filters subscription content by region, multiplier, protocol, or custom keywords in node names. Filtering removes irrelevant entries from the list but does not improve a node’s connection quality. When using exclusion rules, check the keyword scope carefully so needed nodes are not hidden as well.

04

Routing and Traffic Splitting

The routing system first identifies the connection target, then selects an outbound path according to rule order. Where DNS resolution occurs, whether the application follows the system proxy, and whether TUN captures the traffic all affect the information available for matching.

Routing Rule: A set of matching rules that determines whether traffic should connect directly, use a proxy, or be blocked based on domains, IPs, ports, protocols, or processes. Rules are usually evaluated in order, and the first match affects subsequent handling. After changing rules, verify the result with clear test targets rather than relying only on the node’s displayed status.

Traffic Routing: A configuration approach that assigns traffic for different destinations to different outbound paths. Some connections may go directly to their destinations while others are handled by a selected node. Traffic splitting is not a single switch; it combines matching data, rule priority, DNS policy, and outbound configuration.

GeoIP: A data set used to match routes by the geographic region associated with an IP address. It applies only when the target has already been resolved to an IP or when a rule directly processes an IP address. IP geolocation data changes as network resources are reassigned, so the same rule can produce different matches with different data versions.

GeoSite: A rule data set organized by domain categories, allowing the routing engine to match groups of domains in bulk. It handles domain rules rather than GeoIP address ownership. Check the category names, matching method, and rule order to avoid confusing a domain collection with an IP collection.

System Proxy: The client modifies the operating system proxy settings so applications that follow them send HTTP or SOCKS requests to a local proxy port. Not every program reads system proxy settings, so an “enabled” status does not mean all traffic is captured. Browsers and conventional desktop applications are usually the easiest place to begin testing this mode.

TUN Mode: A mode that captures more system traffic through a virtual network interface, useful for applications that do not read system proxy settings. TUN involves routing tables, DNS, and virtual network adapter permissions, so confirm that ordinary node connections work first. If networking fails after enabling it, disable TUN and check permissions, DNS, and routing separately.

FakeDNS: A DNS mechanism that temporarily returns reserved addresses for domains and restores the domain information during the subsequent connection stage. It is commonly used with TUN mode and domain-based routing, allowing connections that expose only a destination IP to match rules by the original domain. A FakeDNS address is an internal mapping result, not the real address of the destination server.

05

Connections and Diagnostics

Diagnostic metrics must be interpreted in the context of the test method. Ping, true connection latency, and download speed tests observe different stages. When a connection fails, check the subscription content, node parameters, core logs, system traffic-capture mode, and DNS path in sequence.

Latency: The time required for data to make one round trip, usually measured in milliseconds. Different test methods cover different parts of the path, so results should not be compared without considering the test type. A lower Ping does not necessarily mean a faster proxy handshake or higher download bandwidth.

True Connection Latency: The time measured when the client completes an actual connection request through a proxy node, including the proxy handshake and the connection to the destination. Compared with Ping, which only checks network reachability to a server, it better reflects the connection stage involved in everyday web access. A failed test usually means the complete proxy path was not established, but logs are still needed to identify the cause.

Download Speed Test: A test that estimates a node’s usable throughput by transferring real data. Results are affected by the test target, local network, node load, transport protocol, and test time. Because it generates real traffic, it is best used after true connection latency passes to assess large-file transfers or video loading.

DNS Leak: A condition in which proxy connections are enabled but some domain lookups still travel through a DNS path that is not being used as intended. This is separate from whether a connection to the proxy node can be established. Troubleshooting requires checking the application’s lookup method, system DNS, client DNS settings, and TUN coverage rather than simply switching nodes.

Handshake: The stage in which the client and server establish a protocol session and negotiate required parameters. Mismatched authentication, TLS, server name, public key, or transport settings usually produce errors here. A handshake failure in the logs is more specific than a generic connection-failed message and helps narrow the checks.

Packet Loss: A condition in which packets fail to reach their destination during transmission. Persistent loss can cause retries, unstable speeds, choppy voice calls, or interrupted sessions, while an isolated result may come from a local wireless network. Repeat tests at different times and distinguish the local, server, and destination links.