Configuration Reference
6 categories · 24 terms
V2Ray Glossary:
Protocols, Subscriptions, and Traffic Routing
Start by distinguishing protocols, cores, and clients, then follow the settings a request passes through. Each glossary entry explains what a term means, where it is used, and what it is often confused with. Browse by category to find what you need.
For example, VLESS is a proxy protocol, REALITY is a secure transport, and Xray is a core. All three can appear in the same connection configuration.
Protocols & Transport
A protocol defines how proxy requests are exchanged; transport settings define how data is carried. When troubleshooting a connection, check these layers separately instead of relying on the node name alone.
- VMess
- VMess is a proxy protocol in the Project V ecosystem that authenticates using parameters such as a user ID. After importing a connection, check that the address, port, user ID, and transport settings match the server. An incorrect system clock can also affect authentication, so sync the time before changing unrelated routing rules when authentication fails.
- VLESS
- VLESS is a lightweight proxy protocol that does not encrypt traffic itself. It is commonly paired with a security layer such as TLS or REALITY. The user ID, flow control, and transport options each serve a different purpose, so they cannot be swapped between nodes just because both use VLESS. Keep the server-provided settings after importing, especially flow control values; do not add or remove them yourself.
- Trojan
- Trojan is a proxy protocol typically carried over TLS and authenticated with a password. A correct password only suggests that the authentication details may match; it does not confirm that the certificate, service name, or transport settings are correct. If the handshake fails, troubleshoot TLS separately from password authentication, using the specific stage shown in the client logs.
- Transport Settings
- Transport settings define how proxy traffic is carried, such as over TCP, WebSocket, or gRPC. They are separate from proxy protocols such as VMess and VLESS. WebSocket paths and request headers, as well as the gRPC service name, may be used to match the server configuration. Renaming the protocol will not fix mismatched transport settings, and available combinations also depend on the core version.
Cores & Clients
The client presents settings; the core handles network traffic. To determine whether an option is supported, check the client interface, selected core, and version.
- Project V
- Project V is the network tools and technical ecosystem that grew around V2Ray, not a single desktop app with a fixed interface. When reading documentation, distinguish the project background from the core that runs and the graphical client that manages connections. Related projects may share concepts and configuration structures without having identical features, fields, or defaults.
- V2Fly
- V2Fly is a community project continuing V2Ray development. Its v2fly core handles connections, routing, DNS, and other network functions. On Android, v2flyNG is an alternative client from the same core family. Check which core the documentation targets, and do not apply fields introduced in other forks without confirming support.
- Xray
- Xray is a core fork built on V2Ray technology, with its own protocol implementations and evolving configuration. v2rayNG uses the Xray core, and desktop clients may also offer it as an option. Check support against the current core version and client; the client name alone does not tell you whether a protocol combination will work.
- Graphical Client
- Graphical clients organize subscriptions, nodes, routing, and proxy controls in an interface, then generate or pass configuration to the core. v2rayN is for Windows, macOS, and Linux desktops; v2rayNG and v2flyNG are for Android. A status such as “Started” generally means the relevant process is running; it does not confirm that requests are working.
For help choosing a client, see the comparison of three clients. Find installation links on the client downloads page.
Subscriptions & Nodes
A subscription distributes configurations; a node is a set of connection parameters. Latency tests are useful indicators, but they do not replace checking real-world access and connection stability over time.
- Subscription
- A subscription lets you retrieve multiple connection configurations from a single URL. Refreshing it sends another request to that address, which typically contains a private access token. Do not share the URL in screenshots, chat messages, or public logs. A successful refresh only confirms that configurations were fetched; it does not mean every node works. For instructions, see the subscription import guide.
- Node
- A node is a set of remote connection parameters, typically including an address, port, protocol, authentication details, and transport settings—not just a server name. Providers may assign custom aliases, so a name alone cannot confirm a node’s location, bandwidth, or availability. Sharing a node link may also expose access credentials; redact sensitive details before reporting an issue.
- Latency
- Latency is the time taken to complete a probe or request. Results depend on the test method, target location, and current network conditions. A TCP port connection test is not equivalent to loading a webpage through a proxy, so the results should not be compared directly. Low latency also does not mean fast downloads: sustained transfers are affected by congestion, packet loss, server load, and bandwidth limits.
- Real Connection Latency
- Real connection latency typically measures the time taken by a client to reach a test target through a proxy; the exact timing depends on the implementation. It is closer to the real usage path than simply checking a remote port, but still reflects only one test to one target. If the test succeeds but a particular website will not load, also check its DNS resolution, routing matches, and how the app handles proxy settings.
Routing & Traffic Rules
First check whether the request reaches the core, then identify which outbound the rules select. Domain rules, IP rules, and DNS behavior need to be understood together.
- Routing Rules
- Routing rules select an outbound for a request based on conditions such as domain, IP, or port. Rule order affects which rule matches. In supported cores,
domainStrategy: "IPIfNonMatch"means that if no domain rule matches, the core attempts to resolve the IP and match against it. This does not route all traffic through a proxy; the rules and default outbound still determine where requests go.
- GeoIP
- GeoIP is a collection of IP addresses grouped by region or use for routing-rule matches. It reflects database classifications, not proof of a visitor’s or server’s exact location. Cloud hosting, changes in IP ownership, and data update frequency can all affect results. If traffic is routed incorrectly, check the resolved IP and the data file in use.
- GeoSite
- GeoSite is a collection of domains grouped by service, category, or region, often used to route groups of websites consistently. Unlike GeoIP, it matches domains rather than IP addresses. A category referenced by a rule must exist in the current data file, and the request must retain its domain for matching. A valid category name does not guarantee that every request will match.
- Traffic Routing
- Traffic routing assigns different requests to outbounds such as direct, proxy, or block based on rules; it is not a standalone proxy protocol. Client modes such as “Bypass mainland China” usually apply a set of preset rules, whose details vary by implementation and data file. After changing rules, test destinations that should go direct and those that should use a proxy, then check the logs to confirm the actual outbound rather than relying on the mode name.
Encryption & Security
The connection address, service name, user authentication, and security layer each have a distinct role. For handshake errors, check the relevant settings; disabling verification is not a routine fix.
- REALITY
- REALITY is a secure transport in the Xray ecosystem, commonly used with VLESS but not another name for VLESS. Enter the public key,
serverName,shortId, and other parameters as specified by the server; some fields may be left empty. Import the complete configuration whenever possible. Do not substitute an arbitrary domain or a public key from another node.
- TLS
- TLS encrypts network connections and verifies identity; HTTPS uses the same type of security protocol. Clients typically validate the certificate chain, target hostname, and certificate validity period, so an incorrect system clock can also cause connection failures. If you see a certificate error, check the clock and server configuration first. Disabling certificate verification weakens authentication and does not solve the underlying problem.
- SNI
- SNI is an extension in the TLS handshake that specifies the target service name. In client interfaces, the related field is often
serverName. The connection address and the name used in the handshake may differ, but the combination must match the server configuration. The WebSocket Host, SNI, and certificate name are not interchangeable fields; check each one separately when troubleshooting.
- UUID
- A UUID is a universally unique identifier often used as a user ID in VMess and VLESS connection configurations. Its string value is different from its display name; missing a character or adding a space when entering it can cause authentication to fail. Treat a UUID used for connection authentication as a credential. Generating a new one at random will not replace the value configured on the server, even if the address and port stay the same.
System & Networking
System proxy and TUN mode capture different amounts of traffic, and DNS queries may also take a separate path. To check whether a configuration is behaving as expected, consider the app, system, and core together.
- TUN Mode
- TUN uses a virtual network interface to pass IP traffic to a network handler, allowing it to capture traffic from some apps that do not follow system proxy settings. The actual coverage depends on system routes, exclusions, permissions, and the implementation; enabling it does not guarantee that all traffic will be captured. Before turning it on, check permissions and potential conflicts with other virtual networking tools. For setup steps, see the TUN mode guide.
- System Proxy
- The system proxy is a proxy setting provided by the operating system for apps to use. It often points to a local address and port monitored by the client. Only apps that follow this setting will use it; some games, command-line tools, and apps with their own network settings may not. If the client exits but leaves a broken proxy setting enabled, webpages may stop loading. Check the system proxy status and whether a local listener is running.
- FakeDNS
- FakeDNS returns virtual addresses for internal use and stores the mappings to their original domains. When subsequent traffic enters the same processing path, the core can use those mappings to restore the domain and help determine routing. FakeDNS is not a direct replacement for a public DNS resolver; it must work with traffic capture, routes for the virtual address range, and the mapping lifecycle. Otherwise, resolution may succeed while connections fail.
- DNS Leak
- A DNS leak occurs when domain lookups do not follow the expected resolution path—for example, when they are supposed to use a specified resolver but are sent by the system or app instead. Browser secure DNS, system resolver settings, client DNS, and routing rules can all affect where queries go. Interpret test results in light of your intended policy: a local resolver is not necessarily a problem. First determine which requests are meant to go direct.