CONFIGURATION DICTIONARY

V2Ray Glossary

From protocol names to local listening ports, each concept is explained in the configuration context where it actually appears. Identify the relevant layer first, then read the client menu, core logs and tutorial steps.

05 Technical categories

34 Core terms

A–Z English index

Quick index D F G R T V W X Subscriptions Routing System proxy

01 / PROTOCOL

Protocols and transports

Protocols define authentication and data exchange, while the transport layer determines how a connection is carried. When importing a configuration, check the security layer, transport, path and service name—not just the protocol.

VMess: One of the earlier protocols used in the Project V ecosystem. A configuration usually includes a user identifier, server address, port, transport method and security parameters; any mismatch in a critical field can prevent the handshake. It is common in older configurations, so migration should import the complete parameters supplied by the server rather than copying only the address and port.
VLESS: A lightweight protocol that separates authentication from the transport security layer. VLESS focuses on the user identifier, flow control and underlying transport, and is commonly combined with TLS or REALITY. When reading a configuration, verify the protocol, transport and security fields separately instead of treating their parameters as one layer.
Trojan: A proxy protocol that uses password authentication and is usually paired with TLS. The client must match the server address, port, password, server name and certificate-related settings. If the connection ends during the handshake, check the system time, domain name and security-layer options as well as the credentials.
REALITY: A transport security solution in the Xray ecosystem, commonly paired with VLESS. Typical configurations include fields for the public key, short ID, server name, fingerprint and flow control; these fields are independent and cannot substitute for one another. If the client shows incomplete parameters after import, compare each field with the original configuration instead of repeatedly switching nodes.
TLS: A security layer that encrypts and authenticates network connections. The certificate name, server name, system time and certificate trust status all affect the TLS handshake. The client's “skip certificate verification” option is independent and should not be treated as a universal fix for connection problems.
WebSocket: A transport method that establishes a bidirectional connection through HTTP upgrade, often abbreviated as WS in configuration. Common parameters include the path, request headers and host name, all of which must match the server entry point. WebSocket is a carrier, not the same thing as an upper-layer protocol such as VMess or VLESS.
gRPC: An HTTP/2-based remote procedure call framework that can also serve as a connection transport. Related settings usually include a service name and appear alongside security layers such as TLS. A service name may look similar to a path, but they are different fields; do not copy a path value directly when migrating from another transport.

02 / CORE

Cores and clients

The client handles the GUI, subscription management and system integration, while the core establishes connections and applies rules. Distinguishing them helps identify whether a problem lies in the interface, configuration generation or underlying connection.

V2Ray: The Project V ecosystem's network proxy technology and configuration system, commonly used as a general term for its protocols, cores and client tools. During troubleshooting, the broad name “V2Ray” is not enough; identify the client, core family and protocol in use. Menu names may differ between implementations, but the configuration layers are broadly similar.
V2Fly: A community-maintained family of cores that follows the Project V technology line, with independent releases and configuration implementations. V2Fly and Xray share some concepts, but their protocol support, field details and release schedules are not identical. When choosing a client, check which core it actually invokes rather than inferring it from the app name.
Xray: A family of cores closely tied to the V2Ray configuration model, supporting protocols and transports such as VLESS and REALITY. Xray is usually started as a background process by a GUI client, and its logs record configuration parsing, listening ports and connection errors. Before changing advanced parameters, confirm that the client uses this core and that its version supports the relevant fields.
v2rayN: A desktop GUI client for Windows, macOS and Linux. It manages subscription updates, server lists, routing, system proxy settings and the core, converting interface options into configuration the core can read. The desktop and classic interfaces may place controls differently, so confirm which interface you are using before following a tutorial.
v2rayNG: An Android GUI client that typically uses the Xray core for connections and routing. It can import a subscription or a single share link, then use the system VPN interface to handle selected traffic. Background restrictions, battery policies and network changes can affect persistent connections and should be investigated separately from protocol settings.
v2flyNG: An Android client built around the V2Fly core for configurations that require the V2Fly technology line. Its interface resembles other mobile clients, but supported features depend on the V2Fly core. Before importing a configuration, confirm that its protocol and transport fields fall within the core's supported range.
Core: A background process that reads configuration, opens local listeners, establishes remote connections, handles protocols and applies routing rules. When a GUI client shows “started,” it usually means the core process is running, not that every server configuration can connect. For startup failures, check the local log first; for a single node, focus on the error lines for that connection attempt.

03 / SUBSCRIPTION

Subscriptions and nodes

A subscription is a configuration source, a node is one server record saved by the client, and a test result is a measurement under specific conditions. Keeping these concepts separate helps avoid mistakes such as assuming that a successful update guarantees a connection.

Subscription: A configuration collection URL provided by a server. After requesting and parsing it, the client writes its server entries to the local list. Adding a subscription URL only registers the source; an update usually still needs to be run. When an update fails, distinguish between an unreachable URL, invalid response content and client parsing failure.
Node: A single configuration record in the client's server list, containing the address, port, protocol, authentication and transport parameters. The node name is mainly for identification and does not determine the actual connection target. Two records with different display names may use the same server parameters, or may produce completely different results because their security layers or transports differ.
Subscription group: A management unit for separating multiple subscription sources. Groups make it easier to update, disable or filter servers independently instead of mixing every entry into one long list. Renaming a group usually does not change the remote subscription content, but before deleting one, confirm how the client handles its local records.
Share link: A text form that encodes one server configuration as a specific URI, allowing compatible clients to restore its main parameters. Share links are suited to importing one record, while a subscription URL continuously retrieves a set of configurations; their purposes differ. A parsing failure usually indicates a difference in link format, encoded content or client support.
Latency: The time required for data to make one round trip between the local device and the target, usually measured in milliseconds. Some tests only probe reachability, while others include the handshake and target access, so results cannot be compared directly. Low probe latency does not guarantee a stable connection afterward.
Real connection latency: The time measured by establishing an actual protocol connection and accessing a test target. It covers more stages than a basic network probe and better reflects the client's business connection process, but remains a result from one test condition. The target, DNS, current network and server load can all affect the value.

04 / ROUTING

Routing and traffic splitting

The routing system reads a connection's domain, address, port or process information, then selects the corresponding outbound. Whether a rule works depends not only on its contents but also on its order and whether the core can obtain the original target information.

Routing rule: A configuration set that selects an outbound based on conditions such as domain, address, port, network type, protocol or process. Rules select a path; they do not repair server parameters. Before writing one, define the target, matching condition and intended outbound to avoid a broad condition overriding more specific rules later.
Traffic splitting: The process of assigning connections from different targets or applications to proxy, direct or blocking outbounds. Traffic splitting can use built-in rule sets or explicit user-defined conditions. If traffic takes an unexpected path, first check which rule matched, then inspect the outbound that rule selects.
GeoIP: A collection of network addresses grouped by address ranges, used as a batch-matching condition in routing rules. GeoIP matches resolved or connection-target addresses, not domain categories. Its data files are updated periodically, and outdated data may not fully reflect current network conditions.
GeoSite: A collection of domains organized by purpose, organization or category; the core can match many domains using one category name. GeoSite works at the domain level, while GeoIP works at the address level, and both often appear in routing rules. A category set is not a live online directory, so rule results still need to be checked against the actual resolution process.
Outbound: The exit selected by the core after processing an inbound connection. Common outbounds include connecting through a specified server, connecting directly to the target or blocking the connection. Routing rules usually point to an outbound tag, so tag spelling and configuration references must match.
Rule priority: The evaluation order used when multiple routing rules could match the same connection. Many configurations process rules from top to bottom, so an earlier broad rule can prevent later specific rules from matching. Before changing the order, save the original configuration and verify each rule against a clearly defined target.

05 / NETWORK

Networking fundamentals

The client must first receive application traffic locally, then hand the connection to the core. System proxy settings, TUN, DNS and listening ports belong to different stages; troubleshoot them in the order “application → local entry point → routing → remote connection.”

System proxy: A set of proxy settings exposed by the operating system. Browsers and other applications that follow system settings automatically connect to the local port opened by the client, while some terminal tools, games and applications with their own network stack may use separate settings. An enabled system proxy only confirms that the entry is registered; also check the client core and server connection.
TUN mode: A way to receive system traffic through a virtual network interface, covering applications that do not read system proxy settings. TUN mode involves routing tables, DNS and application compatibility, so it requires more system-level configuration than a standard system proxy. If only certain applications fail afterward, check bypass rules and DNS settings first.
FakeDNS: A mechanism that temporarily assigns reserved addresses to domains and maintains mappings between them in the core. It is commonly used in TUN scenarios so the core can identify the original domain when it receives an address connection and apply domain rules. FakeDNS is not a public resolver; its mappings must be correctly handled by the same traffic-processing path.
DNS: The basic service that converts domain names into network addresses. V2Ray client configurations may involve the operating system resolver, built-in core DNS settings and remote resolution policies. When a domain fails but its address connects, check separately whether the query succeeded, which address it returned and how routing handled the result.
DNS leak: A condition where application traffic follows the expected path but domain queries are still handled by another resolver. It is often related to system resolver settings, browser secure DNS, the scope of TUN interception or core DNS routing. Troubleshooting must check not only the final connection address but also which layer sent and handled the query.
Local listening port: A port opened on the local device for applications to connect to, such as a SOCKS or HTTP entry port. A port on the same address generally cannot be occupied by two processes at once; during a conflict, the core may exit immediately after starting. After changing the port, update the corresponding system proxy or application setting as well.
SOCKS proxy: A general-purpose proxy interface at the application connection layer that supports multiple upper-layer protocols. An application can pass the target address or domain to the SOCKS entry, leaving the client core to handle the connection and routing. With domains, check whether the application resolves them locally or passes them to the proxy side.
HTTP proxy: A local proxy interface for HTTP requests and HTTPS CONNECT tunnels, commonly used by browsers and developer tools. Its protocol format differs from SOCKS, so the ports must not be interchanged without confirmation. If a terminal program does not read system proxy settings, specify the proxy address in that program's own settings.