V2Ray Glossary: Subscriptions, Protocols, Routing & TUN Mode

Identify Connection Settings

Protocols & Transports

A protocol defines how communication works, a transport carries the connection, and a security layer protects it. Check each separately when importing a profile; these terms don't refer to interchangeable settings.

VMess: A proxy protocol in the Project V ecosystem that uses parameters such as a user ID for authentication and communication. Along with the address and port, match the transport and security settings to the server. Seeing VMess confirms the protocol type, but doesn't tell you whether TLS is enabled or eliminate the need to configure transport settings.

VLESS: Distinguish the lightweight proxy protocol from its encryption layer: VLESS doesn't encrypt content by itself and is commonly used with a security layer such as TLS or REALITY. In the client, check the user ID, transport, and any flow parameter required by the server. Don't turn a VMess profile into VLESS just by renaming it; the server must support the protocol you use.

Trojan: A proxy protocol that typically relies on TLS to protect communications and uses password-based authentication. After importing, make sure the domain, port, password, and TLS settings still match the server—especially the server name. For certificate errors, check the domain, device clock, and certificate settings first; don't simply disable certificate verification.

REALITY: Think of REALITY as a transport security mechanism in the Xray ecosystem, not a standalone node protocol. It's commonly paired with VLESS. The server name, public key, short ID, and other settings must match, and the core must support this configuration. A server address and user ID alone usually aren't enough to recreate a complete connection profile.

Separate the Interface from the Core

Cores & Clients

Identify the client first, then check which core it actually uses. A setting being available in the interface doesn't mean the current core can run it.

Project V: Think of Project V as an open-source ecosystem built around networking tools such as V2Ray, not as the name of a desktop installer. When discussing configuration, distinguish the ecosystem, the core, and the graphical client. For interface instructions, check the client guide; for protocol support, check the core in use and the configuration requirements.

Xray: A proxy core project with technical roots in V2Ray, responsible for handling protocols, transports, and routing—not just a label in the interface. v2rayNG uses the Xray core, and v2rayN can also use Xray configurations. Features depend on the core version; when troubleshooting compatibility, note both the client and core details.

V2Fly: Distinguish the community from the software core: V2Fly is the community that maintains V2Ray-related projects, and V2Fly core usually refers to the V2Ray core it maintains. v2flyNG is an alternative Android client that uses this core. Don't assume Xray-specific settings can be transferred unchanged just because the projects are technically related.

Graphical Client: Use a client to manage subscriptions, connection profiles, and proxy settings; the core handles network traffic. v2rayN is for Windows, macOS, and Linux desktops, while v2rayNG and v2flyNG are for Android. Menus, defaults, and backup contents may differ between clients. Sharing a subscription doesn't sync all local settings.

Understand Imports and Tests

Subscriptions & Nodes

A subscription provides a source for profiles, a node is one connection profile, and latency is a test result measured under specific conditions. Check each separately.

Subscription: Use a subscription URL to fetch and update a set of connection profiles instead of entering each one manually. In v2rayN, save the URL under “Subscription Group Settings,” then update the subscription. In v2rayNG, add a group and update it as well. Subscription URLs may contain access credentials, so don't share them or include them in public screenshots. A failed update doesn't necessarily mean existing profiles have stopped working.

Node: A node is a selectable connection profile in the client, typically containing a server address, port, authentication details, protocol, and transport settings. Its display name is just a label, not a guarantee of what the connection can do. Treat authentication details as sensitive when sharing a profile. An update may replace or remove existing entries.

Latency: Check which test is being used before comparing results: a TCP connection test and a request sent through a proxy measure different things. Results vary with the network path, test endpoint, server load, and timeout threshold. Low latency doesn't mean high download speed, and a timeout should be considered alongside real-world access and logs—not as a standalone number in a list.

Real Connection Latency: The client sends an actual request to a test endpoint through the selected proxy profile and measures the time taken. This is closer to an application request than a test of the server port alone. Depending on the client and endpoint, the test may involve DNS resolution, a handshake, and a response from the destination. For a fair comparison, keep the endpoint and network conditions consistent. Failure with one endpoint doesn't prove that every site is unreachable.

Track Where Traffic Goes

Routing & Split Tunneling

Check the match criteria, then the outbound and rule order. Rules with similar names don't necessarily cover the same domains or IP ranges.

Routing Rule: Match connections by domain, destination address, port, or other criteria, then send them to a specified outbound. In common core configurations, rules are checked in order, so an earlier rule may override a later one. In v2rayN routing settings, check the criteria, outbound, and order; unmatched connections are also affected by the default outbound.

Split Routing: Split routing sends different connections through different outbounds, such as direct, proxy, or block. “Bypass mainland China” is a common routing preset name; its actual behavior depends on the rules and data it uses. Split routing isn't just a toggle: DNS results, domain information, and routing matches need to work together so connections reach the intended outbound.

GeoIP: Use IP address lists grouped by region or purpose for routing matches; they don't directly classify domains. Data can be inaccurate due to changes in network allocations and update schedules, and doesn't guarantee a server's physical location. If a domain resolves to a different address, the match may change too. Check both the DNS result and the address list when troubleshooting.

GeoSite: Use domain rules grouped by category instead of maintaining large lists of domains manually. Category names, contents, and coverage depend on the data file; different sources don't necessarily offer the same categories. If a rule doesn't work, first confirm the category exists and the data is available, then check the rule order and whether the core has a domain name to match.

Check the Resolution Path

DNS & Networking

Consider separately which address a domain resolves to and which path the query takes. Apps, the operating system, and the client may each have their own DNS settings.

DNS: DNS resolves domain names to IP addresses and other records so apps can find the destination service. In a proxy setup, consider which resolver handles the lookup, which resolver it queries, and whether the request goes direct or through the proxy. Changing system DNS may not affect remote resolution in the client; encrypted DNS enabled in a browser may also use a separate path.

FakeDNS: Assigns synthetic addresses to domains and stores the mappings, allowing the core to recover the original domain when a connection arrives and use it for routing. It's not a regular public DNS server, and setting a resolver address alone won't enable it. Before turning it on, make sure the core, DNS configuration, and traffic interception mode work together; otherwise, an address may resolve while the connection still fails.

DNS Leak: Check whether domain lookups follow the intended path. Queries sent through another resolver or network interface may bypass the planned setup. To diagnose this, consider system DNS, encrypted DNS in the browser, client settings, and routing policies—not just the exit IP. Local resolution for domains sent direct may be intentional; what matters is whether the actual path matches the configuration goal.

Domain Sniffing: Reads destination domain information from recognizable protocol details in a connection to help the core match domain-based routing rules. What it can identify depends on the protocol, encryption, and implementation; it won't work for every connection and doesn't decrypt app content. When changing settings, distinguish options that assist routing from those that override the destination address, so connections don't go somewhere unexpected.

Separate Traffic Capture from Routing

Proxy Modes

Traffic capture determines which connections enter the client; routing determines what happens to them afterward. These are separate settings and can't replace each other.

System Proxy: Registers a local proxy address with the operating system so apps that follow system proxy settings send requests to the client. In v2rayN, options such as “Set system proxy automatically” control this setting, but it doesn't capture traffic from every program. If a browser works but another app doesn't, check whether the app uses the system proxy or has its own proxy settings.

TUN Mode: Receives and handles traffic through a virtual network interface, including traffic from some apps that ignore system proxy settings. To enable Tun in v2rayN, make sure you have the required permissions and network conditions, and check for conflicts with other virtual network adapters. System routes, exclusions, and client rules still determine what gets captured; turning it on doesn't mean every connection goes through the proxy.

VPN Mode: On Android, clients such as v2rayNG can receive traffic through the system VPN interface. The system typically asks for permission the first time you connect. This describes how traffic enters the client; it doesn't replace the node's protocol. App selection, routing rules, and system settings still affect what gets handled, and another active VPN service may cause conflicts.

Global Proxy: Usually means sending connections that reach the client—and aren't excluded by higher-priority rules—to the proxy outbound. The exact meaning depends on the menu where the setting appears. It describes how traffic is handled, not whether all device traffic has been captured. If an app bypasses the system proxy, switching to a global routing mode won't capture it; check traffic capture first, then the outbound rules.

V2Ray Terms and Settings Explained

Protocols & Transports

Cores & Clients

Subscriptions & Nodes

Routing & Split Tunneling

DNS & Networking

Proxy Modes