Configuration reference

V2Ray Terminology and Configuration Reference

A focused guide to common concepts in protocols, cores, client settings, subscription nodes, and routing rules. Each entry maps to a real configuration scenario, making it useful for checking tutorials or client options.

VMess · VLESS · REALITY Xray · V2Fly TUN · FakeDNS GeoIP · GeoSite

Browse by category

First identify where the term appears, then open the relevant category. Protocol parameters determine how a node connects; the core executes the configuration; client features control how traffic enters the core; subscriptions manage nodes; and routing rules decide which outbound handles the traffic.

Protocols and encryption

Connection protocols and transport security

Protocols, security layers, and transport methods belong to different configuration layers. When importing a node, keep the parameters for each layer aligned; do not infer the remaining options from the protocol name alone.

VMess: VMess is a node communication protocol in the Project V ecosystem. It handles client identity, time validation, and data transmission. Common settings include the server address, port, user ID, and additional identifiers. VMess also works with transports such as TCP and WebSocket; the protocol name alone does not describe a complete connection configuration.

VLESS: VLESS is a lightweight protocol that reduces encryption handled by the protocol layer itself, usually delegating transport security to TLS or REALITY. Configuration still requires a user ID, server address, port, and transport settings. The flow control and security layer depend on the server configuration, so client fields must match the server exactly.

Trojan: Trojan is a proxy protocol that establishes secure connections through TLS, with authentication usually represented by a password field. Besides the address and port, clients must correctly set the server name, transport method, and certificate options. After importing a share link, check that the server name has been preserved in full.

REALITY: REALITY is a transport security solution in the Xray ecosystem, commonly used with VLESS. Client settings typically include a public key, short ID, server name, and fingerprint. It is not a standalone node protocol, so clients usually place it under transport security rather than the protocol type list.

TLS: TLS is a general-purpose transport layer security protocol used to encrypt connections and authenticate the server. TLS settings in V2Ray clients commonly include the server name, permitted application-layer protocols, and certificate verification policy. If the server name is incorrect, the connection may fail during the secure handshake even when the address and port are correct.

Transport: A transport method is the connection format that carries protocol data. Common options include TCP, WebSocket, gRPC, and HTTPUpgrade. It sits beneath protocols such as VMess and VLESS but directly affects extra fields such as the path, host name, and service name. The client's transport method must match the server's listening configuration.

Cores and ecosystem

Project V, V2Fly, and Xray

Graphical clients import, edit, and invoke configurations, while the core listens on local ports, establishes connections, and applies DNS and routing rules. Their versions and supported capabilities are not necessarily identical.

Project V: Project V is an open-source technology ecosystem built around network proxy protocols, configuration structures, and runtime cores. In everyday usage, V2Ray may refer to the configuration system, a core program, or the broader ecosystem. Read the surrounding context to determine the intended meaning, and do not confuse a client name with a core name.

V2Fly: V2Fly is a community-maintained project continuing the Project V technology stack, with its core implementation commonly called v2fly-core. v2flyNG follows this core line for connections and routing on Android. Supported configuration features depend on the core, not simply on the appearance of the client interface.

Xray: Xray is a core implementation broadly compatible with the V2Ray configuration system, with additional features such as VLESS and REALITY. Common configurations in v2rayN and v2rayNG may invoke the Xray core. Client updates and core updates are separate, and their version information may appear in different places.

Inbound: An inbound is the entry point where the core receives traffic, corresponding to inbounds in the configuration file. Local SOCKS and HTTP proxy ports, as well as a TUN interface, can serve as inbounds. Inbounds determine which traffic can enter the core, but not which exit ultimately sends it.

Outbound: An outbound is the exit through which the core processes and sends traffic, corresponding to outbounds in the configuration file. Common types include proxy, direct, and block. The routing module selects an outbound according to its rules, so a connected node does not mean all traffic will automatically use it.

Client features

Traffic capture, DNS, and connection tests

Client switches mainly control how traffic enters the core and how domains are resolved. System proxy and TUN cover different traffic scopes, while latency tests must be interpreted in light of their testing method.

System proxy: A system proxy points the operating system's proxy address to the client's local listening port. Browsers and applications that read system proxy settings then pass traffic to the client. Some applications use an independent network stack or ignore system settings, so enabling the system proxy alone may not cover their traffic.

TUN mode: TUN mode receives system traffic through a virtual network interface and can cover applications that do not read system proxy settings. It usually requires permission to create or use a network interface and must be configured alongside DNS and routing. If LAN access behaves unexpectedly, check LAN bypass rules and the virtual interface routes.

FakeDNS: FakeDNS returns mapped addresses to applications while preserving the relationship between domains and mapped addresses in the core. When a later connection enters the core, the original domain can be restored and routed by domain rules. It mainly improves domain recognition in TUN scenarios and is not the same as a regular public DNS service.

DNS leak: A DNS leak occurs when queries that should use the designated DNS path are sent directly by the system resolver or another network interface. This may cause the apparent resolution location to differ from expectations or prevent domain rules from participating correctly in routing. Troubleshooting should cover client DNS, system DNS, browser secure DNS, and the scope of TUN capture.

Real connection latency: Real connection latency usually checks node availability by establishing an actual protocol connection or accessing a test target, then records how long the process takes. It is closer to the real connection path than a server-port check alone, but still depends on the target, network conditions, and protocol handshake. One result should not be treated as proof of long-term stability.

Subscriptions and nodes

Node sources, updates, and test results

A subscription is an updatable node list, while a share link usually describes a single node. Successful import, subscription update, and node connection are three separate states that must be verified independently.

Subscription: A subscription is a server-provided URL containing a list of nodes that the client can read as multiple configurations. The subscription URL itself is usually not a directly connectable node; it must first be updated or imported. After saving it, the client can fetch the list again on a schedule, while handling of custom local notes and groups depends on the client implementation.

Node: A node is a complete set of server connection parameters, usually including an address, port, protocol, identity details, security layer, and transport method. Each item in a client list generally represents one node configuration. A node name is only a label for identification and cannot replace checking the actual parameters and availability.

Subscription update: A subscription update makes the client revisit the subscription URL and synchronize the node list. The result may include new nodes, changed parameters, renamed entries, or removed old items. If the list does not change, first check that the URL is complete, the network request succeeded, and the client updated the intended subscription group.

Latency: Latency is the time from starting a test to receiving a response, usually measured in milliseconds. Clients may test a port connection, protocol handshake, or target request, so results from different methods are not directly comparable. Lower latency only means a shorter test time for that run; it does not indicate bandwidth, sustained stability, or performance for every destination.

Routing and traffic splitting

Match conditions, rule data, and evaluation order

The routing module does not create node configurations; it determines which outbound each flow should use. Rule conditions, DNS results, and rule order together affect the final match.

Routing rule: A routing rule determines which outbound receives traffic based on conditions such as domain, IP, port, protocol, or process. Each rule usually consists of matching conditions and a target outbound. Rules only handle traffic that has entered the core, so correct system proxy or TUN capture remains a prerequisite.

Traffic splitting: Traffic splitting assigns traffic for different destinations or applications to outbounds such as proxy, direct, or block. Common criteria include domain category, IP region, port, and process name. A well-structured setup should cover explicit targets first and retain a clear final default rule.

GeoIP: GeoIP is rule data organized by the region or category associated with an IP address, used to match resolved destination IPs. It is useful when only IP-based conditions are available and can supplement domain rules. Data files must be updated with the core or client; otherwise newly allocated address ranges may not be categorized as expected.

GeoSite: GeoSite is domain rule data organized by purpose or category, allowing the routing module to group and match destination domains. It contains domain sets, not an IP address database. If the core sees only the resolved IP and not the original domain, some GeoSite rules may not match.

Rule priority: Most V2Ray routing configurations check rules from top to bottom; the first match determines the outbound used for the traffic. Broad rules placed too early can mask more precise rules below them. When reordering, put explicit conditions such as processes and full domain names first, then handle broader categories and the default match.

V2Ray Terminology and Configuration Reference

Find terms by configuration stage