V2Ray Glossary: Protocols, Cores, Subscriptions, Routing and DNS

Protocols and transport

Combining protocols with transport and security layers

A protocol defines how the client and server organize authentication and data. The transport carrier and security layer are usually configured separately, so a protocol name alone is not enough; also check fields for TLS, REALITY, WebSocket, or gRPC.

VMess protocol: VMess is an early client–server communication protocol in the Project V ecosystem. Its configuration typically includes a user identifier, server address, port, and transport method. It is distinct from underlying carriers such as TCP and WebSocket, so review them separately.

VLESS protocol: VLESS is a lightweight communication protocol that does not provide transport-layer encryption itself. In practice it is commonly paired with TLS or REALITY and uses a UUID to identify the user. When troubleshooting, check the protocol, security layer, and transport parameters separately.

Trojan protocol: Trojan uses TLS to organize authentication and data transfer, with authentication typically represented by a password field. Client settings also require the server address, port, and server name. A successful TLS handshake does not guarantee successful authentication; assess the two stages separately.

REALITY security layer: REALITY is a transport security solution in the Xray ecosystem, commonly used with VLESS. Client settings generally include a public key, short ID, server name, and fingerprint. It is a security layer, not a standalone application protocol that replaces VLESS.

Cores and clients

The configuration execution layer and graphical control layer

The core handles connections, inbounds, outbounds, routing, and DNS, while the graphical client organizes these capabilities into an interface. Client names and core names are not interchangeable, and a client may use different cores depending on its version and settings.

V2Ray ecosystem: V2Ray commonly refers to the network toolset in the Project V ecosystem and, depending on context, to related cores. Its configuration usually consists of modules for inbounds, outbounds, routing, DNS, and policies. Read the context carefully to determine whether it means the ecosystem, a core, or a configuration format.

V2Fly core family: V2Fly is a community project and core family that continues the V2Ray technology line. Its configuration is organized around modules such as inbounds, outbounds, routing, and DNS. Some fields resemble those of other core families, but supported features should be checked against the current core version.

Xray core family: Xray is a core family with many concepts shared by the V2Ray configuration model. It supports protocol and security combinations such as VLESS and REALITY and is invoked by graphical clients. If a field is not recognized, first confirm which core the client is actually using.

v2rayN desktop client: v2rayN is a graphical client for Windows, macOS, and Linux. It manages subscriptions, individual server profiles, routing rules, DNS, and system proxy settings. Interface options are ultimately converted into runtime configuration readable by the core.

v2rayNG Android client: v2rayNG is a graphical Android client that typically uses the Xray core. It can import subscriptions or share links and provides per-app proxy, routing, and DNS settings. Background operation is also affected by the system’s battery policies and network permissions.

Subscriptions and server profiles

Configuration sources, server entries, and test results

A subscription delivers configurations in batches, a server profile is one server record in the client, and latency is a result produced by a specific test method. They solve different problems: a successful subscription update does not mean every profile connects, and low latency does not guarantee a stable end-to-end session.

Subscription subscription: A subscription is a set of configuration endpoints provided centrally by a service. The client uses the subscription URL to retrieve server entries. Updating it usually reparses remote content and merges or replaces existing records according to client rules. An expired link, changed format, or failed request can affect the result.

Server profile server profile: A server profile is one server connection configuration in the client list. It typically includes the address, port, protocol, authentication, transport method, and security parameters. “Server profile” is a convenient interface term; in configuration files it usually corresponds to an outbound or a group of related fields.

Latency latency: Latency is the time from a client-initiated test to the received response, usually shown in milliseconds. Different tests may check only TCP connection setup, an HTTP response, or another stage, so their results are not directly comparable. Latency mainly indicates responsiveness and does not by itself represent transfer performance.

Real connection latency real delay: Real connection latency measures response time by establishing a connection closer to the actual usage flow. It usually includes more steps, such as the core outbound, protocol handshake, and target request. The test target, timeout, and current network conditions all affect the final value.

Routing and traffic splitting

Traffic matching order and outbound selection

The routing module does not change protocol parameters; it decides which outbound handles a connection. Rules are generally checked in order, and the domain, IP, port, and inbound tag may all affect the decision. Rule placement and DNS results can therefore change the final path.

Routing rule routing rule: A routing rule determines which outbound handles traffic based on the domain, IP, port, protocol, or inbound tag. Multiple rules are usually evaluated in configuration order, so the first match affects subsequent processing. After changing rules, save the configuration and restart or reload the current core.

Traffic routing traffic routing: Traffic routing sends traffic for different destinations to different outbounds according to conditions. Common conditions include domain categories, IP ranges, application entry points, and destination ports. Results depend on rule order, DNS results, and whether each outbound is configured correctly.

GeoIP IP dataset: GeoIP matches IP addresses against geographic sets. It is typically used as an IP condition in routing rules and requires a resolved destination address first. Data-file versions affect the covered address ranges, so matches may change after an update.

GeoSite domain dataset: GeoSite is a collection of domains organized by purpose or category that can be referenced in routing and DNS rules. It matches domain rules rather than GeoIP address ownership. Category names and contents depend on the data files used by the client.

TUN mode virtual interface: TUN mode receives system traffic through a virtual network interface and can cover applications that do not read system proxy settings. It involves the routing table, DNS interception, and virtual-interface permissions, making its scope broader than a regular system proxy. Avoid having multiple virtual networking tools intercept the same traffic.

System proxy system proxy: The system proxy is the proxy address and port exposed by the operating system for compatible applications to read. v2rayN typically points it to the client’s local listening port, after which the core selects the outbound. Programs that ignore system proxy settings need separate configuration or may require TUN mode.

DNS and resolution

Domain queries, mapped addresses, and resolver paths

DNS settings determine which resolver receives domain queries, how results are filtered, and which path carries the queries. When routing rules depend on domains or IPs, DNS results may also affect matching, so resolution and traffic routing should be checked together.

DNS name resolution: DNS is the basic service that resolves domain names to IP addresses. V2Ray can specify multiple resolvers and use domain categories, query types, or expected address ranges to determine selection order. System DNS, core DNS, and application-level resolution may coexist, so identify the actual query path.

FakeDNS address mapping: FakeDNS first returns a mapped address to the application, then lets the core restore the original domain from the mapping and process the traffic. This helps preserve domain information when intercepting IP traffic. The address pool, TUN settings, and routing rules must work together.

DNS leak unexpected resolver path: A DNS leak occurs when domain queries bypass the intended resolver path and are sent directly to another resolver by the system or another network component. Check the browser’s built-in secure DNS, system DNS, TUN coverage, and core routing. It describes a path deviation, not an ordinary resolution failure.

DoH DNS over HTTPS: DoH sends DNS queries over HTTPS, with the resolver usually represented by a URL. Configuration must account for how that URL’s domain is initially resolved and which outbound sends the query. Entering a DoH address alone does not determine the routing of all DNS traffic.

Security and encryption

Identity fields, handshake parameters, and transport protection

Authentication fields identify the connection, while security layers such as TLS protect the transfer; they serve different roles in configuration. For troubleshooting, separate address reachability, protocol authentication, security handshaking, and application requests into distinct stages instead of inferring everything from one error.

TLS transport security: TLS provides encryption and authentication for connections and is commonly combined with VLESS and Trojan configurations. Client fields typically include the server name, certificate verification, application-layer protocol, and fingerprint. The server name is used for handshake verification and should not simply be treated as a duplicate of the server address.

UUID identifier: UUID is an identifier made of hexadecimal characters in a fixed format and is commonly used as the user identity field in VMess and VLESS configurations. It is neither a server address nor a local listening port. Preserve every character and hyphen when copying it.

Fingerprint TLS fingerprint: In relevant client settings, a fingerprint usually refers to TLS handshake characteristics. Some cores allow a preset to be selected to adjust client handshake behavior. This field must match the security layer and server configuration; it cannot replace the server name, public key, or authentication details.

Transport encryption encryption layer: Transport encryption protects data exchanged between the client and server and should be distinguished from protocol authentication and the transport carrier. TLS, REALITY, and protocol fields occupy different configuration layers, with their combination determined by the server setup. Whether the client’s local listening port is encrypted is a separate issue.

How to read the glossary

From interface labels back to configuration layers

A graphical client may combine several configuration fields into one toggle or dropdown. For example, “Enable TUN” may involve a virtual interface, DNS interception, the routing table, and a local inbound at once. When troubleshooting, first determine whether the client is using the system proxy or TUN, then check whether the request reaches the client.

A protocol name alone does not describe the complete connection. With VLESS, for example, also confirm whether the security layer is TLS or REALITY, which transport is used, and whether the server name matches the user identity. Checking fields by protocol, transport, security, and routing layers is usually more effective than repeatedly switching server profiles.

A subscription update only retrieves configuration content; it does not prove that every server profile can connect. For update failures, first check the link format and request process. If import succeeds but the connection fails, check the profile fields, core logs, system time, DNS, and routing settings.

V2Ray Protocol, Core, and Configuration Glossary

Browse by topic