Glossary · 24 common terms

V2Ray Glossary
Protocols, cores and routing

Look up concepts by where they fit in the configuration. Start by distinguishing the client from the core, then see how connections enter, which rules route them and where domains are resolved.

How connections are handled · Overview
How apps, cores, rules, and outbounds relate Apps send traffic to the core through a local inbound. The core selects an outbound using routing rules, while DNS resolves domain names. App Core Outbound Routing rules DNS lookup
The inbound receives traffic; rules decide where it goes.
Connection parameters

Protocols and transports

A protocol defines communication and authentication; transport and security layers determine how a connection is carried and protected. The same protocol can use different transports, and matching names do not mean every parameter matches.

Protocols and transports

VMess

VMess protocol

A proxy protocol in the Project V ecosystem, with user authentication and data encryption. The client and server must use matching user IDs and connection parameters. A large time difference between devices can also affect authentication. When troubleshooting, check protocol parameters, transport and security layer separately; a transport is not the same thing as VMess.

Protocols and transports

VLESS

VLESS protocol

A lightweight proxy protocol that does not encrypt application data on its own. It is usually paired with a security layer such as TLS or REALITY. Check the user ID, transport and security-layer parameters together; the protocol name alone does not establish compatibility. Some flow-control options require a specific core and transport, so do not add them without instructions from the server provider.

Protocols and transports

Trojan

Trojan protocol

A proxy protocol that typically uses TLS for a secure connection and a password for authentication. A correct password is not enough on its own: the server address, port, server name and certificate trust settings must also match. For certificate errors, check the domain name and device time before considering any change to certificate verification.

Protocols and transports

Shadowsocks

Shadowsocks protocol

A protocol that carries proxy traffic using an agreed encryption method and key information. The client and server must support the same encryption method; methods from different generations cannot interoperate just because they use the same password. If an imported configuration reports an unsupported method, check the selected core's supported features and the original configuration rather than repeatedly changing routing modes.

Protocols and transports

REALITY

REALITY security

A secure transport mechanism in the Xray ecosystem, not a standalone subscription format or another name for VLESS. Connections typically require matching parameters such as the public key, server name and short ID; the exact fields depend on the server configuration. A client recognizing an imported link does not mean the selected core supports the feature.

Software layers

Cores and ecosystem

Project V is the ecosystem; V2Fly and Xray are core families; names such as v2rayN refer to user interfaces. Knowing which layer you are dealing with helps you find the right setting to change.

Cores and ecosystem

Project V

Project V ecosystem

The open-source project background and technical ecosystem built around V2Ray and related networking tools. Project V is neither a specific graphical client nor an account service that provides nodes or subscriptions. When reading documentation, distinguish the ecosystem's history, core capabilities and individual client features rather than assuming one applies to every program.

Cores and ecosystem

V2Fly

V2Fly core

A community project that continues V2Ray development and one of the commonly used proxy core families. The core handles settings such as inbounds, outbounds, routing and DNS; the client provides the graphical interface. v2flyNG is based on the V2Fly core, so check that the imported protocol and parameters are supported by that core before using them.

Cores and ecosystem

Xray

Xray core

An open-source core fork originating in the V2Ray ecosystem, with support for multiple proxy protocols and related transport features. Xray and V2Fly share some concepts, but their newer features, configuration fields and support differ. v2rayNG uses the Xray core; when troubleshooting a specific protocol, check the core actually in use, not just the client name.

Cores and ecosystem

Clients and cores

Client / Core

A client is the interface for importing subscriptions, selecting nodes and changing settings. The core is the program that handles network connections. v2rayN, v2rayNG and v2flyNG are graphical client names, not three proxy protocols. If the interface starts but connections fail, check the core logs next. For help choosing a client, see Client Comparison.

Configuration sources

Subscriptions and nodes

A subscription distributes configuration, a node contains connection parameters, and a test result describes how a request performed at a particular time. These refer to the source, the configuration and the observed result, respectively.

Subscriptions and nodes

Subscription

Subscription

A URL or collection of data used to fetch and update server configurations in bulk, usually provided by a service you already use. Updating a subscription changes configuration data; it does not renew a service, fix a route or change the server's status. A subscription URL may contain account credentials, so treat it as sensitive information and remove access details before sharing screenshots or logs.

Subscriptions and nodes

Node

Server profile / Node

A common client term for a server connection profile, typically containing an address, port, authentication details and transport parameters. A node entry does not necessarily represent a separate physical server, and its display name alone cannot confirm the actual egress location. Keep track of the source before editing an entry; a subscription refresh may overwrite local changes to that entry.

Subscriptions and nodes

Subscription groups

Subscription group

A client feature for organizing server entries by configuration source or use case. Groups can help manage subscription updates, filter lists and identify sources, but they do not necessarily provide load balancing or automatic failover. If entries are duplicated, check their groups and subscription sources before deleting anything, so you do not remove a configuration saved manually by mistake.

Subscriptions and nodes

Latency

Latency

The time taken by a particular test. Its meaning depends on the method: a TCP connection test, a request test and a full proxy-path test measure different stages, so their results are not directly comparable without considering the test goal. A lower value does not mean faster downloads, and timeouts should be assessed alongside the target address, network conditions and logs.

Subscriptions and nodes

Real connection latency

Real connection latency

A term some clients use for the time taken to reach a test URL through a proxy outbound. It is closer to the real request path than simply checking whether a server port is open, but results still depend on the test URL, DNS, handshakes and current network conditions. Use it to compare nodes under the same test conditions; it cannot predict video load times or download bandwidth.

Traffic routing

Routing and traffic rules

Match connection attributes first, then choose the appropriate outbound. Referenced data resources, rule order and outbound tags all matter. A short example phrase is not a complete configuration you can import.

Routing and traffic rules

Routing rule

Routing rule

A configuration rule that selects an outbound for a connection based on conditions such as its domain, IP, port or inbound tag. Rules commonly match in order, and the first match determines where traffic goes, making rule order and outbound tags important. Before adding a rule, identify what it should match and where it should send traffic, then check whether a broader rule above it would already match the connection.

Routing and traffic rules

Traffic routing

Traffic routing

Sending different connections to different outbounds based on conditions, such as direct, proxy or block. Routing happens after traffic enters the core; it does not replace the settings needed to send application traffic to the local proxy in the first place. Modes such as Global and Bypass Mainland China are usually labels for preset routing policies; check the rules currently generated by the client to confirm their actual behavior.

Routing and traffic rules

GeoIP

IP address sets

A categorized set of IP addresses used by routing rules for matching. geoip:private is commonly used to match private network address ranges. The exact entries depend on the rule data in use. Geographic categories are data labels, not a guarantee of a service's actual location; for domain connections, whether IP matching happens also depends on the domain resolution strategy.

Routing and traffic rules

GeoSite

Domain name sets

A categorized set of domains used for domain matching in routing rules. Labels such as geosite:cn refer to categories in a rule data resource, not a live location lookup or a DNS result. Before using one, confirm that the relevant resource is available and includes the category; updates to category data can also change which rules match.

Routing and traffic rules

Outbound

Outbound

The configuration the core uses to send a connection to its destination. An outbound can use a proxy protocol, connect directly or block the connection. Routing typically selects an outbound by its tag; a tag is a configurable identifier, not a fixed protocol name. If a rule specifies proxy, a matching outbound definition must exist. Changing the tag alone does not create a new connection capability.

Traffic entry and resolution

DNS and networking

Whether an application sends traffic through the proxy, which resolver handles a domain, and where the connection ultimately exits are three separate questions. When something goes wrong, checking each layer in turn is more useful than changing several switches at once.

DNS and networking

DNS

Domain Name System

The network system that resolves domain names to IP addresses and other records. The operating system, individual applications and the proxy core may each perform DNS resolution, so changing one setting does not mean every request follows the same resolution path. To troubleshoot, first identify which program makes the query, which resolver it uses and which outbound carries the query, then look at specific options such as caching or encrypted DNS.

DNS and networking

TUN mode

Virtual network interface

A way to receive traffic through a virtual network interface and pass it to the appropriate networking component for forwarding. TUN mode usually covers more applications than a system proxy, but its actual scope depends on routing, permissions, implementation and application behavior. Also check DNS interception and local network access when enabling it; TUN is not simply another name for a global proxy switch.

DNS and networking

FakeDNS

Synthetic IP mapping

A mechanism that returns synthetic IP addresses to applications for internal mapping, then maps those addresses back to the original domains for later connections. It can preserve domain information, but requires DNS interception, a mapping address range and traffic capture to work together. A synthetic address is not the website's real server address; connections may fail if they bypass the component responsible for restoring the mapping.

DNS and networking

DNS leak

DNS leak

A DNS query that leaves the intended resolution path and is handled by another resolver. Whether this counts as a leak depends on the intended policy; not every direct DNS query is a problem. Check the browser's built-in resolver, system DNS, core DNS and the outbound used for queries. Seeing a resolver name on a test page alone is not enough to identify the cause.

DNS and networking

System proxy

System proxy

A local proxy address and port registered with the operating system for applications that follow the system proxy settings. It does not guarantee that every program will send traffic through the proxy, and it does not decide whether connections reaching the core go direct or through a proxy. If a browser still points to a stopped local port after you close the client, it may lose network access; check that the system proxy settings have been restored.