V2Ray Glossary

Protocols define how connections are represented, cores handle traffic, and clients manage configuration. Identify which layer a concept belongs to, then look up the relevant setting.

Menus in v2rayN, v2rayNG, and v2flyNG can change between versions. These explanations focus on how the concepts differ; check the current client and its integrated core for specific features. Link to any term card by its heading.

Protocols and Transport

Configure the proxy protocol, underlying transport, and security layer separately. Matching names do not guarantee matching parameters.

VMessProtocols and Transport · Proxy Protocol
VMess is a proxy protocol in the Project V ecosystem that provides user authentication and encrypted transport. Modern configurations typically use AEAD authentication. VMess connections require matching client and server settings for the user ID, transport, and security layer; a significant system clock difference can also affect authentication. A VMess share link is just one way to package these parameters, and importing it successfully does not guarantee a working configuration.
VLESSProtocols and Transport · Proxy Protocol
VLESS is a lightweight proxy protocol that does not encrypt payloads on its own. It is typically used with a security layer such as TLS or REALITY. In addition to selecting VLESS, configure the transport, server name, and any required flow control parameters. VLESS is not inherently faster; performance still depends on connection quality, server load, and the overall configuration.
TrojanProtocols and Transport · Proxy Protocol
Trojan is a proxy protocol typically run over a TLS-secured connection and authenticated with a password. A Trojan configuration needs more than the password: enter the correct server address, port, and server name, and validate the certificate. If a Trojan connection reports a certificate error, check the domain, system time, and server certificate before considering any change to validation settings.
ShadowsocksProtocols and Transport · Encrypted Proxy Protocol
Shadowsocks is an encrypted proxy protocol. Common settings include the server address, port, password, and encryption method. Key formats can differ between protocol generations, and a core may not support every encryption method. After importing a Shadowsocks entry, retain its original algorithm and key rather than replacing them just because other options appear in the menu.
REALITYProtocols and Transport · Transport Security
REALITY is a transport security option supported by Xray, not a proxy protocol at the same layer as VMess or VLESS. A common setup pairs VLESS with REALITY. Client settings must match the server name, public key, short ID, and other parameters. REALITY cannot be enabled simply by toggling an option: the server must support it, and the client interface and core must be able to represent the required configuration.

Cores and Clients

The core determines protocol support; the GUI client imports, manages, and invokes configurations. They are updated separately.

XrayCores and Clients · Proxy Core
Xray is an independent proxy core project that evolved from V2Ray code. It handles protocols, routing, and network connections, and supports features such as REALITY. Xray is not a GUI: v2rayN and v2rayNG translate interface options into configurations the core can read. Available features depend on the integrated Xray version; an option in the interface does not mean an older core can use it.
V2FlyCores and Clients · V2Ray Project
V2Fly is a community-maintained V2Ray project ecosystem. Its core and Xray have evolved separately while retaining some similar configuration concepts. Their protocol implementations, configuration fields, and feature support are not identical, so they cannot be treated as interchangeable executables. When migrating a V2Fly configuration, verify the protocol, security layer, and routing syntax one by one instead of simply changing the core name.
v2rayNCores and Clients · Desktop GUI Client
v2rayN is a desktop GUI client for managing servers, updating subscriptions, setting routing presets, and configuring proxy access. Its interface organizes parameters and generates the configuration; the selected core handles network traffic. Updating the GUI and updating the core are separate tasks. When troubleshooting v2rayN, check the selected server, core, system proxy, and routing status rather than assuming the connection works because the window opens normally.
v2rayNGCores and Clients · Android GUI Client
v2rayNG is an Android GUI client based on the Xray core. It can capture device traffic through Android's VPN interface and includes subscription and routing management. VPN permission only means Android allows traffic capture; it does not confirm remote authentication, DNS resolution, or access to the destination. Background operation can also be affected by battery policies, so check system restrictions and client logs if the connection drops.
v2flyNGCores and Clients · Alternative Android Client
v2flyNG is an Android client based on the V2Fly core ecosystem, suited to setups that require its configuration capabilities. Despite the similar names, v2flyNG and v2rayNG do not necessarily support the same protocol extensions, and Xray-specific parameters may not apply. Before importing a subscription, confirm that its protocol and transport combinations are supported by the current version.

Routing and Traffic Splitting

Traffic first enters the client; rules then determine where it goes. Understand traffic capture and outbound selection as separate steps.

Routing Rules and Traffic SplittingRouting and Traffic Splitting · Outbound Selection
Routing rules send connections to a specified outbound route based on conditions such as domain, destination IP, or port. Traffic splitting is the result of classifying and forwarding connections by those conditions. Rules are usually evaluated in order, so a broad rule near the top can prevent more specific rules from taking effect. When troubleshooting, also check the default route for unmatched traffic and whether the client has the domain or address information required by the rules.
GeoIPRouting and Traffic Splitting · IP Address Sets
GeoIP is a collection of IP addresses grouped by region or purpose. Routing rules can reference these collections instead of listing address ranges individually. Matching depends on the data file and the destination address; changes in address allocation, shared infrastructure, and DNS results can all affect the outcome. A GeoIP label describes a dataset category, not a definitive guarantee of a server's physical location or operator.
GeoSiteRouting and Traffic Splitting · Domain Sets
GeoSite is a collection of domains grouped by service or purpose. The core can use a collection label to match related domains. Available labels and their contents depend on the loaded data file, so datasets may differ between clients. GeoSite rules also need domain information: if only the destination IP is available, check DNS, domain sniffing, or the traffic capture method.
System ProxyRouting and Traffic Splitting · App Traffic Capture
A system proxy is a proxy address setting provided by the operating system to apps that respect it. v2rayN can set its local listening address as the system proxy for those apps. It does not automatically capture traffic from every program or guarantee that every type of network traffic passes through the client. System proxy and routing are separate: the proxy directs app traffic into the client, while routing decides whether that traffic goes direct, through a proxy, or is blocked.
TUN ModeRouting and Traffic Splitting · Virtual Network Interface
TUN mode captures IP traffic through a virtual network interface and is often used for apps that ignore system proxy settings. Its actual coverage depends on system routing, permissions, exclusions, and DNS configuration; some traffic may still go direct. Running TUN alongside other virtual network adapter tools can cause routing conflicts. When troubleshooting, start by reducing the number of components managing network traffic at the same time.

DNS and Networking

Successful resolution, a successful connection, and fast browsing are different measures. Interpret test results in light of what each test measures.

DNSDNS and Networking · Domain Name Resolution
DNS resolves domain names into IP addresses and other records, an important step before visiting most websites. DNS queries and application connections can take different paths: a connection going through a proxy does not mean its DNS query uses the same outbound route. DNS settings also affect routing matches and address selection, so consider app-level encrypted DNS, the system cache, and the core's DNS settings together.
FakeDNSDNS and Networking · Virtual Address Mapping
FakeDNS assigns temporary addresses to domain names from a pool of virtual addresses. When a connection arrives, the core can recover the domain information and route traffic by domain. Addresses returned by FakeDNS are not real server addresses and cannot be used for ordinary network access without their corresponding mappings. FakeDNS can interact with app caches and address exclusion rules; if issues arise after changing these settings, check that the caches and mappings are still consistent.
DNS LeakDNS and Networking · Unexpected Resolution Path
A DNS leak occurs when DNS queries take an unintended path, exposing query information to resolvers that were not meant to handle it. Do not judge a DNS leak solely by the region shown on a website; check the resolver, client logs, app-level DNS, and system settings. If DNS routing is explicitly configured to resolve some domains locally, those expected queries are not leaks merely because they bypass the proxy.
LatencyDNS and Networking · Response Time
Latency is the time taken for a specific network operation to receive a response, and results must be interpreted in light of the test method. A latency test may measure only a TCP connection or ICMP response, or include a proxy handshake and web request, so values from different tools are not directly comparable. Lower latency does not mean higher bandwidth; throughput, packet loss, and server load also affect real-world performance.
Proxy Connection LatencyDNS and Networking · Proxied Request Test
Proxy connection latency typically measures how long the client takes to reach a test address through the selected proxy configuration, making it more representative of the full request path than a simple server port probe. Results depend on the test address, DNS resolution, handshake, and timeout settings; they do not represent the response time of every website. A timeout does not necessarily mean all destinations are unreachable, so check the logs and retest with another real destination.

Subscriptions and Configuration

The source of a configuration determines which parameters it contains. After importing it, check core support and test the connection.

SubscriptionSubscriptions and Configuration · Bulk Configuration Retrieval
A subscription lets a client retrieve a set of server configurations from a URL. When updated, the client fetches the source again and syncs the corresponding entries. Subscription links may contain credentials and should be stored securely; avoid sharing the full URL in screenshots, logs, or public discussions. Updating a subscription only refreshes its configuration content. It cannot resolve issues such as an incompatible core, a system proxy that is not capturing traffic, or an unreachable server.
Server EntrySubscriptions and Configuration · Single Server Configuration
A server entry is a common client term for a single server connection configuration, typically including the address, port, proxy protocol, authentication, and transport parameters. Its name is only a management label, not proof of location, bandwidth, or availability. If an entry fails, check its individual fields; the same server address can have multiple configurations with different ports, protocols, or credentials.
Subscription Format CompatibilitySubscriptions and Configuration · Parsing and Parameter Retention
Subscription format compatibility describes whether a client can correctly parse subscription content and preserve all parameters needed for a connection. A subscription may be a collection of share links or use a specific configuration structure, so the file extension alone cannot establish compatibility. Reading the content, importing entries, and having the core run the configuration are three separate checks. Format conversion cannot restore parameters missing from the source.
Custom ConfigurationSubscriptions and Configuration · Direct Core Configuration
A custom configuration provides a core configuration file directly to the client rather than relying entirely on parameters generated by the GUI. It is often used for more detailed inbound, outbound, and routing settings. The configuration must match the core type and version, and some GUI options may no longer apply. When troubleshooting, first confirm which file is actually loaded and review the logs; do not assume GUI presets reflect the active settings.