Glossary 25 common terms

V2Ray protocol and configuration terms

Look up terms by configuration layer: distinguish protocols, transports, and security first, then explore cores, subscriptions, and routing. Similar names do not mean settings are interchangeable.

Protocols and transport

The protocol determines how the two sides authenticate and exchange proxy data; the transport determines how that data is carried. The security layer has a separate role, so the protocol name alone does not tell you how the entire connection is encrypted.

Protocols and transport · 01

VMess

VMess is a proxy protocol in the Project V ecosystem. It defines user authentication and data encapsulation and supports different transport methods. When importing a configuration, preserve the user ID, transport type, and security parameters along with the server address and port. Do not copy only a few fields. For older configurations, check what your client supports. An incorrect system clock can also affect authentication, so not every failure means the node is unavailable.

Related term: UUID →
Protocols and transport · 02

VLESS

VLESS focuses on lightweight authentication and forwarding; it does not provide full transport encryption on its own. Assess security in combination with settings such as TLS or REALITY. Seeing VLESS in a client only identifies the proxy protocol; it does not tell you which transport, security layer, or flow-control settings are in use. Keep the field combinations from the provided configuration and confirm that your current core supports them rather than simply changing VMess to VLESS.

Related term: REALITY →
Protocols and transport · 03

Trojan

Trojan typically runs over a TLS-secured connection and uses a password for proxy authentication. The protocol name and client name are two different things. The password, server name, and certificate verification settings all affect whether the connection succeeds, so a correct address and port are not enough. If the handshake fails, check the system clock, server name, and server configuration first; do not treat skipping certificate verification as a universal fix.

Related term: TLS →
Protocols and transport · 04

Shadowsocks

Shadowsocks establishes an encrypted proxy connection using a specified cipher suite and password. The client and server must support the same method. Protocol versions can differ in password format, authentication, and implementation support, so recognizing a share link does not guarantee that a client can use every setting it contains. After importing, check that the encryption method was preserved. Do not substitute methods based on similar names or reuse a password across different protocols.

Read the protocol selection guide →
Protocols and transport · 05

Transport

Transport refers to how a connection carries proxy data. Common options include TCP, WebSocket, and gRPC; these are not standalone node accounts. Transport and security are separate settings: using WebSocket does not automatically enable TLS. Fields such as the path, Host, or service name must match the transport type and server requirements. If details are missing, get the complete configuration instead of guessing field by field.

Related term: SNI →

Cores and clients

The client handles the interface and system integration; the core handles connections, resolution, and routing. Check separately which interface program you downloaded and which core it actually runs.

Cores and clients · 06

Project V and V2Ray

Project V is an open-source proxy technology ecosystem related to V2Ray. V2Ray usually refers to the core program and related technologies, not a particular desktop or mobile interface. In everyday use, “V2Ray client” usually means a graphical app that manages related connection settings, but cores, options, and supported features vary between apps. When following a guide, check the software name and version first; core configuration fields may not match menu labels in the interface.

Related term: Graphical client →
Cores and clients · 07

V2Fly

V2Fly is a community project ecosystem centered on ongoing development of the V2Ray core, which handles protocol processing and connection forwarding. It has technical roots in V2Ray and Xray, but their feature sets, configuration fields, and release cycles differ. Support for the same basic protocol does not mean every configuration is compatible. When using a client such as v2flyNG, choose nodes according to its actual core capabilities and check for core-specific extensions in the configuration.

Related term: Xray →
Cores and clients · 08

Xray

Xray is a proxy core with technical roots in V2Ray and its own protocol extensions and transport security features, including REALITY. To determine whether a configuration will work, check the core version, transport, and extension parameters—not just whether the client offers a “VLESS” option. After updating the interface, check whether the core itself has also changed. The core name in the logs is a better indicator of the active environment than the node label.

Read the core compatibility guide →
Cores and clients · 09

Graphical client

A graphical client manages nodes, imports subscriptions, generates configurations, and integrates with the operating system. Connection handling is usually performed by the core it runs. v2rayN is for Windows, macOS, and Linux desktops; v2rayNG and v2flyNG are for Android, and one key difference is that they use Xray and V2Fly cores, respectively. A setting in the interface does not mean every combination of parameters will work. When troubleshooting, compare the client settings, generated configuration, and core feedback.

Choose a client →
Cores and clients · 10

System proxy

A system proxy is an operating system setting that provides apps with a proxy endpoint. Apps that honor the setting send the relevant requests to the local client. Some apps have their own network settings, so enabling the system proxy does not capture every connection or mean the core sends every destination through a proxy. In “Set system proxy automatically,” “automatically” describes how the client changes system settings; the actual route still depends on app behavior and routing rules.

Related term: TUN mode →

Subscriptions and nodes

A node is a connection configuration, a share link is one way to represent that configuration, and a subscription URL is an entry point for retrieving a set of configurations. A connection test answers a specific question under specific conditions; it cannot replace checking everyday access.

Subscriptions and nodes · 11

Node

A node usually means a set of settings in a client that can be used to establish a connection. It includes the server address, port, protocol, authentication details, and required transport parameters. A node name is just a label, not proof of its geographic location, availability, or connection quality. Entries with similar names may use different settings, while different names may point to the same server. Compare configuration details—not just names—to identify duplicates.

Related term: Share link →
Subscriptions and nodes · 13

Subscription URL

A subscription URL lets a client fetch a set of connection configurations and subsequent updates. The client retrieves the content and parses it in a supported format. It serves a different purpose from a single share link, and an ordinary web address is not necessarily a valid subscription. If a request succeeds but no nodes appear, check the response content and format compatibility. A subscription URL may contain access credentials, so store it securely; updates may also overwrite manual changes in the subscription group.

View the subscription setup steps →
Subscriptions and nodes · 14

TCPing

TCPing usually measures how a target address and port respond by attempting to establish a TCP connection. The exact behavior and timing depend on the test tool. It can help check whether a port is reachable, but does not fully verify proxy authentication, TLS negotiation, or whether the final request succeeds. A successful TCPing result alongside a page that will not load is not a contradiction. Check the full connection path instead of choosing a node based only on this result.

Related term: Real connection latency →
Subscriptions and nodes · 15

Real connection latency

Real connection latency usually refers to the time a client takes to send a request through a proxy configuration to a specified test address. Whether the measurement includes resolution, handshake, or connection reuse depends on the implementation. Results vary with the test address, DNS, routing rules, and current network conditions. Compare results under consistent conditions and confirm that the test request used the expected outbound route. Lower latency does not mean higher download bandwidth, and one timeout does not prove that all destinations are unreachable.

Read about connection tests and verifying they work →

Routing and traffic routing

First confirm that traffic reaches the client, then check which rule matches and which outbound route it uses. Traffic capture, DNS resolution, and route selection are related but distinct steps.

Routing and traffic routing · 16

Routing rules and traffic routing

Routing rules direct connections to a specified outbound route based on criteria such as domain, IP, port, or inbound connection; traffic routing is the process of choosing a path based on those criteria. Common routes include direct, proxy, and block, but names and rule structures depend on the configuration. Most rules are evaluated in order, so a broad condition earlier in the list can override a more specific one later. To troubleshoot a site's route, check the destination details, rule order, and default route—not just the selected node.

Related term: GeoSite →
Routing and traffic routing · 17

GeoIP

GeoIP is categorized data organized by IP address ranges. Routing rules can use these collections to match destination addresses without listing every subnet manually. Categories are updated periodically, and changes in cloud service, CDN, or IP address ownership can affect matches. GeoIP cannot pinpoint a server's actual location or connection quality. Whether an IP rule applies to a domain request also depends on the resolution strategy, so a rule's presence does not guarantee that every request will match it.

Related term: Routing rules and traffic routing →
Routing and traffic routing · 18

GeoSite

GeoSite is a collection of domains organized by category. Routing rules can reference a category to manage related domains, such as those used for advertising. The category only provides a matching condition; the rule's outbound route determines whether traffic goes direct, through a proxy, or is blocked. Referencing a category does not automatically change how a connection behaves. Categories are updated, so check that the data file, category name, and core are compatible. Related domains used by an app may not all belong to the same category.

Related term: GeoIP →
Routing and traffic routing · 19

TUN mode

TUN mode receives and processes IP packets through a virtual network interface. It is often used to cover apps that do not follow system proxy settings, but actual traffic capture depends on routing, permissions, and the client implementation. Consider DNS handling, local network access, and interactions with other virtual network interfaces; enabling TUN alone does not replace all configuration. If app behavior changes, check the route and logs to confirm the traffic path and avoid conflicts from enabling multiple traffic-capture features at once.

Related term: System proxy →
Routing and traffic routing · 20

FakeDNS

FakeDNS assigns synthetic IP addresses to domains and restores the domain through a mapping later in a controlled connection path. This helps the proxy retain domain information for processing and routing. A synthetic address is not the website's actual server address. The mechanism depends on coordinated DNS interception, mapping state, address ranges, and routing settings. If a query returns a synthetic address but the connection bypasses the client, access may fail. After switching modes, also account for old DNS results cached by the system or app.

Related term: DNS leak →

Encryption and security

Authentication identifies the user making a connection; the security layer protects communications and verifies identity. Importing a share link does not guarantee that its parameters match, and it does not mean verification errors can be ignored.

Encryption and security · 21

TLS

TLS is a security protocol that protects data in transit and verifies the identity of the communicating party. In proxy configurations, it often appears as a separate security layer. Certificate trust, server name matching, and system time can all affect the handshake; protocol negotiation settings must also match the server. Skipping certificate verification weakens identity checks and should not be a routine setting. If an error occurs, first investigate the server name, certificate chain, or system clock.

Related term: SNI →
Encryption and security · 22

REALITY

REALITY is a transport security mechanism in the Xray ecosystem, not a proxy protocol at the same level as VLESS. They are often used together but serve different purposes. The client and core must support REALITY, and the server name, public key, short ID, and other parameters must match the server configuration. Check the required fields for your setup. REALITY does not guarantee that the entire application connection is configured correctly: verify authentication, transport, and routing separately. Do not apply it by simply renaming a standard TLS configuration.

Read about REALITY and protocol combinations →
Encryption and security · 23

SNI

SNI is a TLS handshake extension that specifies the target server name. A client may label the related field “Server name” or serverName. The connection address and this name can differ, but the name must meet the server's requirements and match certificate validation rules. Do not enter an arbitrary value. SNI and the WebSocket Host field apply at different stages; even if an example uses the same value for both, one is not a general replacement for the other.

Related term: Transport →
Encryption and security · 24

UUID

UUID is a user identifier commonly found in VMess and VLESS configurations and is used in the corresponding protocol's authentication process. It is usually represented as a hyphenated hexadecimal string. It is not a server address or an encryption key; its specific role depends on the protocol, and a correctly formatted value does not guarantee the server will accept it. Treat UUIDs in real configurations as authentication credentials. When copying one, avoid adding spaces or truncating it, and do not use example values from a tutorial as a working account.

Related term: Share link →
Encryption and security · 25

DNS leak

A DNS leak usually means that domain lookup requests took an unintended route. Before investigating, determine which queries are expected to be handled locally and which should use a specific outbound route. Browser-level resolution, system DNS, client DNS, and app caches can all affect access, so a resolver name in a single test result is not enough to identify the cause. Check client logs and actual rules step by step. Enabling TUN or encrypted DNS does not guarantee that every DNS request will follow the same route.

Common connection and DNS troubleshooting →