Configuration Concepts and Field Explanations

V2Ray Glossary

From protocols and cores to subscriptions, proxy modes, and routing. Look up terms from your settings to understand each concept before changing parameters.

A useful reading order is to start with clients and cores, then explore protocols, subscriptions, and proxy scope. Import errors, connection failures, and unexpected routing often occur at different stages, so one term alone rarely identifies the cause.

Setting up for the first time? See Getting Started →

Connection settings

Protocols & Transports

Proxy protocols, transports, and security layers work together. Similar names do not mean their settings are interchangeable.

VMess: A proxy protocol in the Project V ecosystem that authenticates connections using parameters such as a user ID and supports multiple transport combinations. Client and server authentication, transport, and security settings must match. System clock differences can also affect authentication. If a connection fails after import, check the entire configuration, not just the server address.

VLESS: A lightweight proxy protocol that does not encrypt data on its own and is commonly paired with a security layer such as TLS or REALITY. When importing a configuration, check the transport, security settings, and flow as well as the user ID. VLESS support does not automatically guarantee support for every extended combination; check the core's capabilities.

Trojan: A proxy protocol that typically uses a secure TLS connection and password-based authentication. The password, server name, and certificate validation all affect whether the connection succeeds, so a correct address alone may not prevent a handshake failure. For certificate errors, check the server name, system time, and server certificate rather than routinely skipping certificate validation.

REALITY: A transport security option in the Xray ecosystem, commonly used with VLESS rather than as a standalone proxy protocol. The server public key, server name, shortId, and other parameters must match the server configuration. Field names vary by core and client version. Selecting REALITY in the interface cannot supply missing server parameters.

How the components work

Cores & Ecosystem

v2rayN, v2rayNG, and v2flyNG are client names; Xray and V2Fly refer to core-level concepts.

Project V: The name of a project and technology ecosystem built around proxy tools and related protocols. Clients provide a graphical interface, while cores handle connections and routing. An ecosystem name is not an importable node configuration. Understanding the distinction helps separate interface instructions from protocol requirements.

V2Fly: A community project that continues the V2Ray approach and maintains proxy cores and related components. v2flyNG is an Android client using the V2Fly core; that does not mean it supports every feature available in other cores. When choosing a client, first check that it supports the protocols and transport combinations required by your subscription, then consider which interface you prefer.

Xray: A proxy core associated with the V2Ray ecosystem, supporting combinations such as VLESS and REALITY. v2rayNG uses Xray, but available configuration fields still depend on the core version bundled with the client. When consulting configuration instructions, check which core and feature set they apply to; do not assume fields from another core can be copied directly.

Core: The software component behind a client that handles protocols, connections, DNS, and routing rules. Interface settings are usually translated into core configuration, but an option appearing in the interface does not guarantee that the current core supports it. If the core fails to start, check the logs for configuration parsing errors before investigating unsupported fields or core incompatibilities.

Choose a client by platform and core →

Traffic entry points

Client Features

These features determine how requests enter the client. They are separate from the choice of outbound path after a request arrives.

System proxy: Points the operating system's proxy settings to the client's local listening address so apps that honor those settings send their requests through it. This does not capture every app: games, command-line tools, or apps with their own proxy settings may use another entry point. Before closing the client, check that the system proxy settings have been restored to avoid apps connecting to a stopped local port.

PAC: A proxy auto-configuration script that tells compatible apps whether to use a proxy or connect directly based on conditions such as the request URL. PAC is used when an app selects its proxy entry point; it is separate from routing rules applied by the core after the request arrives. If an app ignores the system PAC settings, editing the script will not change its connection path.

TUN mode: A way to receive traffic through a virtual network interface when it matches the system's routing conditions, then pass it to the client. It typically requires additional permissions and relies on system routing and DNS settings; enabling TUN does not mean every connection uses a proxy outbound. If you use other virtual network tools at the same time, check for interface or route conflicts before adjusting settings one by one.

FakeDNS: A mechanism that returns a mapped address for a domain and keeps the address-to-domain association so the destination domain can be identified later. It must work with traffic capture and the core's processing flow; the mapped address is not the destination server's real address. When troubleshooting, also consider DNS caching to avoid continuing to use stale mappings after changing settings.

Configuration sources

Subscriptions & Nodes

Fetching, organizing, and testing configurations are separate steps. A successful subscription update does not mean a connection test will pass.

Subscription: A way for a client to retrieve and update a set of connection configurations from a URL. The provider determines the contents and format. Subscription URLs may contain access credentials, so do not show them in full in public screenshots, chats, or logs. A successful update only means the configurations were fetched; it does not mean every node can connect or that the subscription contents will never change.

Node: A connection configuration in a client, typically including the server address, port, protocol, authentication, and transport security settings. A node's display name does not prove its actual exit region, network route, or availability. Renaming a node usually does not change its connection settings, but edits to subscription-generated configurations may be overwritten on the next update.

Subscription group: A management unit for organizing connection configurations by subscription source, making them easier to update, filter, and remove. Group names usually affect only the management view; they do not automatically change a node's routing rules, exit, or proxy scope. Keep manually added and subscription-based configurations organized separately, and check what will be affected before deleting a group.

Connection latency: The time measured when a node handles an actual connection or request. The measurement depends on how the client runs its test. It is closer to real-world access than a basic port check, but does not directly indicate bandwidth, stability, or performance across all sites. For meaningful comparisons, use the same test target, network environment, and method; check the logs to understand timeouts.

Matching & outbound routing

Routing & Split Tunneling

The final path depends on rule conditions, rule order, data files, and the default outbound. Looking at a single rule is not enough to determine the result.

Routing rule: A configuration that selects an outbound for a connection based on its domain, IP, port, or other conditions. Common Xray and V2Ray rules are evaluated in order, and typically the first match determines the outbound. Check the default behavior to see how unmatched connections are handled. The outboundTag referenced by a rule must match an existing outbound tag; a rule name alone cannot determine the route.

Split tunneling: A policy that sends different connections through paths such as direct, proxy, or block. It describes how traffic selects an outbound, unlike system proxy or TUN settings, which determine how traffic reaches the client. “Bypass mainland China” commonly refers to a combination of specific rules; the actual scope depends on the generated client configuration and the rule data in use.

GeoIP: A collection of IP address ranges organized by tags for use in routing rules. For example, geoip:private is commonly used to match private address ranges, with the rule determining the outbound. Classification depends on the data source and how recently it was updated. IP tags are not precise geolocation data and cannot identify which service a domain belongs to.

GeoSite: A collection of domain rules organized by tags, which the core can use to match requests by site or service category, such as geosite:cn. It matches domain rules, not server IPs. A match also depends on the relevant tag being available and the core having access to the destination domain. Some resources use separate domains and may need additional rules; the site's main domain alone does not reveal every request path.

Read the routing guide in the user manual →

DNS & Connections

Networking Basics

A request may involve DNS resolution, connection setup, authentication, and data transfer. The point of failure determines where to start troubleshooting.

DNS: A system that converts domain queries into corresponding records, commonly to find the IP address needed for a connection. Browsers, operating systems, and clients may each perform DNS lookups. When troubleshooting, distinguish lookup failures from connection failures that occur afterward. Encrypted DNS changes how those queries are transmitted; it does not automatically handle lookups from other apps.

DNS leak: A DNS query is handled by a resolver or network interface other than the one specified by the intended resolution path. To assess a leak, compare the intended policy with the actual query source; the exit IP or the location associated with a DNS response alone is not enough. When checking a browser's own DNS settings, the system resolver, and client DNS settings, first identify which queries were meant to go direct.

Local listener: An entry point where a client accepts requests from other apps on a local address and port, commonly using SOCKS or HTTP. The proxy protocol, address, and port configured in an app must match the actual listener; SOCKS and HTTP ports are not interchangeable. A listener on a loopback address is usually accessible only from the same device. For other interfaces, consider firewall rules, authentication, and access scope.

TLS: A security protocol that provides transport encryption, authentication, and integrity protection. Certificates, server names, and system time can all affect the handshake. TLS settings do not replace the proxy protocol's own authentication parameters. For related errors, check the time, server name, and certificate chain first, then distinguish network connection issues from authentication failures.

From terminology to setup

For a first-time setup, follow the steps to import a subscription and test the connection. If an existing configuration runs into problems, identify the stage where the error occurs before checking the relevant settings. Remove subscription URLs, authentication details, and other sensitive information before sharing logs.

Subscription Import & Connection Steps Browse FAQs →