REFERENCE / GLOSSARY

V2Ray glossary of protocols, cores, and configuration

A configuration-focused guide to common concepts covering protocol fields, core relationships, client modes, subscription nodes, traffic routing, and DNS. Each entry explains the problem it addresses, how it differs from related concepts, and the boundaries to watch during configuration.

READING PATH

From connection configuration to traffic egress

A complete connection usually starts with the client interface generating a configuration, which V2Fly or Xray then executes. The core receives traffic through an inbound, uses DNS and routing rules to select an outbound, and sends it onward. A subscription delivers node records in bulk, while protocols such as VMess, VLESS, and Trojan describe their authentication and transport parameters. Understanding these layers makes it easier to identify whether a problem lies with the subscription, node, core, resolution, or routing.

PROTOCOL / TRANSPORT

Protocols and Transports

The protocol handles authentication and data exchange, while the transport security layer controls the connection's appearance, encryption negotiation, or underlying carrier. A protocol name usually cannot replace a complete configuration.

VMess: A protocol used to exchange data between clients and servers in the Project V ecosystem. Node configurations typically include the server address, port, user ID, transport, and security settings. After importing one, verify that the client time, user ID, and server parameters match; copying only the address and port does not create a usable configuration.

VLESS: A protocol with lightweight authentication, commonly combined with TLS, REALITY, TCP, WebSocket, or gRPC transports. VLESS describes only part of the connection stack. Whether fields such as the server name, public key, short ID, and path are required depends on the server's security layer and transport.

Trojan: A password-authenticated protocol typically used with TLS. The client must match the server address, port, password, server name, and transport parameters. If the certificate name does not match the connection target, the connection may end during security negotiation instead of reaching proxy forwarding.

REALITY: A transport security solution in the Xray ecosystem, commonly used with VLESS and REALITY. Pay attention to the server name, public key, short ID, client fingerprint, and flow-control fields, which must correspond to the server. It is a connection security layer, not a standalone subscription format or client name.

CORE / ECOSYSTEM

Cores and Ecosystem

The graphical client manages user-facing controls, while the core reads the configuration and processes network traffic. Distinguishing the project ecosystem, core family, and specific client helps identify which layer provides a feature.

Project V: An open-source technology ecosystem built around proxy cores, protocols, and configuration systems. It is not the name of a single desktop button or installer; different communities and projects have continued maintaining the related technology. When reading documentation, check the specific core and client versions to determine whether a field is supported.

V2Fly: An open-source community ecosystem maintaining v2ray-core and related specifications, components, and documentation. The V2Fly core can be called by graphical clients to execute inbound, outbound, DNS, transport, and routing configuration. The features shown in a client interface still depend on which core options the client exposes.

Xray: A family of cores related to the Project V technology stack, supporting configurations for VMess, VLESS, Trojan, REALITY, and more. Clients such as v2rayNG can use Xray to handle actual connections. Successful node import only means the configuration was recognized; it does not mean every parameter has been validated by the core.

v2ray-core: The core program maintained by V2Fly. It reads structured configuration and handles inbound, outbound, DNS, transport, and routing. It typically runs in the graphical client's background while the user manages subscription updates and mode changes through the client. Configuration parsing, listening-port, and routing errors in the logs usually originate in this execution layer.

CLIENT / PLATFORM

Clients and Platforms

Clients organize subscriptions, nodes, cores, and system network settings into an interface people can operate. System proxy and TUN are two different ways to bring traffic into the client.

v2rayN: A desktop graphical client for Windows, macOS, and Linux that provides subscription management, node selection, system proxy, TUN, and routing configuration. v2rayN handles the interface and configuration orchestration; the core running alongside it processes network traffic. Permission and proxy-setting locations vary across desktop systems.

v2rayNG: A graphical client for Android that typically uses the Xray core to handle connections. It can import subscriptions or single-node share links and route selected traffic through the system VPN service. Background execution policies, battery restrictions, and VPN permissions can affect connection persistence.

v2flyNG: An Android client built around the V2Fly core, suitable when the V2Fly core family is required. Its subscription import and node management approach resembles common V2Ray clients, but supported protocol fields depend on the current client and core versions and cannot be inferred from the share-link prefix alone.

System proxy: A client mode that points the operating system's proxy settings to a local HTTP or SOCKS listening port. Only applications that read and follow system proxy settings use this entry point; apps with their own proxy configuration or direct connections may be unaffected. Before closing the client, restore the system proxy state in most cases.

TUN mode: A mode that receives system network traffic through a virtual network interface and usually covers more traffic than the system proxy. TUN requires the appropriate system permissions and relies on the routing table, DNS, and exclusion rules working together. For local-network access problems, check bypass addresses and interface routes rather than simply switching nodes.

SUBSCRIPTION / NODE

Subscriptions and Nodes

A subscription delivers a collection of configurations, while a node is one connection record within it. A latency test reflects the time measured by a particular test method and does not equal overall usability.

Subscription: A collection of node configurations provided by a server and periodically read by the client. Updating a subscription fetches remote content again and refreshes the associated group, but does not necessarily switch the current node. If the list does not change, check the subscription URL, group selection, update result, and client logs.

Node: A set of connectable server configuration records in a client. Complete data includes the protocol, address, port, authentication details, and transport parameters. The node name is only an identification label and is not used for most connection authentication. Two records with the same name may still point to entirely different servers or use different protocols.

Latency: The time required to complete a specified probe from the local device to a test target, usually measured in milliseconds. Clients may test with a TCP handshake, HTTP request, or another method, so results from different pages are not directly comparable. A lower number does not necessarily mean better bandwidth, stability, or reachability.

Real connection latency: The time measured after the client establishes an actual proxy connection using the node configuration and reaches the test target through it. This covers the protocol handshake and proxy forwarding, making it closer to real-world use than a simple server-port probe. If the test fails, check the logs to determine whether the issue involves the node, DNS, or test target.

ROUTING / RULES

Routing and Traffic Splitting

The routing module uses connection attributes to decide which outbound receives the traffic. Rule order, DNS results, and data-file versions all affect the match.

Routing rules: Configuration that selects an outbound based on conditions such as domain, IP, port, network type, protocol, or process. When multiple rules exist, the core generally evaluates them in a defined order and priority. Record the original mode before changing it so you can restore it if the result is unexpected.

Traffic splitting: The process of assigning traffic for different targets to outbounds such as direct connection, proxy, or block. Traffic splitting is not a standalone protocol; it results from DNS, domain rules, IP rules, and outbound configuration working together. If the same domain resolves to different addresses, the rule ultimately matched may also change.

GeoIP: A data set organized by IP address ranges for use by routing rules. It matches the connection target IP or a resolved IP, not domain categories. Its scope changes with each version, so the same rule name does not mean its contents are permanently fixed.

GeoSite: A collection of domain rules organized by purpose or category that the routing module can load by category name. Its main difference from GeoIP is that it matches domains. Confirm that the core can find the corresponding data file and understand the precedence of the client's preset rules.

NETWORK / DNS

Networking Basics

DNS determines how a domain obtains its target address, while inbound and outbound determine how traffic enters and leaves the core. Most connection problems can be isolated step by step along this processing chain.

DNS: The basic network service that translates domain names into IP addresses. A V2Ray client can use system DNS, a specified remote DNS server, or different resolvers selected by domain rules. If the resolution path does not align with the routing target, a domain rule may match while the actual connection takes an unexpected route.

FakeDNS: A resolution mechanism that returns reserved addresses to applications while storing mappings between domains and those addresses in the core. It is often used with TUN so the core can recover the original domain after an application starts a connection and apply routing. The address pool must not conflict with the local network or other virtual interfaces.

DNS leak: A situation where an application's DNS queries bypass the expected resolution path and are handled by another resolver. Troubleshooting requires checking system DNS, client DNS, the browser's built-in resolver, TUN settings, and routing rules. Changing a single DNS address may not cover every application's query path.

Inbound: The entry configuration through which the core receives traffic from local applications. Common forms include SOCKS, local HTTP listening ports, and a TUN virtual interface. Inbound settings determine the listening address, port, and access protocol. If another program occupies the port, the client may fail to start the core or receive application traffic.

Outbound: The direction in which the core sends traffic after processing it, such as through a proxy node, a direct connection, or a block action. The final action of a routing rule usually points to an outbound tag. The protocol and transport parameters in the outbound configuration must be complete; otherwise, connections can fail during sending even when inbound is working normally.