V2Ray / Client Glossary
Protocol names, core names, and operating modes often appear together in the same settings window, but they do different jobs. This page organizes common terms into five categories, explaining what each means and how it relates to client settings. Every card has its own anchor for easy bookmarking or sharing.
First distinguish the protocol, transport security, and core—then check whether the configuration is compatible. This page explains fields and concepts. For step-by-step instructions, see the client setup guide; to compare design trade-offs, see the protocol and core technical reference.
The protocol defines how the two ends exchange proxy data; the transport determines how that data is carried; TLS or REALITY provides transport security. It is normal for a node name to contain several of these terms—they are not interchangeable options.
A proxy protocol in the Project V ecosystem, with authentication and data protection mechanisms. Node configurations typically include a user ID. VMess supports different transports, but using the same protocol does not mean the other settings are the same. Keep the server-provided parameters when importing, and make sure the device clock is accurate to avoid authentication failures caused by time drift.
A streamlined proxy protocol that does not provide complete transport encryption on its own; deployments commonly pair it with TLS or REALITY. The user ID, transport, flow control, and security settings in the client must match the server. Changing a VMess node's type to VLESS does not convert it—each protocol requires its own valid server configuration.
A proxy protocol typically carried over a TLS connection and authenticated with a password. A correct password is only one requirement: the server name, certificate validation, and transport settings must also match. For handshake errors, check the credentials and TLS configuration separately rather than repeatedly changing the password.
A proxy protocol that uses a pre-shared key and a specified encryption method, often abbreviated as SS. The encryption method is not a performance setting to choose freely; it must match the server. Protocol generations may differ in their key format and feature requirements, so if importing fails, first check whether the client and core support the method.
A transport security mechanism in the Xray ecosystem, most often used with VLESS. REALITY is not a proxy protocol at the same level as VLESS. Its configuration typically includes a public key, server name, and short ID; exact fields vary by client. Use matching parameters from the same valid configuration rather than combining settings from different nodes.
A security protocol that encrypts connections and verifies identity; browsers also use it when accessing HTTPS sites. The node's connection address may differ from its TLS server name, which is usually checked against the certificate. For certificate errors, check the name, system clock, and certificate status first; skipping validation is not a routine fix.
The client is the control interface; the core is the program that applies the network configuration. A field appearing in the interface does not mean the selected core can use it. To assess compatibility, check the client version, core type, and specific feature.
An open-source networking ecosystem built around components such as V2Ray, not a single desktop app with a unified interface. Graphical clients such as v2rayN provide controls for subscription management, node selection, and proxy settings, then hand off the work to a core. Understanding this distinction helps separate interface issues from core execution problems.
A core fork derived from V2Ray-related code that has since developed its own features; capabilities such as REALITY are closely tied to its ecosystem. v2rayNG uses Xray, while v2rayN configurations may use different cores, so check which one is selected. The cores share some concepts, but advanced fields and full configurations are not necessarily interchangeable.
A community project that continues development of the V2Ray core. Clients may label the corresponding core with lowercase v2fly. v2flyNG is an alternative Android client that uses this core and may suit configurations designed for it. Check support for the specific protocol and transport rather than judging which core is a better fit by its name alone.
These options control how application traffic enters the client and who can access its local proxy endpoint. Once traffic reaches the client, routing rules still determine its outbound route. Enabling the proxy and choosing global routing are therefore two separate steps.
Proxy settings provided by the operating system; only applications that honor them will use the proxy. v2rayN's “Set system proxy automatically” option usually points the system proxy to a local listener. It does not capture every connection on the device. If an application still connects directly, first check whether it supports the system proxy, then consider its own proxy settings or another traffic-capture method.
A mode that captures system IP traffic through a virtual network interface and passes it to the core. It usually covers more applications than the system proxy alone. Actual coverage still depends on system routing, permissions, and DNS settings; it does not guarantee that every connection uses the same route. Watch for routing conflicts when running other virtual network tools at the same time.
A proxy endpoint opened on the device for browsers and other applications to connect to; SOCKS and HTTP are common listener types. The listening address determines which devices can access it, and the port must match the application using it. If the log reports that the port is already in use, first check whether the client is running more than once instead of immediately switching remote nodes.
This setting lets other devices on the same local network access the local proxy endpoint; it does not control whether the current client can connect to other local devices. You also need the right listening address and firewall rules, and other devices must use this computer's local network address. It is usually unnecessary for local use. When sharing access, limit who can connect and consider authentication.
A subscription retrieves configurations in bulk, a node is one specific connection configuration, and a test measures how a connection performs. Updating a subscription, selecting a node, and running a test are separate steps. When troubleshooting, first identify which step failed.
A URL or data source that provides a set of node configurations and subsequent updates. The client parses it in a supported format. A successful update means the configurations were retrieved and parsed; it does not guarantee that every node will connect. Subscription links may contain account identifiers, so avoid sharing them publicly. If an update fails, first check that the URL is complete, then look for connection or format errors in the log.
A set of parameters in a client for connecting to a remote service—not just a server address. A complete configuration may include a port, user ID or password, transport, and TLS or REALITY settings. The node label is just for identification; it does not establish the actual location, protocol capabilities, or connection quality.
A client-side collection for organizing subscriptions and nodes by source or purpose, making configurations easier to update, filter, and remove. Group labels generally do not affect authentication or automatically change a site's outbound route. Before deleting a group, check whether its nodes will also be deleted and whether you will still need the original subscription URL. Don't mistake organization for connection settings.
The time it takes to receive a response using a particular test method, usually shown in milliseconds. ICMP, TCP, and HTTP tests cover different parts of the connection, so compare results only when the method and target are the same. Lower latency does not guarantee faster downloads, and a timeout may be caused by the test target or method. It is not, by itself, proof that a node is down.
The time measured for an actual request to a test target through the current proxy configuration. This is closer to an application request than a simple port-connectivity test. The measured steps depend on the client and may include the proxy handshake, DNS lookup, and target response. Results reflect only that test and do not replace real-world use or directly predict download speed.
Routing determines where connections go; DNS resolves domain names, and the two can affect each other. When troubleshooting, trace how a domain gets its address, how the connection matches a rule, and which route it ultimately takes. Changing one setting alone does not prove that the entire path has changed.
A set of rules that selects an outbound route—direct, proxy, or block—based on criteria such as domain, IP address, or port. Many cores use the first matching rule, so a broad rule near the top can take precedence over a more specific one. When adjusting rules, check the match criteria, order, and default route; don't just confirm that the target domain appears in the list.
The process of assigning different connections to different outbound routes. It describes routing behavior, not an encryption protocol. Presets such as “Bypass mainland China,” “Blacklist,” and “Global” are convenient ways to select routing policies. Their exact rules can vary by version or configuration, so check the actual rules when you need finer control.
A collection of IP addresses referenced by routing rules, often organized by region or other attributes. Classification depends on database contents; it is not a live measurement of a server's physical location. Changes in address ownership and shared infrastructure can also affect the result. Whether a domain must first be resolved to an IP for matching depends on the core's domain-resolution strategy.
A collection of domains organized by service, purpose, or other categories for domain-based routing. Unlike GeoIP, it classifies domains rather than IP addresses. The core generally needs the destination domain to match a rule; a destination IP alone may not be enough. A site may rely on several resource domains, so if the page loads but images fail, check the routes for related domains too.
The system that resolves domain names to IP addresses and other records. The operating system, browser, and proxy core may all perform DNS lookups. A client's “direct DNS” and “remote DNS” settings typically serve different purposes, but the field names alone do not guarantee that queries use a particular route. Check the resolver address, query path, and how the result is used separately.
A mechanism that assigns virtual IP addresses to domains and stores the mappings, allowing the core to recover the original domain when a connection later uses that address. It must work alongside traffic capture and routing; the returned virtual address is not the remote server's real IP. If an application keeps using an old mapping after a mode change, flush the DNS cache or reconnect.
A DNS query that takes an unexpected path or enters an unintended resolver chain. The resolver name shown by a test site must be considered alongside the intended routing target; a different name alone does not mean the configuration is wrong. Check browser secure DNS, system resolution, core DNS, and the query's outbound route. Distinguish intentional direct DNS lookups from unexpected bypasses.