V2RAY WIKI · TECHNICAL GLOSSARY
From protocol names and core relationships to subscriptions, routing, and DNS settings, this glossary explains the technical terms commonly found in configuration panels. Each entry covers what the term means, which settings it relates to, and what to check when troubleshooting.
Find by category
When reading a subscription tutorial or troubleshooting a connection, you do not need to memorize every term at once. First identify whether the issue involves protocol parameters, core capabilities, node management, routing rules, or system interception, then open the relevant category. The explanations focus on each term’s relationship to actual client settings rather than unrelated background.
The protocol defines identity fields and data format, while the security layer protects the outer transport. When importing a configuration, preserve all parameters supplied by the server instead of filling in fields manually based only on the protocol name.
VMess is an early protocol in the Project V ecosystem, with authentication, time validation, and transport-related parameters. Client configurations commonly include the server address, port, user ID, encryption method, and transport type. Any mismatch in a key field can cause connection failure, so importing a complete configuration or subscription is usually preferable to entering it manually.
VLESS is a lightweight protocol that does not provide complete transport encryption on its own, typically leaving security to an outer mechanism such as TLS or REALITY. Common fields include the user ID, flow control, transport method, and server name. To determine whether a VLESS configuration is complete, check the protocol, transport, and security layers together rather than verifying only the address and port.
Trojan is a password-authenticated proxy protocol typically paired with TLS. Key client settings include the server address, port, password, server name, and certificate verification options. If the address is reachable but the handshake fails, first check the server name, security-layer settings, and system time instead of repeatedly switching system proxy modes.
REALITY is a transport security mechanism from the Xray core family and is commonly combined with VLESS. A configuration generally includes a public key, short ID, target name, and fingerprint, all determined by the server configuration. It is not a generic switch that can be enabled arbitrarily; connections will not work as expected without the matching parameters or with an incompatible core version.
TLS is a general-purpose security protocol for establishing encrypted transport channels and may appear in many proxy protocol and transport combinations. The server name in the client usually participates in certificate verification and should not be treated as simply the connection address. For certificate or handshake errors, check the domain, system time, verification policy, and security parameters provided with the configuration.
The GUI client handles the interface and configuration management, while the core performs the actual connection, DNS, and routing work. Distinguishing the two helps identify whether an update affects client features or underlying protocol capabilities.
Project V is an open-source technology ecosystem built around proxy cores, protocols, and related tools. As the community evolved, its technical line produced core families such as V2Fly and Xray. In everyday use, “V2Ray client” often refers to GUI tools built on compatible cores and protocols rather than one particular interface program.
V2Fly is a community core family that continues the Project V technology line and handles inbounds, outbounds, protocols, DNS, and routing. A GUI client can translate settings selected in its interface into core configuration before starting the relevant core. Support for a new parameter depends on both the client interface and the capabilities of the core it invokes.
Xray is one of the core families in the V2Ray ecosystem, handling protocol connections, transport security, DNS, routing, and other low-level tasks. Clients such as v2rayN and v2rayNG can invoke a compatible core to make the actual connection. When the interface appears normal but the connection fails, core startup messages and configuration errors in the client log are usually more useful than button states.
v2rayN is a desktop GUI client for Windows, macOS, and Linux that manages server profiles, subscription groups, routing, DNS, system proxy settings, and TUN mode. The client handles interaction and configuration orchestration; the invoked core performs the actual protocol connection. After switching cores or upgrading the client, check whether existing configuration fields are still supported by the current combination.
v2rayNG is an Android GUI client that commonly uses the Xray core for protocol connections. It takes over selected traffic through the system VPN service mode and provides configuration import, routing, and per-app settings. Desktop system proxy mode and Android VPN service mode are different interception methods, so their procedures should not be applied interchangeably.
Subscriptions distribute configurations in batches, while a node is the individual connection record ultimately used by the client. Updating, filtering, and latency testing address configuration refresh, list organization, and connection assessment respectively.
A subscription is a configuration bundle URL generated by a service provider. After reading it, the client parses a set of server records. Adding a subscription URL does not mean the nodes have already been refreshed; an update usually needs to be run separately. If the list is empty afterward, check whether the subscription group is enabled, whether the URL is complete, and whether the log reports a parsing error.
A node is a single server connection profile in the client, usually containing an address, port, protocol, identity fields, transport method, and security parameters. The node name is mainly for identification and does not indicate line quality. Choose nodes by considering real connection latency, connection success, usage time, and configuration type together.
Latency describes the time required for a data round trip, but different test buttons in a client may use different methods. A basic test may only check whether the target address is reachable and may not cover the protocol handshake or proxy request. A lower value usually means a faster response, but connection stability, line load, and the destination service also affect the experience.
Real connection latency is measured by starting a connection through the actual proxy path, making it closer to real usage than a basic network probe. It can help distinguish between a reachable server address and a successful protocol connection. The result still reflects only one point in time, so test candidate nodes repeatedly and verify them with actual access.
Subscription groups manage multiple subscriptions by source and separately control their update, filtering, and batch-testing scope. Sensible grouping keeps identically named nodes from different sources apart and makes it easier to identify which set of configurations was affected by an update. Before deleting a group, confirm that its associated nodes and custom settings are no longer needed.
The routing system first identifies traffic characteristics, then decides whether to use a proxy, connect directly, or select another outbound. Rules are usually matched in order, so broad rules should not precede more specific ones.
A routing rule directs traffic to an outbound based on conditions such as domain, IP, port, protocol, or process. Most rules are evaluated in a defined order, and the corresponding action is applied after a match. When adding a custom rule, define the match target and outbound first, and avoid letting an overly broad condition override later rules.
Traffic splitting sends different traffic through a proxy, directly, or to a blocked outbound according to rules. It is not a protocol itself, but a way to use the core’s routing capabilities. If some websites work while some apps fail, check the domain resolution result, rule order, and whether the application is being intercepted by the client.
GeoIP is a data set organized by the geographic region or network range associated with IP addresses and can be used as a destination-IP condition in routing rules. A domain request can be evaluated against the related IP rule only after resolution produces an IP. Outdated data files can reduce matching accuracy, so client updates and rule-data updates should be treated separately.
GeoSite is a collection of domain rules organized by purpose or category and can be referenced directly as a routing condition by supported cores. It classifies domains, unlike GeoIP, which matches address ranges. A request may contain both a domain and its resolved IP information; the final result depends on the rule configuration and matching order.
Domain matching can identify request targets by full domain, subdomain, keyword, or regular expression. Full-domain conditions are the most precise; subdomain rules are useful for covering hostnames under one site, while regular expressions require careful scope control. If an application connects directly by IP, a domain rule may have no hostname available to match.
A client must receive application traffic through the system proxy or a virtual network interface, while DNS converts domain names into information usable for later connections. The interception method and resolution path should be configured together.
TUN mode receives traffic through a system virtual network interface and can cover applications that do not read system proxy settings. It usually involves permissions, routing tables, DNS, and virtual network adapter configuration, so its impact is broader than simply enabling a system proxy. Save the current configuration before enabling it; if network problems appear, disable TUN first and confirm that the basic node connection works.
FakeDNS assigns temporary mapped addresses to domains and restores the original domain information for subsequent connections, commonly working with TUN and routing. This helps the core retain domain-based matching, but the mapped address pool and DNS flow must be configured correctly. Conflicts between the local network, another virtual network, and the address pool can cause connections to be directed incorrectly.
A DNS leak occurs when an application’s domain queries bypass the intended DNS path and are handled by another resolver. Troubleshooting requires checking DNS settings in the operating system, browser, client core, and TUN mode separately. Changing one resolver address may not alter every application’s query path; the key is to confirm which component actually handles the traffic.
A system proxy is the proxy configuration exposed by the operating system for applications to read. Once enabled, programs that follow it send requests to the client’s listening port. Some applications use their own network stack and may not read the system proxy, requiring TUN mode or an in-app proxy setting. Restore the system proxy before exiting the client to prevent the system from pointing to a port that is no longer listening.
DNS settings specify resolvers, query policies, domain rules, caching, and fallback behavior. A client interface may include separate options for system DNS, remote DNS, direct DNS, and core DNS, each serving a different traffic path. Before changing them, determine which resolver should handle each type of domain, then verify the result against the routing rules.