V2Ray Glossary: Protocols, Cores and Routing Concepts

VMess is a Project V protocol for communication between clients and servers, covering authentication, time validation and data transport. Importing a configuration typically requires a server address, port, user ID, transport method and security parameters.

A large system-time offset, mismatched user ID or incompatible transport settings can prevent a connection from being established. VMess defines only part of the connection profile; outer options such as TLS and WebSocket must be checked separately.

VLESS is a streamlined connection protocol that does not provide additional encryption for transported content by itself. It typically delegates security to an outer mechanism such as TLS or REALITY. Common fields include the user ID, transport type, flow control and server name.

VLESS and VMess use different field structures, so changing only the protocol name does not convert one into the other. Troubleshooting should separately verify identity information, outer security and transport parameters.

Trojan authenticates connections with a password and typically uses TLS to establish the transport channel. Client configuration should verify the server address, port, password, server name and certificate-related options.

A correct password does not guarantee a successful connection; the domain, port and TLS parameters must also match the server. For handshake errors, first check the certificate name and connection-stage messages in the client log.

REALITY is a transport-security implementation in the Xray ecosystem, commonly used with VLESS. Configurations typically include a public key, short ID, server name, fingerprint and flow-control fields.

These fields serve different purposes and cannot be replaced with ordinary TLS settings. If an imported node fails to connect, compare the public key, short ID and server name one by one, and make sure automatic client values do not differ from the original configuration.

Project V refers to the open-source technology ecosystem built around proxy cores, protocols and tools. V2Ray's configuration model includes inbound, outbound, routing, DNS and transport modules, and later cores and clients adopted many of these concepts.

It is not the name of a graphical client. When reading documentation, distinguish the ecosystem, core and client names so interface features are not mistaken for capabilities of the protocol itself.

V2Fly is a community-maintained collection of cores and related projects continuing the V2Ray technical direction. Some clients use the V2Fly core to parse configurations, establish connections and apply routing rules.

The same base configuration may have different field support across core versions. If an old configuration behaves unexpectedly after a client upgrade, first confirm which core the client is using and which configuration syntax it supports.

Xray is a family of cores broadly compatible with the V2Ray configuration model, supporting VMess, VLESS, Trojan and REALITY protocols or security mechanisms. v2rayN and v2rayNG can use the Xray core to handle connections.

Compatibility does not mean every field is identical. For flow control, transport security or experimental features, follow the configuration structure recognized by the current core.

v2ray-core is the program responsible for actual network processing. It parses configurations, creates inbounds and outbounds, performs DNS queries and matches routing rules. Graphical clients typically control it through startup arguments or configuration files.

A client interface opening normally only shows that the client process can run; it does not prove that the core started successfully. Troubleshooting connection failures requires checking the client status, core logs and local listening ports.

A subscription is a configuration-collection URL provided by a server. Clients use it to retrieve a node list, request remote content and parse it into local configurations in a supported format.

A successful subscription update only means the URL was reachable and its content could be read; it does not mean every node in the list can connect. For update failures, check the complete URL, system time, network path and client logs.

A node is a single connection profile in a client containing the server address, port, protocol, authentication details, transport parameters and display name. After selection, the core uses these fields to establish the corresponding outbound.

A node name is only a management label and does not directly indicate the protocol or connection quality. When copying a configuration, preserve every field rather than copying only the name and server address.

Latency is the time required for data to travel from the local device to a target and return, usually recorded in milliseconds. Client tests may use port probes, basic network requests or proxy requests, and results from different methods are not directly comparable.

Lower latency does not necessarily mean faster downloads. Bandwidth, packet loss, server load and target-site response all affect real-world performance. Evaluate nodes using connection success rates and actual access results as well.

True connection latency usually means the response time recorded after a client establishes an actual proxy connection through the selected node and sends a request to a specified target. It covers more stages, including the protocol handshake, transport setup and target response.

Results are still affected by the test address, network fluctuations and cache state, so they are best used for relative comparisons during the same period. Verify a single timeout against the logs instead of immediately treating the configuration as invalid.

Routing rules select an outbound according to domains, IPs, ports, network types, protocols or processes. Common outbounds include direct, proxy and block; exact names are defined by the client or configuration file.

Rules are usually matched in order, so an earlier broad condition can make later rules ineffective. When editing rules, confirm the default outbound first, then arrange conditions from specific to general and test each change.

Traffic splitting assigns different targets, applications or network types to different outbounds. It is not a standalone protocol; it results from the interaction of routing rules, DNS resolution and outbound configuration.

Common matching criteria include domain category, IP region, port and process name. When rules conflict, inspect the condition that actually matched and confirm whether the domain was resolved to an IP before matching.

GeoIP is a dataset organized by the region or network category associated with IP addresses, which routing rules can reference as a match condition. It is useful for connections whose targets already appear as IP addresses.

GeoIP data is not a real-time lookup result. Database versions and changes in address ownership can affect classification. For incorrect traffic splitting, check that the data file loaded correctly and that the referenced rule tag exists.

GeoSite is a dataset of rules organized by website domain categories for domain-level routing matches. Each category contains domains, subdomains or matching expressions referenced by routing rules through a tag.

GeoSite and GeoIP match different objects: GeoSite handles domains, while GeoIP handles IP addresses. If an application connects directly to an IP, relying only on GeoSite rules may not produce a match.

v2rayN is a graphical client for Windows, macOS and Linux that manages subscriptions, nodes, system proxies, TUN mode, DNS and routing settings. It organizes common configuration tasks in a user interface and calls the selected core for actual connections.

Troubleshooting should distinguish interface settings, core startup and system proxy status. A client showing a selected node does not automatically prove that application traffic has entered the corresponding local proxy entry point.

TUN mode receives system traffic through a virtual network interface and passes it to the core according to routing and DNS settings. It can cover some programs that ignore system proxy settings and suits scenarios requiring centralized traffic handling.

Enabling TUN mode usually involves system permissions, a virtual interface, the routing table and DNS settings. If the network goes offline, disable it first to restore basic connectivity, then check permissions, interface conflicts and bypass rules.

A system proxy is the proxy address and port configuration exposed by the operating system for applications to read. Browsers and some desktop programs follow it and send requests to the client's HTTP or SOCKS entry point.

Not every program reads system proxy settings, so direct connections may remain after it is enabled. To verify whether it works, check the system settings, local port and the target program's own proxy options.

FakeDNS returns mapped addresses to applications while retaining the relationship between each address and its original domain in the core. In transparent proxy or TUN scenarios, this lets the core continue making routing decisions by domain.

FakeDNS must be configured together with DNS inbounds, an address pool and routing rules. Address-pool conflicts, queries that never reach the core or lost mappings can all cause resolution or connection problems.

DNS is the basic network service that translates domain names into IP addresses. The V2Ray core can configure multiple DNS servers, query protocols, domain rules and address-selection strategies, then use the results for routing decisions.

A successful DNS query does not guarantee a successful target connection; they are separate stages. Troubleshooting should confirm that the domain resolves, the result is expected and which outbound handles the connection.

A DNS leak occurs when a domain query expected to use a specified client path or DNS server is sent through another resolver. Common causes include app-level DNS, system fallback, independent browser settings or routing bypasses.

Troubleshooting requires checking system DNS, the client listening entry, TUN settings, browser configuration and query destinations in the logs. Changing one DNS address alone cannot ensure every application uses the same path.

SOCKS is a general-purpose proxy interface protocol that lets applications hand TCP or UDP connections to a designated server. V2Ray clients commonly expose a local SOCKS inbound for software that supports manual proxy settings.

A SOCKS address usually points to the local loopback address and a listening port. If an application uses the wrong port, the client is not running or the port is occupied, the connection fails before reaching the node protocol.

A local listening port is opened by the client on the local device to receive application connections, such as a SOCKS or HTTP proxy port. The port in the system proxy settings must match the value the client is actually listening on.

If another program occupies the port, the core may be unable to start the corresponding inbound. Check the startup log, switch to an unused port and update every application setting that references it.