V2Ray Terminology Guide: Protocols, Cores, Subscriptions, Routing & Clients

CATEGORY INDEX

Find terms by configuration layer

When you encounter an unfamiliar field, first determine whether it belongs to the protocol, core, subscription, routing, or client layer, then open the relevant category. Entries cross-reference one another, but each can also be read independently.

How to read this guide: The protocol determines how data is encapsulated; the transport and security layers determine how the connection is carried; routing determines which outbound handles it. Graphical clients organize these fields into a UI, but the core ultimately reads the configuration and executes it.

LAYER 01 / PROTOCOL

Protocols & Encryption

The protocol layer handles identity parameters and data encapsulation. Security mechanisms such as TLS and REALITY occupy adjacent layers, while WebSocket is a transport method. Confusing these fields is one of the most common mistakes when manually reviewing a configuration.

VMess: VMess is a client-to-server communication protocol in the V2Ray ecosystem. Its configuration typically includes a user ID, encryption options, and time-based validation. It handles protocol-level data encapsulation and is not the same as TLS, WebSocket, or the underlying network connection. When reviewing a shared link, check VMess fields separately from transport and security parameters.
VLESS: VLESS is a streamlined transport protocol often combined with TLS, REALITY, TCP, gRPC, and other settings. It does not replace the transport security layer, so after selecting VLESS in a client, you still need to enter the server name, transport type, and security parameters. For troubleshooting, verify the protocol identity fields first, then check the outer layers.
Trojan: Trojan primarily uses password authentication for identity verification and typically runs over a TLS-secured connection. Client configuration requires more than an address, port, and password: also check the server name, certificate verification policy, and transport parameters. Even a correct password may not help if the TLS fields do not match and the handshake is aborted.
REALITY: REALITY is a transport security solution in the Xray ecosystem. Common fields include the public key, short ID, server name, and client fingerprint. It is not a standalone node protocol, but a security layer used with protocols such as VLESS. After importing a configuration, verify the public key and short ID field by field rather than judging the node by name alone.
TLS: TLS provides encryption, integrity protection, and server authentication for a connection. In V2Ray configurations, the server name commonly participates in certificate matching; device time, DNS resolution, and certificate status can also affect the handshake. Enabling TLS only selects the security layer, so the protocol, address, and transport entry point must still match the server.
WebSocket: WebSocket is a bidirectional transport built on HTTP semantics and is usually listed under transport settings in client interfaces. Common parameters include the path and host name, which must match the remote entry point. Protocol authentication occurs at an inner layer, so a working WebSocket connection does not prove that the entire protocol chain is complete.

LAYER 02 / CORE

Cores & Ecosystem

Graphical clients import, edit, and switch configurations, while the core establishes connections, performs DNS queries, and applies routing. Separating the client from the core makes it easier to determine whether a feature comes from the UI, the configuration format, or the underlying implementation.

Project V: Project V is an open-source technology ecosystem built around proxy cores, protocols, and supporting tools. V2Ray Core, V2Fly, and multiple graphical clients are connected to it through their history or implementations. It is not the name of one specific client; discussions of particular features should also identify the core and client versions in use.
V2Ray Core: V2Ray Core is the core program that reads configuration and handles inbound, outbound, transport, DNS, and routing logic. Graphical clients convert subscriptions and settings into configurations the core can read, then manage the core process. Protocol handshakes, routing matches, and DNS records in logs generally come from the core layer.
V2Fly: V2Fly is a community-maintained project and core family continuing the V2Ray Core technical direction. Its related cores can handle inbound, outbound, routing, DNS, and multiple transport configurations, and clients such as v2flyNG can use them for connections. Feature support may differ between branches, so check field compatibility when migrating configurations.
Xray: Xray is a core family with configuration concepts similar to V2Ray, supporting protocols and security features such as VLESS and REALITY. Some v2rayN and v2rayNG options generate different fields depending on the Xray core in use. Whether a client can display a setting and whether the core can parse its field are separate questions.

LAYER 03 / SUBSCRIPTION

Subscriptions & Nodes

Subscriptions distribute configuration, nodes represent individual remote profiles, and latency tests observe only a particular test path. They often appear in the same interface, but answer different questions: where the configuration comes from, what is currently selected, and what the probe found.

Subscription: A subscription is a set of nodes or configuration endpoints centrally provided by a server. The client fetches and updates its local list through a link. Updating a subscription only synchronizes configuration and does not mean every node is currently available. If the list is empty, check the link, response format, update path, and client compatibility in that order.
Node: A node is a single remote connection profile in a client list, usually containing an address, port, protocol, identity parameters, transport method, and security settings. Its name is only an identification label, not proof of connection status. After switching nodes, confirm it is active and reapply the proxy state.
Latency: Latency is the response time measured when a client probes a target, usually reported in milliseconds. Basic probes, TCP connection tests, and real request tests do not cover exactly the same path, so compare results only under equivalent conditions. A lower value alone does not indicate higher throughput or stable long-lived connections.
Real connection latency: Real connection latency usually means the time taken for a client to establish an actual connection through the selected node and access a specified test target. Unlike a simple server-port probe, it covers more steps, including the protocol handshake, transport security, and target request. Results still depend on the target address, current network, and test time.
Subscription conversion: Subscription conversion is the process of turning raw subscription content into a target client's or configuration format. It may involve field mapping, node filtering, and rule merging. Check the protocol, security layer, transport method, and server name carefully. Successful import only shows that the structure is readable; it does not prove every parameter remains equivalent to the original.

LAYER 04 / ROUTING

Routing & Traffic Splitting

The routing system reads the domain, destination address, port, network type, and inbound tag before choosing an outbound. DNS appears early in this chain, and the resolution method directly affects whether later rules match by domain or by address.

Routing rules: Routing rules are conditions that select an outbound path based on the domain, destination address, port, protocol, or inbound tag. Most configurations match by a defined priority or written order, so earlier conditions may take effect first. When editing rules, record the match condition, target outbound, and final fallback strategy together.
Traffic splitting: Traffic splitting is a configuration strategy that sends different types of connections through different outbounds, for example by domain set or destination address. It is not a standalone protocol but the result of combined routing rules. If traffic takes an unexpected path, check rule order, resolution results, and outbound tags.
GeoIP: GeoIP classifies data by the region or network set associated with an IP address and applies when the destination has already been resolved. It relies on local rule data, so its scope and update time affect the result. GeoIP does not interpret domain meaning directly; a domain generally must be resolved before it can be matched by address.
GeoSite: GeoSite is rule data organized into domain sets for matching groups of site domains. Its match target differs from GeoIP: GeoSite focuses on domains, while GeoIP focuses on addresses. Check whether the core still preserves the destination domain and whether the relevant category exists in the current data file.
DNS: DNS resolves domain names to network addresses, and the result may then feed GeoIP and routing decisions. The V2Ray core can use dedicated DNS servers, query strategies, and matching conditions; system DNS and built-in DNS may also work at the same time. When troubleshooting a domain connection, first distinguish resolution failure from node connection failure.
FakeDNS: FakeDNS first assigns a synthetic address to a domain, then restores the original domain inside the core for further processing. It is often paired with TUN mode so applications that provide only a destination address can still be routed by domain. The address pool, DNS interception, and routing configuration must be coordinated.
DNS leak: A DNS leak occurs when domain queries expected to use a designated path are sent directly through the operating system or another resolver. Check the OS DNS, the client's built-in DNS, TUN interception scope, routing rules, and browser secure DNS. The key fix is to unify the resolver entry point and query outbound, not merely switch nodes.

LAYER 05 / CLIENT

Clients & Platforms

Clients bring subscription management, node selection, system entry points, and core status into one interface. System proxies and TUN mode receive traffic, while inbound and outbound settings describe how traffic moves through the core afterward.

System proxy: A system proxy is a proxy configuration entry provided by the operating system. Applications that read it send requests to the specified local port, but enabling it does not automatically cover every program; some use an independent network stack or their own proxy settings. Troubleshooting should verify both the client's listening port and the system setting.
TUN mode: TUN mode receives system traffic through a virtual network interface and passes it to the core for DNS, routing, and outbound processing. It usually covers more applications than a system proxy but depends more on system permissions, the virtual interface state, and DNS interception. After enabling it, avoid duplicate interception by other virtual network components.
Inbound: An inbound is the entry configuration through which the core receives connections from local applications, LAN devices, or virtual interfaces, corresponding to inbounds in JSON. The listen address, port, and inbound protocol determine how traffic enters the core. A system proxy usually points to a local HTTP or SOCKS inbound port.
Outbound: An outbound is the configuration the core uses to send matched connections along their destination path, corresponding to outbounds in JSON. Node connections, direct connections, and blocking actions can each be represented by a different outbound. Routing rules reference them by tag, so tag spelling and references must match.
v2rayN: v2rayN is a graphical desktop client for Windows, macOS, and Linux that manages subscriptions, nodes, system proxies, routing, and the core. Desktop editions and the classic WPF edition use different UI frameworks, so choose an installer that fits the system environment. Client updates and core updates are separate layers; check their version information independently.
v2rayNG: v2rayNG is a graphical client for Android that typically uses the Xray core to handle protocols, DNS, and routing. After importing a subscription, select an active node and start the connection; seeing a node list alone does not mean system traffic is connected. Battery-saving policies, background permissions, and virtual network authorization can affect continued operation.