V2Ray Glossary: Protocols, Cores, and Routing

Protocols and transport

The protocol defines how communication works, the transport carries data, and the security mechanism protects the connection. These layers are not interchangeable just because they appear under one name.

VMessProxy protocol · user ID authentication: VMess is a proxy protocol in the Project V ecosystem that authenticates with a user ID. Typical configurations also include the server address, port, transport, and security settings. The client and server must use matching parameters; an address alone is not enough to connect. Authentication depends on accurate system time, so sync the device clock before assuming the configuration has expired.

VLESSLightweight proxy protocol · paired with a security layer: VLESS streamlines protocol-level processing and does not encrypt traffic by itself. It is commonly paired with a security mechanism such as TLS or REALITY. When importing a profile, preserve the original transport, server name, flow control, and user ID. VLESS and VMess are not interchangeable: changing the protocol in a dropdown does not convert a configuration.

TrojanProxy protocol · password and TLS: Trojan typically carries proxy traffic over a TLS connection and uses a password for authentication. The server name, certificate verification, and actual transport also affect connectivity. If certificate errors occur, check the domain, device clock, and server configuration; disabling certificate verification is not a suitable everyday fix.

REALITYTransport security mechanism · Xray ecosystem: REALITY is a transport security mechanism in the Xray ecosystem, not a standalone proxy protocol. It is often used with VLESS. The public key, server name, short ID, and other settings must match; available fields depend on the client and core versions. If a profile uses REALITY, make sure the selected core supports it rather than checking only whether VLESS appears in the protocol list.

Cores and ecosystem

The interface manages settings; the core handles connections. When troubleshooting compatibility, check both—not just the software name.

Project VProject ecosystem · modular proxy communications: Project V is an ecosystem built around modular proxy communications, with V2Ray as an important starting point for understanding it. In everyday usage, “V2Ray” may refer to the core or more broadly to compatible protocols and clients; check the context when following a guide. Before choosing software, distinguish the protocol, the core that runs it, and the graphical client to avoid confusing their capabilities.

V2FlyCommunity project · V2Ray core maintenance: V2Fly is a community project that maintains the V2Ray core and related components. Connection capabilities depend on the core version in use. The Android client v2flyNG is one option built around this core, but a client name is not a protocol name. When migrating a configuration, check its protocol, transport, and supported fields; do not assume every setting will work unchanged with another core.

XrayProxy core · connection and routing: Xray has technical roots in V2Ray and handles protocol negotiation, connections, and routing, with some features evolving independently. v2rayN can manage core configurations, while v2rayNG is a common graphical client for Android. If a core fails to start, check the startup log for specific field or file errors; an open interface does not mean the connection is working.

Core and clientThe execution layer and configuration interface: The client provides an interface for managing subscriptions, selecting servers, and viewing logs; the core runs network tasks in the background using the generated configuration. A setting shown in the interface is not necessarily understood by every core. Updating the client, updating the core, and refreshing a subscription are separate actions. When troubleshooting, note which one changed.

Subscriptions and nodes

Subscriptions provide configurations; nodes describe connections. Sharing or backing them up also requires considering sensitive information and what will transfer.

Subscription linkURL for fetching connection profiles: A subscription link is a URL a client uses to fetch connection profiles, and the returned content must be in a format the client can parse. The link may contain credentials, so avoid exposing it in public screenshots, logs, or discussions. If importing fails, first determine whether the URL could not be reached or its contents could not be parsed. Subscription conversion only adapts the format; it cannot fill in connection parameters missing from the source.

NodeServer entry · connection profile: A node usually means a connection profile in the client’s list, containing the server address, port, protocol, authentication, and transport security settings. Its display name is only a label and does not confirm the server’s actual location or connection quality. Selecting a node makes it the current connection candidate; whether apps use it also depends on proxy mode, routing rules, and the core running correctly.

Subscription updateRefreshes the profile list · not a software upgrade: A subscription update requests the subscription URL again and refreshes the profile list according to the client’s behavior. It does not update the client or core. Changes at the source may modify or remove existing entries, so subscription profiles are not reliable long-term backups for manual edits. After updating, confirm that the selected profile is still available before testing the connection; otherwise, a changed selection could be mistaken for a network problem.

Routing and split tunneling

Rules evaluate conditions; outbounds handle connections. Check rule order and data sources first, then inspect the final match.

Routing ruleMatch conditions → outbound label: Routing rules select an outbound based on conditions such as domain, IP, port, or process; available conditions depend on the core and client. Rules are usually evaluated from top to bottom, and the first match determines the outbound. Broad conditions can shadow more specific rules below them. When troubleshooting, check rule order, then confirm the request includes usable domain information. Leave fallback handling until last.

GeoIPIP address lists · grouped by region or purpose: GeoIP organizes IP addresses into routing lists by region or purpose. For example, geoip:private is commonly used to match private addresses. Results depend on the data source and version, so they are not definitive proof of an address’s actual location. When using IP-based rules, also consider when the domain is resolved and whether the routing policy triggers a lookup for matching.

GeoSiteDomain categories · depends on rule data: GeoSite organizes domains into categories, so rules can refer to categories such as geosite:cn instead of listing domains one by one. Which categories exist and what they contain depends on the loaded data file. If the log reports a missing category, check the data file and category name; changing rule order cannot fix a category that is not present.

Routing and outboundsRequest assignment and connection configuration: Routing sends requests down different paths; an outbound defines how the connection is actually made. Interfaces often use direct, proxy, and block to label direct connections, proxied connections, and blocked traffic. The labels alone do nothing—they must map to the right configuration. Direct connections still require network access to the destination; choosing direct does not bypass normal network conditions.

Client features

Proxy mode determines which traffic enters the client; a connection test checks only a specific target. Know what each one covers.

System proxyRegisters a local proxy address with the OS: A system proxy registers a local proxy address with the operating system. It mainly affects apps that honor the setting and does not capture every network connection. In v2rayN, “Automatically configure system proxy” and “Clear system proxy” change system settings, not remote connection parameters. If the client exits while a stale proxy address remains configured, the browser may keep sending requests to a local port that is no longer listening.

TUN modeVirtual network interface · broader traffic capture: TUN mode receives traffic through a virtual network interface and can handle some apps that do not follow the system proxy. It typically requires administrator privileges or appropriate network permissions. Actual coverage depends on system routes, exclusions, IPv6 settings, and the implementation; an enabled toggle alone does not prove all traffic is being handled. Before enabling it, check permissions and DNS settings, and watch for routing conflicts with other virtual network software.

Latency testDifferent methods produce results that are not directly comparable: Latency is the time taken by a specific test. TCP connection setup, HTTP requests, and other probes measure different steps. A reachable TCP port only confirms that the corresponding connection stage is accessible; it does not prove protocol authentication or access to the destination will succeed. Compare results using the same method and target. Lower latency does not necessarily mean faster sustained downloads.

Connectivity test latencyA request sent through the proxy configuration: In a client, a connectivity latency test typically sends a request to a test endpoint through the current proxy configuration, covering more connection steps than a simple server port probe. Whether it includes DNS, handshakes, or redirects—and how success is determined—depends on the client. A failed test may be caused by the endpoint itself or its routing and does not prove that all apps are unable to connect.

Networking basics

DNS resolution, address mapping, and local ports are separate steps. Identify where the problem occurs before changing settings.

DNSDomain name resolution · address lookup before connecting: DNS resolves domain names to records such as IP addresses. The result affects subsequent connections and routing decisions based on IP. The operating system, browser, and proxy core may each have their own DNS settings, so changing one does not necessarily change every lookup path. If a domain is unreachable, check whether it resolves, whether the returned address is reachable, and which outbound the request ultimately uses.

FakeDNSVirtual addresses and domain mapping: FakeDNS returns a virtual address from a designated pool and keeps a mapping to the original domain, allowing later processing to retain domain information. These addresses are not the destination server’s real addresses; a component that recognizes the mapping must handle the connection. After switching modes, an app may still have an old address cached and fail to connect. Check how the client handles DNS caching and traffic capture.

DNS leakQueries take an unexpected path: A DNS leak usually means domain queries did not follow the expected resolution path and were sent to another resolver by the operating system or an app. Whether this is a problem depends on the intended routing policy; local resolution for domains set to go direct is not automatically a fault. Check the browser’s secure DNS, system resolver, core DNS, and TUN settings together. A single test page can show only part of the picture.

Local listening portThe local entry point apps use to connect to the client: A local listening port is where the client accepts connections on the device; it is not the same as the remote server port. Some v2rayN configurations use 10808 for a mixed SOCKS/HTTP listener, but check the current settings for the actual value. The protocol and port configured in an app must match. If another program is using the port, the core may fail to start or listen; check the logs to find the conflict.