Configuration Reference · 28 Terms

V2Ray Glossary

Protocols, cores, subscriptions, and DNS. Look up what each setting means in your client, understand the concepts, then check the parameters.

Read the Protocol Guide View Setup Steps →

Proxy Protocols

First, confirm that both ends use the same protocol. Security and transport settings must also match. REALITY is covered here for reference, but it is not a standalone proxy protocol.

VMess: A proxy protocol in the Project V ecosystem that authenticates users with an ID. Modern configurations typically use AEAD. The user ID, security settings, and system clocks must match on the client and server. Avoid copying extra authentication parameters from outdated guides without checking whether they apply. After choosing VMess, check the transport and TLS settings too: the same protocol name does not guarantee an identical configuration.

VLESS: A lightweight proxy protocol that does not encrypt data on its own and is typically used with TLS or REALITY. Check the user ID, transport, security layer, and flow separately; flow support depends on the cores at both ends and the connection combination. Do not assume that “encryption: none” in the interface means the entire connection is unencrypted. Check the outer security settings as well.

Trojan: A proxy protocol that authenticates with a password and typically relies on TLS to protect the connection. The server address, port, password, and TLS server name are separate fields; copying the password alone is not enough to connect. If you see a certificate error, check the server name, certificate validity, and system clock before considering any change to certificate verification.

Shadowsocks（SS）: A proxy protocol configured with a shared key or password and an encryption method. Share links often start with ss://. Traditional AEAD and Shadowsocks 2022 have different parameter and key requirements, and client support varies. The protocol, encryption method, and key must be used as a compatible set; do not mix fields from different methods.

REALITY: A transport security option in the Xray ecosystem, often used with VLESS. It is not a proxy protocol that can replace VLESS on its own. Configuration typically includes a server name, public key, shortId, and client fingerprint; available fields depend on the core version and client interface. After importing, confirm that all details were preserved. The server address alone is not enough to verify a configuration.

Transports and Obfuscation

This layer determines how data is carried and how the handshake works. Using the same transport does not make the path, hostname, and forwarding settings optional.

TCP: A transport-layer protocol that provides a reliable, ordered byte stream and carries many proxy connections. A TCP test in a client typically measures the time to connect to a specified port; it does not verify proxy authentication or subsequent requests. So a successful TCP test alongside failed browsing is not a contradiction. Next, check the protocol handshake, TLS, and DNS.

UDP: A protocol that sends data in datagrams without guaranteeing delivery or order, commonly used for DNS and real-time communications. An app's need for UDP does not mean system proxy settings will automatically route those requests. The local entry point, core, server, and operating mode all need to support it. Test UDP and TCP separately; successful web browsing does not confirm that UDP works.

WebSocket（WS）: A bidirectional communication mechanism that can carry proxy data, but does not handle proxy user authentication. The path, Host, and TLS server name in the client serve different purposes and must match the server and reverse-proxy settings. A successful TLS handshake does not prevent a connection failure caused by an incorrect path or forwarding rule.

gRPC: A remote procedure call framework built on HTTP/2, used as a transport by some proxy cores. The service name must match the server configuration. If a reverse proxy is in the connection path, it must support HTTP/2 and forward traffic correctly. gRPC is not a proxy protocol and is not guaranteed to outperform other transports on every network or workload.

TLS and SNI: TLS encrypts the connection and authenticates the server; SNI indicates the requested server name during the handshake. The connection address, SNI, and HTTP Host may differ, but each field must follow the server's requirements and cannot be swapped arbitrarily. Certificate validation must match the configured target name. Entering an arbitrary domain does not create a secure connection.

Cores and Clients

The core handles protocols and routing; the graphical client manages settings and runs the core. An interface that lets you save a field does not guarantee that the current core supports it.

Project V: An umbrella term for the ecosystem built around V2Ray and related networking tools, not the name of a specific desktop or mobile app. In documentation, distinguish the ecosystem from core projects and individual clients; do not treat core parameters as interface instructions. This site's setup guides focus on v2rayN, v2rayNG, and v2flyNG.

V2Fly: A community and core project continuing the development of V2Ray, with support for proxy protocols, transports, routing, and DNS. It shares history with Xray, but subsequent development has led to differences in features, configuration formats, and supported fields. When migrating a configuration, check the documentation for the core you actually use. Two JSON files are not necessarily interchangeable.

Xray Core: A proxy core project forked from V2Ray, with features such as REALITY and its own ongoing development of configuration and protocol implementations. v2rayNG uses the Xray core; on desktop, behavior depends on the selected core. Feature availability depends on the installed version and parameter combination. Updating the graphical client is not the same as updating the core.

v2rayN: A desktop graphical client for managing subscriptions, servers, routing, and proxy modes on Windows, macOS, and Linux. The client interface generates or organizes settings, while the selected core handles proxy connections. When troubleshooting, record both interface settings and core logs; the client name alone does not show which protocols or modes are enabled.

v2rayNG: An Android graphical client based on the Xray core that can import subscriptions and shared configurations. It typically routes app traffic through Android's VPN interface. System permissions, per-app settings, and background restrictions can all affect which traffic is captured. Seeing that the client is running only confirms that the service started; verify access with an actual request.

v2flyNG: An Android graphical client that uses the V2Fly core and is an option within that core ecosystem. Its name is similar to v2rayNG, but the core is different; do not assume it supports REALITY, flow, or other extensions in the same way. Before choosing, confirm the server's requirements, then check that the client recognizes all configuration fields after import.

Subscriptions and Servers

A subscription is a source for retrieving a set of configurations; a node is one connection profile in that set. Importing, updating, and testing each address a different issue.

Subscription Link: A URL a client uses to retrieve a set of server configurations. Refreshing it fetches and parses the content again. Clients may support different subscription formats, so a URL that opens successfully may still fail to import correctly. The link may contain access credentials; treat it as sensitive information. Updates usually apply to the associated group, so save important manual configurations separately.

Node / Server Configuration: A selectable connection profile in a client's server list, usually containing an address, port, authentication, transport, and security settings. It is a logical configuration and does not have to correspond to a separate physical server; one address can offer multiple connection options. The label is for identification only and does not reveal the actual location, performance, or whether the protocol is configured correctly.

Latency: The time from starting a specific test to receiving a response; the result must be interpreted in context. ICMP, TCP connection setup, and visiting a URL through a proxy measure different paths and processes, so their numbers are not directly comparable. A timeout does not necessarily mean the entire configuration is broken. Check whether the test target is reachable and whether the test used the intended proxy.

Real Connection Latency: In a client, this usually means the time taken to reach a specified test address through the proxy, covering more connection steps than a basic port check. Results can depend on DNS, the protocol handshake, TLS, the target site, and connection reuse; the exact timing method depends on the client. It is not download speed. To compare configurations, use the same test address and method.

Routing and DNS

How traffic enters the client, which rule it matches, and which resolver handles the domain are three separate steps that need to be verified independently.

Routing Rules and Split Tunneling: Routes connections to different outbounds, such as direct, proxy, or block, based on domains, IPs, ports, or other criteria. Rules are commonly evaluated in order; the default outbound, domain resolution strategy, and sniffing settings can also affect the result. “Rule mode” in the interface only selects a rule set. Check the match order and core logs to see where traffic actually goes.

GeoIP: An IP address collection grouped by region or purpose, which routing rules can use to match multiple destination IPs at once, such as geoip:private. It matches addresses, not website names; whether a domain is resolved first can affect matching. The data file must be compatible with the configuration, and an IP range cannot precisely identify a service or its current network location.

GeoSite: A domain collection grouped by site or purpose that reduces the need to maintain rules one domain at a time, such as geosite:cn. Available categories depend on the data file actually loaded; labels in a guide are not necessarily built into every core. If an app only provides an IP address, domain rules may need DNS mapping or sniffing to obtain the domain name.

System Proxy: Changes the operating system's proxy settings so apps that follow them connect to the local proxy provided by the client. It does not automatically capture every program; apps with their own network stack may ignore system settings, and this does not confirm that UDP is routed. If the network stops working after you close the client, first check whether the system proxy still points to a local port that is no longer listening.

TUN Mode: A mode that receives IP traffic through a virtual network interface and passes it to proxy components; it is not a new proxy protocol. It typically requires additional permissions, routing, and DNS settings, and exclusions affect which traffic is captured. After enabling it, check local network access, DNS resolution, and the target app separately. “Capturing all traffic” does not mean every connection must use the proxy outbound.

FakeDNS: Returns a synthetic IP address to the app and stores its mapping to the original domain in the core, allowing later connections to recover the domain and use it for routing. The synthetic address is not the website's real IP and requires compatible traffic capture and mapping. If the configuration is incomplete, traffic may bypass the intended processing path. Stale DNS cache entries after a mode change can also cause problems.

DNS Leak: When DNS queries deviate from the configured resolution path—for example, a query intended to go through the proxy is sent to a local resolver. Whether this counts as a leak depends on the policy: explicitly configured direct DNS is not automatically a problem. Check system DNS, app-level encrypted DNS, core DNS outbounds, and routing rules. A result from a single DNS test site is not enough to identify the cause.