REFERENCEConfiguration terms and concepts
V2Ray Glossary
Protocols define how connections work, the core handles forwarding, and the client provides the settings interface. Start by distinguishing these layers, then explore subscriptions, routing, and DNS.
PROTOCOL / TRANSPORT
Protocols and transports
Protocols, transports, and security layers are separate settings. The same protocol can use different transport combinations, so check each setting against the server configuration after importing.
- VMess
- A proxy protocol in the Project V ecosystem that identifies users with parameters such as UUIDs and has its own data protection mechanism. VMess is not the same as WebSocket or TLS, which belong to the transport and security layers. When troubleshooting, check the transport as well as the address and port. For older configurations, verify that additional parameters are supported by the current core.
- VLESS
- A lightweight proxy protocol that does not encrypt traffic on its own and is generally deployed with TLS or REALITY. The UUID, transport,
flow, and security options must match the server. A link starting withvless://does not mean its parameters are interchangeable. A client recognizing a link also does not guarantee that its current core supports every optional field.
- Trojan
- A proxy protocol typically used over TLS that authenticates with a password, unlike configurations that use a UUID. The server name, certificate verification, port, and password all affect whether the connection succeeds. For certificate errors, first check the domain, system clock, and server certificate; disabling certificate verification should not be treated as a routine fix.
- REALITY
- A transport security mechanism in the Xray ecosystem, commonly used with VLESS but not a standalone subscription format. Enter the public key,
shortId,serverName, and other parameters correctly; field labels vary by interface. Matching the protocol name is not enough—the core must also support the security layer and transport combination.
CORE / CLIENT
Cores and ecosystem
The client provides the interface; the core handles the actual connection. To determine which features are supported, check both the client options and the core currently in use.
- Project V
- An ecosystem of projects and tools built around V2Ray networking and proxy technology, not a server configuration you can import directly. Distinguish the GUI client, proxy core, and connection settings when interpreting the term. Open-source licenses define how code may be used and distributed; they do not establish the trustworthiness of a subscription source, server operator, or local configuration.
- Xray
- A proxy core evolved from V2Ray-related technology that handles protocols, routing, and connection forwarding. v2rayNG uses the Xray core, but supported features still depend on the bundled core version. Updating the GUI and updating the core are separate things; if a configuration field is unsupported, first check which core is actually running.
- V2Fly
- A community project that continues to maintain the V2Ray core and provides core protocol, routing, and DNS capabilities. V2Fly and Xray share some technical roots, but their feature development, field meanings, and support differ. v2flyNG is an alternative Android client; check your existing configuration before switching rather than assuming the two cores are interchangeable.
- GUI client
- An app that provides controls for importing subscriptions, browsing server lists, choosing proxy modes, and viewing logs. v2rayN is for Windows, macOS, and Linux desktops; v2rayNG and v2flyNG are for Android. A single interface toggle may generate several low-level settings, so a field in the native JSON documentation may not have a matching input in the settings page.
Choosing a client? Compare platform support and core differences across three clients.
SUBSCRIPTION / CONNECTION
Subscriptions and nodes
A subscription is a way to retrieve configurations; a node is an individual connection entry. Seeing a list only confirms that its contents were read—it does not mean a remote connection was established.
- Subscription
- A way to retrieve and update connection configurations in bulk, usually through a URL. v2rayN can use subscription groups to manage different sources. An update may add, replace, or remove nodes, and whether local edits are preserved depends on the client. Subscription URLs may contain access credentials; hide the full URL in screenshots and logs, and do not share it as if it were an ordinary public link.
- Node
- A selectable set of server connection settings in the client, usually including an address, port, protocol, authentication details, and transport settings. An alias is just a label for identification; it does not reveal the server's actual location, bandwidth, or availability. Switching nodes changes the connection configuration, but may not help if the problem is local DNS or the proxy entry point.
- Real connection latency
- The time measured when accessing a test target through the selected proxy; the exact timing depends on the client. A basic TCP latency test usually measures only the time to connect to a port, while a real connection test is closer to an actual proxy request. Results still depend on the target, DNS, and network conditions at the time. Compare results under the same conditions; a lower number does not mean faster sustained downloads.
Ready to try it? Start with the subscription import and first connection tutorial.
MATCH / OUTBOUND
Routing
Match conditions first, then choose an outbound. Rule data, match order, and outbound tags work together to determine how a connection is forwarded.
- Routing rules
- A set of rules that selects an outbound based on conditions such as domain, IP, port, or protocol, usually evaluated in configuration order. A broad rule placed first can prevent more specific rules below it from matching. After changing the routing profile in v2rayN, check the default outbound and rule order as well; the selected server in the interface is not necessarily the outbound used for every connection.
- GeoIP
- A collection of IP addresses referenced by routing rules, organized by region or purpose. For example,
geoip:privaterepresents a set of private addresses. It relies on a local data file and support from the current core; it is not a real-time location service. Address classifications can change as networks are reassigned. If traffic is routed incorrectly, check which rule matched and whether the data is up to date—not just the server alias.
- GeoSite
- A collection of domains grouped by site, service, or purpose, so you do not need to enter large numbers of domains individually. The tags used in rules must exist in the data file currently in use, and tags are not necessarily compatible across data sources. Domain rules also require the core to know the target domain; if an app connects directly by IP, DNS mapping or traffic sniffing may be needed.
- Routing and outbounds
- Routing sends different connections through different exits; an outbound is a specific connection exit configured in the core, such as direct, proxy, or block. A rule's
outboundTagmust refer to an existing outbound tag, not an arbitrary interface note. Global proxy generally means the routing policy favors the proxy; it does not capture traffic from apps that never enter the client.
DNS / NETWORK MODE
DNS and network modes
Where traffic enters and where domains are resolved are separate concerns that need to work together. Capturing connections does not automatically capture every DNS query.
- TUN mode
- A mode that captures traffic through a virtual network interface, which can handle apps that ignore the system proxy. It typically requires additional permissions or network components. Captured traffic still goes through routing rules, so enabling TUN does not send all traffic through a proxy outbound. When using other virtual network tools at the same time, check the default route, DNS, and local network access for side effects.
- DNS
- The system that resolves domain names into IP addresses and other records, an important step before most network connections. The operating system, browser, and proxy core may each perform their own lookups, so changing a single DNS address may not affect every app. Clarify which component sends queries, which outbound they use, and which routing rules use the results before troubleshooting caching or resolution failures.
- FakeDNS
- A mechanism that returns mapped addresses for domains and restores the domain association for later connections, making domain-based routing possible. These addresses are for internal mapping, not the target server's real address. DNS responses, traffic capture, and mapping recovery must work together; copying only the address pool settings can cause connection problems. After disabling the feature, check for DNS caches retained by apps or the operating system.
- DNS leak
- A DNS leak occurs when queries do not take the expected route; the name of a DNS service alone is not enough to confirm one. Check whether apps use their own encrypted DNS, along with the system resolver settings, IPv6, and client routing policy. A website's exit IP only reflects the route used by that request; it cannot prove that other apps or their DNS queries follow the same path.
CLIENT / SETTINGS
Client settings
Traffic capture, traffic identification, and connection optimization each serve a different purpose. Change one setting at a time and test with the same app to make it easier to identify the cause of any change.
- System proxy
- Registers a proxy address and port with the operating system, allowing apps that honor system settings to send connections to the local client. In v2rayN, “Set system proxy automatically” belongs to this layer; it is separate from routing rules on the routing page. Some apps ignore the system proxy or use their own settings. If the network stops working after closing the client, check whether the operating system still points to a local proxy port.
- Per-app proxy
- A setting that selects which apps' traffic the client captures, commonly used in Android VPN mode. In v2rayNG, first check whether the list is set to proxy only selected apps or bypass selected apps; the checked state alone does not tell you which behavior is active. Captured connections still go through routing rules and are not necessarily forced through a proxy outbound.
- Traffic sniffing
- Extracts metadata such as domain names from a connection's initial protocol data to help with routing, for example by checking the server name in a TLS handshake. It does not decrypt all traffic or identify every connection. In v2rayNG, use “Enable traffic sniffing” to support your routing needs; if identification fails, check the app protocol and whether enough information is visible.
- Mux multiplexing
- A mechanism that carries multiple logical connections over an underlying connection, potentially reducing repeated connection setup overhead in some situations. Its effect depends on protocol compatibility, packet loss, concurrent requests, and core implementation; it is not a universal speed boost. If enabling it causes stuttering or breaks connections for a particular protocol, compare with it disabled under the same conditions and check whether the current transport combination is suitable.
From terminology to configuration
Once the concepts are clear, choose a guide based on what you want to do. Start with importing a subscription if this is your first time. Before changing routing or DNS, save the current configuration and note the core and network mode in use.
- Getting Started: Import a subscription, choose a server, and verify the connection.
- Advanced configuration: Learn about routing, DNS, TUN, and custom outbounds by topic.
- Selection guide: Compare where v2rayN, v2rayNG, and v2flyNG are best suited.