CONFIGURATION GLOSSARY
This guide breaks down the key terms found in client interfaces and node details. Each entry starts with a plain-language note, then explains where the term appears in configuration, how it differs from related concepts, and what to check when verifying parameters.
CATEGORY INDEX
When you are unsure which layer a term belongs to, start with where it is used: the protocol defines the connection format, the core executes the configuration, the subscription supplies nodes, the transport layer carries the connection, and routing rules determine where traffic goes.
PROTOCOL & SECURITY
Protocols define authentication and data encapsulation, while the security layer protects the transmission. Matching protocol names in a client do not mean the other parameters can be mixed and matched.
VMess is an early, widely used proxy protocol in the Project V ecosystem. Nodes typically include a user ID, address, port, and transport parameters. It is sensitive to clock differences between the client and server, so an incorrect device time can cause authentication failures. VMess and transports such as WebSocket and TCP belong to different layers; after importing a node, continue by checking the transport fields.
VLESS uses a relatively streamlined protocol structure and typically does not provide complete transport encryption by itself. In practice, nodes often combine VLESS with TLS, REALITY, or XTLS Vision, with the corresponding layer providing the security features. When checking a VLESS node, review the user ID, transport method, security type, and flow-control field together.
Trojan typically authenticates clients with a password and establishes the connection over TLS. The password, server name, port, and certificate-related settings must correspond to one another. Its authentication fields differ from VLESS, so changing only the protocol selector does not make all previous parameters valid.
REALITY is a secure transport solution in the Xray ecosystem, often used with VLESS and XTLS Vision. Clients typically require a server name, public key, short ID, and fingerprint; enter each value according to the node details. REALITY is not a standalone client name and cannot replace the node's protocol type.
TLS protects connection contents and verifies communication endpoints; HTTPS on the web is also built on this protocol family. In V2Ray configurations, TLS usually appears as a transport security option associated with the server name and certificate domain. Protocol and TLS fields belong to different layers, so enabling one does not mean the other will match automatically.
CORE & CLIENT
The core parses configuration, establishes connections, and applies routing. Built on top of the core, the client provides subscription management, node selection, and system settings interfaces.
Project V is an open-source technology ecosystem built around proxy protocols, transports, and routing capabilities, with V2Ray as one of its major projects. In everyday usage, “V2Ray” may refer to the core or more broadly to clients compatible with related configurations. Use the context to determine whether the documentation means the protocol ecosystem, a core, or a graphical client.
V2Fly continues V2Ray's community-maintained direction, with common configurations still organized into modules such as inbounds, outbounds, routing, and DNS. It shares many foundational concepts with Xray, but supported protocol extensions and fields may differ. When migrating a configuration, follow the options supported by the target core.
Xray shares much of the V2Ray configuration structure and extends it with capabilities such as VLESS, XTLS Vision, and REALITY. Many clients wrap Xray parameters in their interfaces, so users may not need to edit the complete JSON directly. If a field is not recognized, first confirm which core the client is currently using.
v2rayN targets Windows, macOS, and Linux, offering subscription updates, node management, routing modes, and system proxy controls. It is a management interface, not the VMess or VLESS protocol. Whether a configuration works also depends on the bundled core, node parameters, and local network settings.
v2rayNG is an Android graphical client that typically uses the Xray core for node connections and routing. After importing a subscription, the client converts the node details into server entries in its interface. Selecting a node only chooses the active configuration; you must also start the connection and verify its status with an actual request.
v2flyNG follows the V2Fly core line and suits scenarios that require its behavior and configuration compatibility. Its interface concepts resemble v2rayNG, but the underlying core is different. When choosing a client, check whether the subscription's protocol types and transport parameters are supported.
SUBSCRIPTION & NODE
Subscriptions handle batch updates, while a node represents one specific connection. Speed-test results describe only the moment of testing and cannot replace checking the protocol and parameters.
A subscription is a server-managed way to update a node list. After saving the subscription URL, the client can fetch its contents on demand. Adding a subscription URL and updating the subscription are separate actions; after adding it alone, the node list may still be empty. Updates may also replace old node names and parameters, so confirm whether a later update will overwrite manual changes before editing them.
A node is a complete set of remote connection parameters in a client, usually including the protocol, server address, port, authentication details, and transport settings. One subscription can contain multiple nodes, each with different protocols and network conditions. A node name is only an identifying label and does not indicate actual speed or availability.
A share link wraps the parameters of a single node with a protocol prefix, commonly starting with vmess://, vless://, or trojan://. The client parses the address, port, user information, and query parameters in the link. Missing the final characters or truncating the link at a line break can produce an incomplete import.
Base64 converts content into printable characters, making it convenient for subscription bodies or sharing text. It is an encoding, not encryption, and does not indicate which security protocol a node uses. Clients usually detect and decode it during import; manual editing can easily damage the original structure.
Latency is the time between sending data and receiving a response, but different test buttons may use different methods. Values from network probes, TCP connection establishment, and real proxy requests are not directly comparable. When assessing a node, also consider the stability of repeated requests rather than relying on a single result.
Real connection latency measures the time required to establish an actual proxy connection and complete the target request, including the protocol handshake and transport layer. It better reflects everyday access conditions than a simple network probe. A failed test means that the complete request did not finish; check the logs to determine whether the cause is an invalid parameter, node status, or local setting.
TRANSPORT SETTINGS
The transport layer describes how proxy data is carried over a network connection. The transport type, path, service name, and security parameters must correspond between the client and server.
streamSettings is the group of fields in a V2Ray JSON configuration that describes the underlying transport and security layer. It may include the network type, security type, and detailed parameters for WebSocket, gRPC, TLS, or REALITY. When troubleshooting a connection, do not inspect only protocol; compare this entire group with the node details field by field.
TCP is a connection-oriented, reliable transport protocol and an optional underlying carrier for many proxy protocols. When an interface shows TCP, proxy data is sent over a TCP connection either directly or with additional headers. It is not the same field as the node's VMess, VLESS, or Trojan protocol type.
WebSocket establishes persistent two-way communication through HTTP's connection-upgrade mechanism and is often abbreviated as ws in configuration. A node may also require path and host fields, which must match the server entry point. Slashes, capitalization, and extra characters in the path are all part of the actual parameter.
gRPC is a remote procedure call and streaming mechanism built on HTTP/2. In V2Ray nodes, a service name commonly identifies the service entry point, and the client and server values must match. gRPC and WebSocket cannot be swapped arbitrarily within the same transport field.
SNI is the target server name supplied during the TLS handshake; client interfaces may also label it as serverName. It is usually a domain name rather than the displayed node name and should correspond to the security-layer configuration. An incorrect value can prevent the TLS or REALITY handshake from completing as expected.
ROUTING & SPLIT
The routing system reads request characteristics and selects an outbound. System proxy and TUN determine how traffic enters the client, while split-tunneling rules determine which exit handles it.
Routing rules select an outbound based on conditions such as domain, IP address, port, network type, or protocol. When multiple rules are present, their order and matching behavior affect the final result. After changing rules, test both proxied and direct destinations to confirm that each type of request follows the intended path.
Split tunneling is a configuration method that sends different requests to different outbounds, such as a proxy, direct connection, or block action. Common criteria include domain categories, IP ranges, and destination addresses generated by applications. It does not change the node protocol; it only determines whether a given request uses that node.
GeoIP organizes data by the region or network range associated with an IP address and can be used as a routing match condition. It matches resolved addresses, not page titles or node names. Because the data is updated periodically, interpret results together with the current rule set.
GeoSite organizes domains into collections by purpose or category, and routing rules can reference a collection name directly. This reduces one-by-one domain maintenance, but the exact contents of each category depend on the data version used by the client. GeoSite matches domains, while GeoIP matches addresses; they can be used together.
A system proxy writes the client's local listening address to the operating system's proxy settings, so applications that follow those settings send requests to the client. Some applications use their own network settings, so system-proxy coverage is not fixed. Restore the system proxy state before closing the client to prevent applications from continuing to target a stopped local port.
TUN mode receives system traffic through a virtual network interface and usually covers more traffic than a standard system proxy. It involves the routing table, DNS, and local network permissions, so troubleshooting requires checking more areas. If the system proxy works but TUN does not, inspect the virtual interface status, DNS settings, and split-tunneling rules separately.
FakeDNS temporarily assigns reserved addresses to domains and stores the domain-to-address mapping inside the client. When later traffic reaches that address, the client can restore the domain name and continue applying domain-based routing. It must work together with TUN, DNS, and routing settings; it is not an ordinary public DNS address.
A DNS leak occurs when domain lookups do not follow the intended resolution path, causing the DNS exit to differ from the traffic-routing policy. Common checkpoints include system DNS, client DNS, browser-specific settings, and TUN interception status. First decide whether lookups should use a direct connection or proxy, then align the corresponding rules.