V2Ray Glossary: Subscriptions, Protocols, DNS & TUN Mode

Protocols and transport

A protocol defines how a connection exchanges data; a transport defines how that data is carried; a security layer protects the connection. Configure each layer separately and make sure they work together.

Protocols and transportVMess: A proxy protocol in the Project V ecosystem that defines authentication and data exchange. It can use different transports, so two VMess connections may require different paths, hostnames or TLS settings. Client and server parameters must match; an address and port alone are not enough to confirm a complete configuration. If authentication fails, check that the device clock is accurate.

Protocols and transportVLESS: A lightweight proxy protocol without a complete built-in encryption layer, usually paired with security mechanisms such as TLS or REALITY. The same protocol name does not make configurations interchangeable: the transport, server name and applicable flow settings can all affect the connection. When importing a share link, keep the security fields provided by its source rather than copying settings from another connection.

Protocols and transportTrojan: A proxy protocol that typically protects traffic with TLS and authenticates users with a password. The password and server address are separate fields, and the server name may also be required for certificate validation. Compatibility depends on the transport combination supported by the selected core. If the connection fails, check the original settings before considering any change to certificate verification.

Protocols and transportREALITY: A transport security mechanism in the Xray ecosystem, commonly used in VLESS configurations but not a subscription format on its own. It requires matching parameters such as the public key, server name and short ID, and a core that supports REALITY. The public key is used for verification, not as a login password. Seeing a REALITY option in the client does not by itself confirm that a connection will work.

Protocols and transportTransport: Describes how proxy traffic is carried and sent, such as over TCP, WebSocket or gRPC. Transport is a different layer from proxy protocols such as VMess and VLESS, and from security mechanisms such as TLS. WebSocket paths, gRPC service names and other fields must match the server configuration; switching transports on one side usually breaks the existing connection.

Cores and clients

The client provides the interface; the core handles networking. When choosing a client, check which core capabilities your connection configuration requires.

Cores and clientsProject V: An open-source networking project and technical ecosystem built around V2Ray, not a connection configuration you can import directly. In related documentation, distinguish among the core, graphical client and server: the core handles networking, the client provides the interface, and the server accepts connections using the corresponding protocols. Similar ecosystem names do not mean every component supports the same features.

Cores and clientsV2Fly: A community-maintained V2Ray project whose core handles protocol processing, routing and network connections. The Android client v2flyNG provides a graphical interface built around the V2Fly core. To check whether a configuration will work, look at the fields and version requirements supported by the actual core rather than copying settings from a different one.

Cores and clientsXray: An independent core developed from V2Ray-related code, with features such as REALITY and its own evolving configuration capabilities. v2rayNG uses the Xray core, but the client interface version and core version are separate details. Choose based on the features your subscription requires. For a detailed comparison, see Xray vs. V2Fly core comparison.

Cores and clientsGraphical client: A visual app for managing subscriptions, selecting connections, editing routing and starting a core, such as v2rayN, v2rayNG or v2flyNG. A client name is not a protocol name, and installing a client does not provide a working connection configuration. Desktop interface updates and core updates can affect different features, so record both versions when troubleshooting.

Subscriptions and nodes

A subscription is a source of configurations, a node is a selectable connection, and a group is a way to organize them. A successful update does not mean a connection works.

Subscriptions and nodesSubscription link: A URL used to fetch and update a set of connection configurations, not a proxy address to enter in the server field. The client fetches the subscription and parses its response into a list of connections; an error page, login page or unsupported format may prevent import. Links often contain credentials, so redact sensitive parts from screenshots, logs and support requests. See the subscription import guide for the steps.

Subscriptions and nodesNode: A connection configuration in a client's list, usually containing a server address, port, proxy protocol and authentication details, and sometimes transport and security settings. A label is for organization and does not determine connection performance. Importing a node only confirms that the configuration was recognized; test the connection and try accessing a destination to confirm it works.

Subscriptions and nodesSubscription group: A way for clients to organize subscriptions from different sources, with separate settings for labels, URLs, enabled status and updates. Updating a group can add, remove or replace its connections, and may overwrite manual edits. Group names are for organization only; setting a subscription as active does not mean every app's traffic will enter the proxy as expected.

Routing and traffic splitting

First confirm that traffic reaches the client, then check the matching conditions and outbound route. Routing rules cannot handle connections that have not been intercepted.

Routing and traffic splittingRouting rules: A set of settings that selects a route for each connection based on its domain, destination IP, port or other conditions. Rule order matters: a broad rule near the top may match first and prevent a more specific rule below it from taking effect. Also check the default route for unmatched traffic and whether the core can access the domain or address information required by the rules.

Routing and traffic splittingTraffic splitting: Directing different connections to a direct, proxy or block route according to defined conditions. It does not simply send all traffic to one server; the traffic entry point, rules and outbound routes must work together. If an app ignores the system proxy, its connections may never reach the client, so changing domain rules may not solve the problem.

Routing and traffic splittingGeoIP: IP address data used by routing rules to organize matching conditions by address range or label. Results depend on the data source, file contents and update status; they do not directly indicate a server's physical location or speed. A domain can resolve to different addresses, so routing for the same website may change with its DNS results.

Routing and traffic splittingGeoSite: Domain data used by routing or DNS rules, usually organized into collections by service or purpose. Labels are not website addresses, and available labels can vary by data source and version. When a rule uses GeoSite, the core needs to identify the domain; a connection with only a destination IP may not match the expected domain category.

Routing and traffic splittingDirect and proxy routes: A direct route connects to the destination over the current network; a proxy route forwards traffic through a configured proxy server. These describe the final network path and are not the same as whether the system proxy is enabled in the interface. To confirm the actual route, check the routing mode, matched rules and core logs—not just the selected node's label.

DNS and networking

Check DNS resolution, connection routing and test results separately. After changing DNS, account for caches and apps' own network settings.

DNS and networkingDNS: A system that resolves domain names to IP addresses and other records, often as a prerequisite to establishing a connection. Resolution may be handled by the app, operating system, client core or a remote service, so setting one DNS address may not cover every request. If a website will not load, first distinguish a resolution failure from a connection failure, then check the DNS settings against the actual request path.

DNS and networkingRemote DNS and direct DNS: These terms usually distinguish between the resolver used and the network path taken by DNS requests, but their exact meaning can vary across configuration interfaces. Entering a remote resolver address does not automatically send requests through the proxy; the resolver connection also needs the right route. Specify which resolvers handle which domains and which outbound route the resolver itself uses.

DNS and networkingFakeDNS: A mechanism that assigns synthetic addresses to domains and maintains a mapping between each domain and its address. The core can use this mapping to identify the original destination in subsequent connections. A synthetic address is not the website's real server address, so FakeDNS must work with traffic interception and routing for the relevant address pool. After disabling it, the system or app may still have old results cached, so check for cache effects when switching configurations.

DNS and networkingDNS leak: A DNS leak occurs when DNS requests take a different path from the one intended—for example, when they are handed to another resolver instead of using the specified outbound route. A resolver name in a test result is a clue for troubleshooting, not proof of the path taken by every request. Check encrypted DNS settings in apps, system resolution, routing and caches. See the DNS leak troubleshooting guide for details.

DNS and networkingLatency and real connection latency: Latency is the time taken by a specific test. TCP connection setup, request-response time and accessing a destination through a proxy measure different things. Real connection latency usually measures a request to a specified test destination through the current proxy; the timing details depend on the client. The test target, DNS resolution and network conditions all affect results, so compare under the same conditions. Low latency does not necessarily mean high download speeds.

System proxy and TUN

These terms describe how traffic reaches the client. Once traffic is intercepted, routing rules still determine which connections go direct and which use the proxy.

System proxy and TUNSystem proxy: A proxy address setting provided by the operating system, typically used by apps that honor it to send requests to the client's local endpoint. It does not guarantee that every app will use the proxy or that DNS requests will take the same path. If web pages stop loading after the client exits, check whether the system still points to a proxy port that is no longer listening.

System proxy and TUNTUN mode: A mode that captures traffic through a virtual network interface and system routes, including traffic from some apps that ignore the system proxy. It usually requires the appropriate permissions and must work with DNS, routing and virtual network adapter settings; enabling it does not mean every connection will use the proxy route. If the network stops working or TUN fails to start, disable TUN to restore basic connectivity, then check the TUN setup guide step by step.

System proxy and TUNLocal HTTP and SOCKS proxy: A local proxy endpoint provided by the client for other apps to connect to over HTTP or SOCKS. The protocol, address and port configured in each app must match an actual listening endpoint; do not enter a subscription URL here. Some clients use a mixed port that accepts multiple protocols. Before allowing LAN access, check the listening address and access controls.

System proxy and TUNBypass the LAN: A routing policy that sends local network addresses direct by default, typically to preserve access to routers, shared devices and LAN services. It does not disable the proxy; connections to other destinations can still follow the rules. Some device discovery relies on multicast, broadcast or a specific interface. If a local service remains unavailable, check TUN routes, firewall rules and the network interface used by the app.