Configuration term index

V2Ray Glossary

Browse protocols, cores, and client settings by configuration layer.

When you encounter an unfamiliar field, first identify which layer it belongs to. Protocols define how the two ends communicate; transports determine how traffic is carried; the core handles connection logic; and the client organizes the configuration. Similar-looking options are not necessarily interchangeable. This page explains the distinctions; for specific steps, see Deep Dive.

Protocols & Transports

First distinguish authentication, transport, and connection security. The same protocol can use different transport settings.

VMessProxy protocol · user ID authentication: VMess is a proxy protocol in the Project V ecosystem that authenticates users with an ID and includes its own security mechanisms. Modern configurations typically use AEAD; avoid blindly reusing parameters from older guides. When importing a node, check the port, transport, and TLS settings as well as the user ID. Selecting the right protocol does not mean the connection settings are complete.

VLESSProxy protocol · UUID: VLESS identifies users with a UUID. The protocol does not encrypt payloads itself, so connection security must be considered alongside mechanisms such as TLS or REALITY. VLESS is not just another name for VMess, and their fields are not interchangeable. Check that the core supports the selected transport and flow parameters; changing only the protocol in a dropdown is not enough.

TrojanProxy protocol · password authentication: Trojan typically protects connections with TLS and authenticates with a password. Here, Trojan refers to the protocol, not malware. A correct password does not guarantee that certificate verification will succeed; the server name and system time can also affect the handshake. Check the address, TLS server name, and transport options separately. Don't hide configuration errors by skipping verification.

REALITYConnection security · Xray ecosystem: REALITY is a connection security mechanism in the Xray ecosystem, typically used with protocols such as VLESS. It is not a standalone node protocol. Configuration often includes a public key, server name, and shortId; exact fields vary by core and client version. Copying only the address and UUID is usually not enough. Import all parameters provided for the node and confirm that the selected core can parse them.

WebSocketTransport · WS: WebSocket is a bidirectional communication method that can carry proxy traffic. It is a different layer from proxy protocols such as VMess and VLESS. The path and Host must match the server's requirements, while the TLS server name is a separate setting. A mismatch in path capitalization, leading slash, or Host can cause the connection to fail at the transport layer.

Cores & Ecosystem

The client manages settings; the core handles the work. Check protocol support and configuration options when choosing a client.

Project VOpen-source project ecosystem: Project V is an ecosystem of open-source projects built around V2Ray and related networking tools, not the name of a particular desktop client. It includes cores that handle network logic and GUI applications that help users manage configurations. If a tool claims to support V2Ray, check which protocols and core it supports, and whether it can represent all the parameters your node requires.

V2FlyCommunity project maintaining V2Ray: V2Fly is a community project that maintains the V2Ray core and related ecosystem, and the name is also commonly used for its core fork. It shares an ecosystem background with Xray, but their protocol support, configuration structures, and development paths are not identical. Before migrating a configuration, check what each field means. Being able to import a link does not guarantee that every connection feature is supported.

XrayIndependent core project: Xray is an independent core project that grew out of the V2Ray ecosystem, with its own development path for protocols, transports, and configuration. Whether features such as REALITY are available depends on the core version and whether the client can generate the required settings. The core name is no guarantee of speed. Check the node's technical requirements first, then consider the client's configuration and maintenance options.

CoreConfiguration execution engine: The core handles protocol processing, routing decisions, DNS logic, and network connections. A GUI typically converts user settings into a core configuration. An open client interface does not mean the core has started successfully; invalid fields or a port conflict can prevent it from running. Distinguish client logs from core output when troubleshooting, and check the core comparison to understand feature support.

GUI clientv2rayN / v2rayNG / v2flyNG: GUI clients manage node lists, subscription updates, configuration generation, and runtime controls, avoiding the need to edit core configuration directly. v2rayN is for desktop platforms; v2rayNG and v2flyNG are for Android. Check core and feature support for each client separately. A client name, core name, and proxy protocol are three different things; appearance alone cannot tell you whether a node is compatible.

Subscriptions & Nodes

Subscriptions provide configuration sources; nodes store connection settings. Updating, converting, and filtering each serve a different purpose.

SubscriptionConfiguration distribution URL: A subscription is usually a URL that provides a collection of nodes. The client fetches and parses its contents into connection configurations. Updating a subscription typically refreshes nodes and their parameters; it does not necessarily sync local routing rules or DNS settings. Treat the URL as sensitive because it may contain access credentials. Don't post the full link publicly. See how to import a subscription.

NodeServer connection configuration: A node is a set of server connection parameters saved by the client, typically including the address, port, authentication details, protocol, and transport options. A node label is just for identification and may not accurately reflect the server's location or network route. Importing a node does not guarantee that it will connect. Check that the configuration is complete and the service is available, then verify the connection with a real request.

Subscription groupClient management group: Subscription groups organize nodes by source or purpose, making it easier to update, filter, and manage lists separately. A group name belongs to the client management layer; it is not a core outbound tag and may not be used by routing at all. Removing a group, deleting nodes, and disabling updates can be different operations. Check the client prompt before proceeding so you don't mistake list cleanup for a server-side configuration change.

Subscription conversionConfiguration format conversion: Subscription conversion reformats configuration content into a format another client can recognize; it cannot supply parameters missing from the server. Conversion may drop less common transport fields or alter group and routing rules, so check the result after importing. Conversion services may access subscription URLs and node credentials. Prefer formats supported natively by the client, and know who will process your data.

Traffic multiplierQuota calculation factor: A traffic multiplier describes how a subscription service calculates usage or quota for a node; it is not a performance metric provided by the client core. For example, a 2× multiplier generally means that using one unit of traffic deducts two units from your quota, though the service's own terms take precedence. A higher multiplier does not necessarily mean faster speeds, nor does a lower one mean slower speeds. Consider stability, intended use, and remaining quota together.

Routing

Rules determine where traffic goes; data sets provide matching criteria. Check rule order first, then the outbound tag.

Routing rulerouting.rules: Routing rules match traffic by domain, IP, port, or other conditions, then select an outbound. Rules are typically evaluated from top to bottom, so an earlier match can prevent later rules from handling the same connection. Put specific rules before broad ones and confirm that each referenced outbound exists. Interpret combinations of conditions according to the configuration syntax of the core you're using.

RoutingOutbound selection by rule: Routing directs different traffic through different outbounds—for example, sending some requests directly, others through a proxy, and blocking the rest. It depends on rules, data resources, and the traffic entry point, not just a mode toggle. DNS results and whether the core can obtain domain information also affect matching. To verify behavior, check which rule and outbound were actually used, not just whether a page loads.

GeoIPIP address set · geoip:private: GeoIP in a configuration usually refers to IP address sets organized by region or purpose. Rules can use these categories to match addresses. For example, geoip:private typically matches private address ranges, but availability depends on the loaded data. GeoIP is not a real-time measure of a route's location; outdated data or changes in DNS results can affect matches.

GeoSiteDomain set · geosite:cn: GeoSite is commonly used to reference domain sets organized by service or purpose, avoiding the need to maintain large numbers of domain rules individually. Category names and their contents depend on the data file, and the same category may differ across sources. If the core receives only the destination IP and no domain, domain sets may not match directly. Check DNS, sniffing, and the traffic entry point together.

OutboundoutboundTag: An outbound is a core component that handles outgoing traffic, such as proxying, connecting directly, or blocking it. Routing rules typically refer to outbounds by tag. Names like direct and block are common conventions, but they must match the actual configuration. A node label in the client is not necessarily an outbound tag. Before writing custom rules, check the actual tags in the generated configuration.

DNS & Network Stack

DNS resolution and application traffic take separate paths. Traffic interception, encrypted queries, and domain mapping are different mechanisms.

DNSDomain Name System: DNS resolves domains to IP addresses and other records. A client's built-in resolver and the system resolver may handle different queries. Routing application traffic through a proxy does not automatically send earlier DNS queries through it. Check who initiates each query, which resolver receives it, and which outbound carries it. Then use the DNS configuration guide to check how resolution and routing work together.

DNS over HTTPSDoH · HTTPS DNS queries: DoH sends DNS queries over an HTTPS connection to protect query contents between the client and the resolver. Encrypting queries does not automatically route them through a proxy or guarantee results suited to the current connection. If the resolver address is a domain, consider how it is resolved initially. When troubleshooting, check both the connection path and initial resolution; an HTTPS URL alone proves little.

FakeDNSSynthetic IP and domain mapping: FakeDNS returns synthetic IP addresses for domains and maintains local mappings so that later connections can recover the domain for routing decisions. It is not a regular DNS service that returns real public IP addresses; it must work with traffic interception and mapping recovery. Connections can fail if synthetic addresses escape the interception scope or an app caches an old mapping. After enabling or disabling FakeDNS, check that caches and routes remain consistent.

DNS leakQuery deviating from the expected resolution path: A DNS leak means a query reached an unintended resolver or took an unexpected path. First decide which queries are supposed to use the proxy. The system, browser, and apps may each resolve domains differently, so changing client DNS alone may not cover every source. Interpret test results alongside logs and configuration; a deliberately direct DNS query is not a problem just because it bypasses the proxy.

TUN modeVirtual network interface · IP traffic interception: TUN mode routes IP traffic to the client network stack through a virtual network interface, covering more than simply changing the system proxy. Enabling it usually involves administrator permissions, system routes, and DNS interception, and it may conflict with virtual interfaces used by other networking tools. TUN does not mean all traffic must use a proxy; routing rules still decide. Before getting started, see the TUN mode configuration guide.

Client Settings

Traffic coverage, listening endpoints, and test metrics answer different questions. Define the test target before interpreting results.

System proxyOperating system proxy settings: The system proxy provides an endpoint for apps that follow the operating system's proxy settings, usually pointing to the client's local listening address and port. Some apps use their own network settings and may ignore it, so enabling the system proxy does not intercept every connection. Clearing the system proxy only removes the related system settings; it does not stop the core or disable TUN. When exiting the client, check each of these states separately.

Local listening portInbound · local connection endpoint: A local listening port accepts connections from apps to the client; it is separate from the remote node port. The proxy port configured in an app must match the client's actual listening port, and you must also choose the correct endpoint type, such as HTTP or SOCKS. For local use, bind to the loopback address. Before allowing other devices to connect, set clear access controls and consider the network boundary to avoid exposing the port more widely than intended.

TcpingTime to establish a TCP connection: Tcping typically measures the time required to establish a TCP connection to a target port, providing a quick indication of port reachability and handshake time. Success only means that this stage completed; it does not confirm that proxy authentication, TLS, DNS, or application requests work. Retry and timing methods vary between tools, so compare results under the same conditions. Do not use them directly to rank download speeds.

Real connection latencyTime for a request through a proxy: Real connection latency is typically measured by sending a request through the selected node to a test address, making it more representative of proxy use than a TCP handshake test alone. The measurement may include DNS resolution, the proxy handshake, and the target response, but the timing boundaries depend on the client. Different test addresses affect results, and a timeout does not necessarily mean every service is unavailable. This is distinct from a bandwidth test.

Domain sniffingSniffing · extracting domain clues: Domain sniffing extracts domain clues from recognizable connection metadata, such as some HTTP requests or TLS handshake information, to help with routing. It does not decrypt communication, and it cannot identify every protocol or connection. Whether it overrides the original destination address or is used only for routing are separate settings. If behavior changes after enabling it, check what each option does.