V2RAY GLOSSARY
From VMess, VLESS, and REALITY to subscriptions, routing rules, TUN mode, and FakeDNS. Each entry explains what it does, where it appears, and which settings are easy to confuse.
Start with a category, then follow the related settings in each entry. Protocol names answer “what format does the connection use?”, core names answer “which program executes the configuration?”, and client names indicate “which graphical interface manages the core?”
01 · PROTOCOL
Protocols define authentication and data-exchange formats, while TLS, REALITY, and similar mechanisms handle transport-layer authentication or encryption. When importing a configuration, the protocol type and its parameters must match as a set.
VMess is an early protocol in the Project V ecosystem that authenticates connections with a user identifier and time information. A configuration typically includes the server address, port, UUID, alter ID, and transport method.
Key fields must match between the client and server. A significant clock difference, incorrect user identifier, or mismatched transport parameters can terminate the connection during authentication.
VLESS is a lightweight authentication protocol that separates user authentication from transport settings. It does not provide complete transport encryption by itself and is commonly paired with TLS or REALITY.
Common fields include UUID, flow, encryption, network, and security. When using XTLS Vision, the flow values on the client and server must correspond.
Trojan authenticates clients with a password and typically runs over a TLS connection. The client needs the server address, port, password, and server name matching the certificate.
When troubleshooting a failed connection, check the password, SNI, system time, and certificate chain separately. An open port does not prove that the TLS handshake and protocol authentication completed.
REALITY is a transport security solution in the Xray ecosystem, commonly paired with VLESS. Client settings typically include serverName, publicKey, shortId, spiderX, and a fingerprint type.
publicKey and shortId come from the server configuration, while serverName is used during the handshake. A mismatch in any field can cause the handshake to stop or the connection to close immediately after opening.
XTLS Vision is one of Xray’s flow-control methods, commonly configured as xtls-rprx-vision. It usually appears in VLESS’s flow field and specifies how the core handles connection data.
This is not a standalone node protocol. The server, client, and core versions in use must support the same flow-control configuration.
TLS encrypts network connections and authenticates servers, and is widely used for websites and many proxy transports. Common related fields in V2Ray clients include security, serverName, allowInsecure, and fingerprint settings.
The certificate domain, SNI, and server address do not have to be identical, but they must match the server’s deployment. An incorrect system clock can also make a valid certificate appear not yet valid or expired.
02 · CORE
The core reads the configuration and handles actual connections, while the client provides graphical controls for subscriptions, nodes, logs, and the system proxy. They serve different roles, and client support for a setting still depends on the core’s capabilities.
Project V is an open-source technology ecosystem centered on proxy protocols, routing, and network tools. V2Ray’s early configuration structure and core concepts became an important foundation for later cores and clients.
When reading documentation, distinguish the ecosystem name, core projects, and graphical clients. They are related, but they are not alternate names for the same software.
Xray is a core branch in the V2Ray ecosystem that supports VLESS, REALITY, XTLS Vision, and related features. v2rayN and v2rayNG often use it to handle connection, routing, and DNS configuration.
“Switch core” in a client means changing the underlying program that executes the configuration. Before switching, confirm that the target core supports the node’s protocol, transport, and configuration fields.
V2Fly is a core line maintained by the Project V community. It retains V2Ray’s configuration structure and provides modules for inbounds, outbounds, routing, DNS, and policies.
It shares many foundational concepts with Xray, but supported features and specific fields may differ. When copying a configuration, follow the documentation and startup logs for the core actually in use.
v2rayN is a graphical client for Windows, macOS, and Linux that manages subscriptions, nodes, the system proxy, routing rules, and cores. The desktop edition and classic WPF edition use different UI technologies, but their core workflows are similar.
The client generates the configuration and controls the core process. When startup fails, check both the client message and core logs instead of repeatedly switching nodes.
v2rayNG is an Android graphical client that typically uses the Xray core. It supports subscription imports, QR code or share-link imports, node switching, routing modes, and per-app proxying.
System battery restrictions, background execution policies, and local virtual network permissions can affect persistent connections. When a connection drops, check these system settings as well as the node parameters.
v2flyNG is an Android graphical client built around the V2Fly core line, with controls similar to those of common mobile clients. It suits scenarios requiring V2Fly configuration behavior or protocol compatibility.
When choosing v2flyNG, confirm that the node’s protocol and transport are supported by the V2Fly core. A configuration containing core-specific fields may fail to start after direct import.
03 · SUBSCRIPTION
A subscription distributes configurations in bulk, while a node represents one specific connection record. Updating a subscription rereads remote content, so local renaming, filtering, and grouping should be considered alongside the update policy.
A subscription is a URL containing a set of nodes generated by a service provider. After reading it, the client parses its share links or structured configurations and creates an updatable node list.
Subscription updates commonly fail because the address was copied incompletely, the link changed, the network request failed, or the returned format is unsupported. Update logs usually distinguish request errors from parsing errors.
A node is one server configuration in a client, usually containing an address, port, protocol, user identifier, and transport parameters. The node name is only a label for identification and does not participate in connection authentication.
Nodes in the same subscription may use different protocols or transports. When copying a node’s parameters, do not copy only the server address and port.
A share link encodes one node’s parameters as importable text. Its protocol prefix tells the client which parsing rules to use. Some links expose fields directly, while others encode the configuration.
Share links are suited to importing a single configuration; subscription URLs are suited to managing node collections that change over time. Clients generally provide separate import paths for them.
Latency is the time required for data to make one round trip between the local device and the target, usually shown in milliseconds. It is affected by the local network, route, server load, and test target.
Clients may test with port probes, HTTP requests, or complete proxy connections, so results cannot be compared directly. A single test value also does not represent long-term connection performance.
Real connection latency establishes an actual connection through the proxy and measures the time taken to reach a specified test target. It reflects protocol authentication, transport handshakes, and outbound access more accurately than a basic port check.
A failed test means that some part of the complete path did not finish, but the result alone cannot identify the fault. Check DNS, the handshake, and routing details in the client logs.
A subscription group is a client-side unit for organizing node collections from different subscription sources. Each group can have its own update URL, enabled state, filters, and update history.
When multiple subscriptions contain similar node names, groups make their configuration sources easier to identify. Deleting a group usually also removes nodes generated by that subscription, so confirm local management rules first.
04 · ROUTING
The routing module does not perform protocol authentication; it decides which outbound should handle a request. Rule scope, order, DNS results, and the client’s operating mode all affect the final match.
Routing rules use domain, IP, port, network type, protocol, or process information to select an outbound. Common outbounds include proxy, direct, and block, with exact names determined by the client-generated configuration.
Rules are usually matched from top to bottom. More specific rules should come before general ones, or a broad condition may match first.
Traffic routing sends different network requests through different outbounds. For example, paths can vary by domain category, IP range, app process, or destination port.
The result depends not only on the rule text but also on DNS resolution and operating mode. During troubleshooting, confirm whether the request enters routing as a domain or an IP address.
GeoIP is a dataset organized by IP address region or network category and can be used as an IP matching condition in routing. It reduces the need to maintain large ranges manually.
GeoIP data needs regular updates because address assignments change. A rule can participate in matching only when the destination IP is available during routing.
GeoSite is a domain collection organized by purpose or category and is commonly used to match related websites in bulk. Rules may cover full domains, subdomains, or categories, depending on the dataset.
GeoSite matches domain information, while GeoIP matches IPs at a different stage. Complex routing configurations often use both types of rules together.
TUN mode captures system traffic through a virtual network interface, including traffic from some apps that ignore system proxy settings. The client passes traffic entering the interface to the core, which selects an outbound according to routing rules.
When enabling it, pay attention to virtual interface permissions, DNS interception, the routing table, and local network access. Other network tools that modify system routes may overwrite one another’s rules.
The system proxy is the operating system’s proxy configuration interface. After v2rayN enables it, the client writes its local listening address into system settings, and apps that follow those settings send requests to the client.
Not every program reads the system proxy, so its coverage is usually narrower than TUN mode. Restore the system proxy state before closing the client to prevent apps from using a stopped local port.
05 · NETWORK
DNS, SNI, and local listening ports belong to different processing stages. Understanding domain resolution, TLS server-name selection, and how apps hand traffic to the client helps locate connection problems.
DNS is the basic network service that resolves domain names to IP addresses. The V2Ray core can use system results or route different domains to designated resolvers according to its configuration.
DNS settings affect domain access and routing decisions. When results are unexpected, check the resolver, query path, cache state, and how routing handles DNS traffic.
FakeDNS returns a mapped address to an app while retaining the relationship between that address and the original domain in the core. When the connection reaches the core, it can restore the domain and apply domain-routing rules.
It is commonly used with TUN mode. Its purpose is to preserve domain information rather than provide ordinary public DNS results. The address pool must not conflict with real local network ranges.
A DNS leak occurs when a query expected to use a designated path is instead sent by the system or another resolver path. This can make DNS results diverge from traffic-routing rules or give an app a different destination address.
Check system DNS, client DNS, the browser’s own resolution settings, and the scope of TUN interception. Changing one resolver address may not alter every query path.
SNI is the field in a TLS handshake that identifies the target server name and commonly corresponds to serverName in client configuration. The server can use it to select a certificate and site configuration.
An SNI mismatch can cause a certificate-domain error or handshake failure. Compare the node’s value with the server’s actual deployment parameters item by item.
A local listening port is opened by the client to receive app traffic. SOCKS, HTTP, and mixed inbounds can listen on separate ports or be managed centrally by the client.
When another program occupies the port, the core usually cannot start the corresponding inbound. Messages such as address already in use generally require closing the conflicting program or changing the local port.