Common terms explained by configuration layer, from protocols and cores to clients, subscriptions, routing, and DNS. Each entry covers its definition, where it is used, and commonly confused boundaries.
When you encounter protocol parameters, core names, or routing options, start with the relevant category. Directory links jump to each section, and every term card has a shareable page anchor.
Protocols define how clients and servers structure connection data, while security layers such as TLS and REALITY protect transport and verify identity. A node's protocol is only the first detail to check; transport, server name, and authentication parameters must also match exactly.
One of the earlier proxy protocols in the Project V ecosystem. Configurations typically include a user ID, server address, port, transport, and security parameters; client and server settings must be compatible. VMess is a protocol name, not a specific client or core version.
A streamlined proxy protocol that does not provide additional data encryption on its own and is commonly paired with TLS or REALITY. Verify the user ID, flow control, transport, and security type together; knowing only the protocol name is not enough to establish a connection.
A proxy protocol designed around TLS-style communication, typically using a password for authentication. The client must have the correct server address, port, server name, and transport security settings. Certificate status, system time, or a mismatched server name can cause the TLS handshake to fail.
A transport security solution in the Xray ecosystem, often paired with VLESS. Client settings generally include a public key, short ID, server name, fingerprint, and flow control. REALITY is not a standalone node protocol; retain its paired protocol and transport parameters when importing a configuration.
A security protocol that protects network traffic and verifies communication identity. In V2Ray configurations, the server name, certificate status, system time, and fingerprint settings all affect TLS connections. Disabling certificate verification changes the security boundary and should not be kept as a routine troubleshooting measure.
The core handles protocols, network connections, DNS, and routing; the graphical client turns these capabilities into an operable interface. When troubleshooting, first determine whether the failure is in the configuration UI, core startup, system permissions, or the remote connection.
A common umbrella term for technologies and tools in the Project V ecosystem. When discussing configurations, distinguish protocols, cores, and graphical clients because they belong to different layers. Whether a feature appears in the client UI also depends on the core and client versions.
An open-source family of cores that follows the Project V technology line and provides low-level protocol handling, transport, routing, and DNS capabilities. Graphical clients can call the V2Fly core to establish connections. V2Fly and v2flyNG have similar names, but the former refers to the core ecosystem and the latter to an Android graphical client.
An open-source family of cores with many concepts shared by the V2Ray configuration system, including VLESS and REALITY support. Xray processes actual traffic, while clients such as v2rayN and v2rayNG generate configurations and manage processes. Core support for a feature does not mean every client UI exposes the same option.
A desktop graphical client for Windows, macOS, and Linux that manages subscriptions, servers, system proxy, routing, DNS, and TUN settings. v2rayN is not a connection protocol; node import and usability depend on compatibility between the client, core, and configuration format.
A graphical client for Android that typically uses the Xray core for connections. It offers subscription imports, node selection, routing, and VPN service mode. A successful connection indicator only means the local service has started; real network requests are still needed to verify the node and DNS.
Subscriptions update configurations in bulk, a node is one specific server record, and a share URI carries a single configuration. Speed-test results reflect a particular method and moment; node selection should also consider protocol compatibility, actual connection results, and current network conditions.
A set of configuration update endpoints provided by a server. Clients use them to retrieve multiple nodes and their parameters. Updating a subscription usually refreshes the node list but cannot repair a server that has already failed. When editing groups, update intervals, or server filters, check that local selections are not being overwritten.
A server connection profile in a client, usually containing an address, port, protocol, authentication details, transport, and security parameters. The node name is only an identification label and does not prove speed or availability. Two similarly named nodes may use entirely different servers and protocol settings.
A format that encodes a single connection profile as copyable text. Each protocol uses its own URI prefix and field structure, which the client parses into a server configuration. If the URI is outside the client's supported format, check protocol support instead of repeatedly changing unrelated system proxy settings.
A client-side check that estimates how quickly a target address responds. Some methods verify only basic reachability, while others access a specified target through the proxy, so results are not directly equivalent. Lower latency usually improves interactive responsiveness but cannot fully represent sustained transfer capacity.
A latency result measured by establishing an actual proxy connection and accessing a test target. It better reflects the real connection process than a basic reachability probe. Results still depend on the target, DNS, transport protocol, and current network load, making them useful for relative comparisons during the same period.
System proxy and TUN determine how traffic enters the client; routing rules determine which outlet handles it after entering the core. GeoIP, GeoSite, and FakeDNS serve different matching purposes for IPs, domain sets, and domain mappings.
A matching rule that selects a traffic outlet based on domains, IPs, ports, protocols, processes, or other conditions. A rule usually contains match conditions and a target outbound. Order affects the result: specific conditions should generally precede a general fallback, and actual access should verify which rule matched.
A configuration method that sends different types of network requests through different outlets. Common outcomes include direct connection, proxying, and blocking, determined by routing rules and match order. Traffic splitting is not simply switching nodes; it classifies traffic item by item within one running configuration.
Geographic and network classification data organized by IP address ranges, which routing rules can reference for matching. GeoIP uses the destination IP rather than the website's domain category. Database version, core support, and rule identifiers must be compatible or rules may not load as expected.
A routing data collection organized by domain categories, used to match groups of domains with shared attributes. It handles domain rules, unlike GeoIP's address-range matching. If an app connects directly to an IP, GeoSite generally cannot match it using a domain set alone.
A operating mode that receives system traffic through a virtual network adapter and passes it to the proxy core. It can cover apps that ignore system proxy settings, but usually requires elevated system permissions. After enabling it, check for conflicts among the virtual adapter, default route, DNS takeover, and other network tools.
A DNS mechanism that returns mapped addresses to applications while retaining the relationship between the domain and address in the core. When the connection enters the core, it can restore the original domain and apply domain routing. The FakeDNS address pool must not overlap with local or other virtual network ranges.
A proxy setting supplied by the operating system to applications, usually pointing to an HTTP or SOCKS port listened to locally by the client. Only programs that honor system proxy settings use it automatically. Apps with an independent network stack may need separate proxy settings or TUN mode.
Many apparent node problems actually occur during DNS resolution, transport, or the TLS handshake. Understanding DNS, TCP, UDP, and SNI helps narrow a failure from the entire client to a specific network layer.
The basic network service that resolves domain names to IP addresses. V2Ray clients can use system DNS or define DNS servers, matching rules, and fallback policies through the core. When a webpage fails to open, determine whether the domain was not resolved, the result was unsuitable, or the target connection itself failed.
A situation where domain lookups leave through an unexpected DNS path even though network traffic follows the intended route. It is often related to the system resolver, browser-specific DNS, client core settings, or TUN coverage. Check who initiated the query, where it was sent, and which outlet handled the corresponding traffic.
A connection-oriented transport-layer protocol designed for reliable, ordered delivery. Web access and many application protocols can run over TCP. A successful TCP connection only confirms that the transport layer works; TLS, protocol authentication, and application requests may still fail separately.
A datagram-based transport-layer protocol without TCP's equivalent connection confirmation and retransmission mechanisms. DNS and real-time communications may use UDP, so clients, nodes, and routing rules must support it. Testing only TCP web access cannot fully confirm that the UDP path works.
The field in a TLS handshake that identifies the target server name, allowing services on the same address to select the appropriate configuration. The node's SNI must match the server's requirements. An incorrect value can cause a certificate-name mismatch, an aborted handshake, or an incorrect server configuration to be selected.