CONFIGURATION GLOSSARY
V2Ray Glossary: Protocols, Cores, Subscriptions and Routing
Starting with configuration fields and client settings, this glossary explains common terms, how they work together and where to troubleshoot them. Protocols, cores and client features are grouped separately to keep different layers distinct.
CATEGORY INDEX
Find terms by configuration layer
First determine whether a term belongs to a protocol, core, configuration source, routing or client traffic-capture method, then open the relevant category. Every term has its own anchor for saving or sharing the exact location.
PROTOCOL & SECURITY
Protocols and encryption
Protocols, authentication identifiers and security layers are separate configuration layers. A complete node usually combines these parameters with a transport method.
- VMess
- A client–server communication protocol in the Project V ecosystem, covering user authentication, time checks and data transfer formats. It is commonly combined with transports such as TCP, WebSocket and HTTP/2. Client and server user identifiers, transport type and security settings must match.
- VLESS
- A lightweight protocol that separates authentication from transport-layer settings. VLESS does not encrypt content itself and is typically deployed with a security layer such as TLS or REALITY. When reading a configuration, check the UUID, flow control, transport and security-layer fields separately.
- Trojan
- A password-authenticated proxy protocol usually run over a TLS connection. Client settings must match the server address, port, password, transport security and domain information. TLS handshake failures and incorrect passwords appear as errors at different stages in the logs.
- REALITY
- A transport-security implementation provided by Xray and commonly paired with VLESS. Settings typically include a public key, short ID, server name and flow control; client and server parameters must match. It belongs to the connection security layer and is not the same concept as the VLESS protocol.
- TLS
- A general-purpose security protocol for establishing encrypted connections and authenticating endpoints. In V2Ray configurations, the certificate domain, server name, system time and certificate chain can all affect the handshake. For certificate errors, check the domain and time first, then inspect handshake details in the client log.
- UUID
- A universally unique identifier made of hexadecimal characters and hyphens. VMess and VLESS configurations commonly use UUIDs to identify users; an invalid or mismatched UUID causes authentication to fail. It is not a server address and cannot replace a password, port or transport parameter.
CORE & ECOSYSTEM
Cores and ecosystem
A graphical client and a core are different software layers. The client handles the interface and configuration management, while the core handles protocols, DNS, routing and connections.
- Project V
- An open-source technology ecosystem built around proxy protocols, routing capabilities and extensible transport components. Many concepts in V2Ray, V2Fly and related client documentation come from this ecosystem. It describes a project and technology lineage, not one specific graphical client.
- V2Fly
- A community-maintained project and core family that continues the V2Ray technology line. It provides protocol handling, inbound and outbound connections, DNS and routing, and can be used by graphical clients. Compatibility still depends on the specific core version bundled with the client.
- Xray
- An open-source core family closely related to the V2Ray configuration ecosystem. Xray supports VLESS, REALITY, routing and multiple transport combinations; available fields depend on the core and client versions. “Xray core” means the program that executes connection settings, not a subscription service.
- v2rayN
- A graphical client for Windows, macOS and Linux. It handles subscriptions, server lists, system proxy settings, routing rules and core startup on the desktop. When connections fail, distinguish interface settings, generated configuration and underlying core errors.
- v2rayNG
- A graphical client for Android that typically uses the Xray core for connections. Common features include subscription updates, node switching, routing modes, per-app proxying and connection logs. Changes between mobile and wireless networks can also alter system routing and affect the current connection.
- v2flyNG
- A graphical Android client following the V2Fly core line. It can import subscriptions and individual node configurations, making it suitable when V2Fly core compatibility is required. When comparing it with v2rayNG, focus on the core family, configuration compatibility and client-feature differences.
SUBSCRIPTION & NODE
Subscriptions and nodes
A subscription distributes configurations, a node is a selectable connection profile, and speed testing helps observe network performance at different layers.
- Subscription link
- A server-provided URL for retrieving node configurations in bulk. When updating a subscription, the client requests and parses this URL; expiration, invalid authentication parameters or network failures can cause the update to fail. A successful import only means the client read the configurations, not that every node can connect.
- Node
- A server connection profile available for selection in a client. A node typically contains an address, port, protocol, authentication details, transport method and security layer. The node name is mainly for identification; its internal fields determine the connection result.
- Subscription group
- A client-side organization method for separating subscription sources and managing node collections. Updates, cleanup and automatic selection usually operate within a group, so confirm the active group when troubleshooting. Deleting a group may remove its node records, so distinguish local nodes from subscription nodes first.
- Latency
- The time required for data to travel from the local device to a target and back, usually measured in milliseconds. Because tests cover different network stages, one latency result does not directly represent transfer speed. Latency also changes with the local network, congestion and test target.
- Real connection latency
- The time measured after a proxy node completes an actual protocol connection or target request. It covers more handshake steps than a basic network probe and is better for determining whether a node can establish a real connection. If the test times out, use logs to identify whether the failure occurred during resolution, transport connection, protocol authentication or the security handshake.
- Download speed test
- A test that transfers a defined amount of data to observe throughput. Results depend on the node's exit route, target server, network congestion, local connection and testing time. It consumes real traffic, and one result cannot establish long-term stability.
ROUTING & SPLIT
Routing and traffic splitting
Routing rules identify traffic characteristics first, then pass each request to a designated outbound. Domain rules, IP rules and outbound tags should be checked as one complete path.
- Routing rules
- A collection of rules that matches traffic by domain, IP, port, protocol or source and assigns an outbound. Rule order and outbound tags must correspond, or matches may not produce the expected result. When troubleshooting, find the rule actually matched by the request, then inspect the outbound it targets.
- Traffic splitting
- The process of sending different requests to separate outbounds, such as direct, proxy or block, according to routing conditions. Validate the result with access behavior, client logs and the DNS resolution path. Changing only the system proxy mode does not automatically fix routing rules in the core.
- GeoIP
- Rule data organized by the geographic region or network range associated with IP addresses. A routing engine can use GeoIP after domain resolution, but data versions and update frequency affect coverage. It handles address ranges and cannot directly replace domain classification rules.
- GeoSite
- Rule data containing domain collections organized by purpose or region. GeoSite handles domain-level matching and is distinct from GeoIP; the two are often combined to cover both domains and addresses. Whether a rule name works depends on the data files loaded by the client.
- Outbound tag
- The name used in a configuration to identify an outbound handler. Routing rules reference direct, proxy or block outbounds by tag; inconsistent spelling prevents expected forwarding. In logs, outbound tags also help confirm where a request ultimately went.
- Rule priority
- The evaluation order used when multiple routing conditions could match. Most configurations check rules sequentially, so specific conditions should generally come before broader ones. After changing the order, reload the configuration and verify the result with a clearly defined test domain.
CLIENT FEATURES
Client features
System proxy settings, virtual network interfaces and DNS handling determine how traffic enters the core. Whether an application reads system settings is key to understanding the capture scope.
- System proxy
- Network parameters supplied by the operating system to applications that support proxy settings. Enabling the system proxy does not affect every program; apps that ignore it need separate configuration or another traffic-capture method. Restore the system proxy before closing the client to avoid leaving a stopped local port configured.
- TUN mode
- A mode that receives system traffic through a virtual network interface and passes it to the client core. It covers more applications that ignore system proxy settings but requires correct permissions, routing-table and DNS configuration. If the local network fails after enabling it, check the virtual interface, route conflicts and other network tools using the same resources.
- FakeDNS
- A DNS mechanism that returns reserved addresses to applications and restores the original domain mapping during the subsequent connection. It preserves domain information for routing matches, but the address pool, cache and fallback settings must work together. Old cache entries may briefly affect tests after switching or disabling the mode.
- DNS leak
- A condition in which domain queries bypass the expected resolution path and are handled by another DNS resolver. Check system DNS, client DNS, routing rules and the browser's own DNS settings when troubleshooting. Interpret test results together with the active traffic-capture mode rather than in isolation.
- Inbound port
- A port that the client listens on locally to receive proxy requests from applications. SOCKS and HTTP inbounds may use different ports; an incorrect application setting or occupied port causes connection failures. When configuring an app manually, also confirm that the address points to the local device rather than the remote node.
- Client logs
- Text output recording core startup, configuration loading, DNS queries, routing matches and connection errors. Troubleshooting should focus on entries near the failure time and distinguish client interface logs from core logs. Before sharing logs, check for subscription URLs, authentication fields or complete node configurations.