Protocols and Encryption
Connection Formats and Security Layers
The protocol defines how identity information and data are structured, while security layers such as TLS and REALITY protect the connection at different stages. When importing a node, the protocol is only the starting point; the transport method and security parameters must also match.
- VMess Protocol
- VMess is an application-layer protocol in the Project V ecosystem, covering authentication, time validation and data transport. Clients usually require a user ID, server address, port and additional identifier. If the server clock differs too much from the local system time, authentication may fail, so check the system clock when troubleshooting connection issues.
- VLESS Protocol
- VLESS is a streamlined proxy protocol that delegates encryption and transport security to outer layers such as TLS and REALITY. Connectivity depends not only on the VLESS name but also on whether the transport layer, security layer and server configuration match. Common key fields include the user ID, flow control, server name and public key.
- Trojan Protocol
- Trojan uses a password for authentication and commonly establishes connections over TLS. Client settings must match the server address, port, password, server name and transport method. If the certificate name does not match or the handshake fails, first verify the server name instead of repeatedly switching nodes.
- REALITY Security Layer
- REALITY is a transport security solution in the Xray ecosystem, commonly used with VLESS. Client configuration usually includes the server name, public key, short ID and browser fingerprint. A missing or incomplete critical field can leave the connection stuck during the handshake; consult core logs to identify the exact parameter.
- TLS Transport Security
- TLS is a general-purpose security protocol for establishing encrypted connections and verifying the identity of the communicating endpoint. Client settings commonly include the server name, certificate verification, application-layer protocol negotiation and transport port. Certificate errors require distinguishing an incorrect system clock, a mismatched server name and a certificate-chain problem, as each calls for a different fix.
Cores and Ecosystem
Client, Core and Project Relationships
The graphical client manages the interface, subscriptions and settings; the core handles protocols, DNS, routing and the actual connection. Keeping these roles separate helps identify whether a problem lies in the interface configuration, core startup or remote connection stage.
- Project V Technology Ecosystem
- Project V is an open-source technology ecosystem built around network proxy protocols, routing capabilities and related tools. V2Ray's configuration concepts, inbound and outbound model, and many client tools are connected to this system. It is not the name of a single graphical interface; documentation should distinguish the project, core and client names.
- V2Fly Core Branch
- V2Fly is a community-maintained project and core branch that continues the V2Ray technical lineage. It provides protocol handling, inbound and outbound connections, DNS and routing, while a graphical client can generate its configuration and start it. With v2flyNG, settings in the interface are ultimately converted into a configuration the core can read.
- Xray Proxy Core
- Xray is a proxy core built around configuration concepts similar to V2Ray, with support for VLESS, REALITY and other capabilities. v2rayN and v2rayNG can invoke it to handle connections under the appropriate configuration. If the interface shows a node but the connection fails, check whether the core started correctly and whether its logs contain configuration parsing or handshake errors.
- v2rayN Desktop Client
- v2rayN is a graphical desktop client for Windows, macOS and Linux. It manages subscriptions, nodes, the system proxy, TUN mode, routing rules and core processes. The desktop edition uses a different interface implementation from the classic Windows WPF edition, but both follow the same workflow: import a configuration, select a node, start the core and choose how traffic is captured.
- v2rayNG Android Client
- v2rayNG is a graphical client for Android that typically uses the Xray core to handle connections. It captures application traffic through the system-provided VPN service and offers subscription management, node switching and routing settings. On the first connection attempt, grant the network connection permission requested by the system; otherwise interface actions will not create a working data channel.
Client Features
Traffic Capture and Connection Tests
The system proxy and TUN mode capture traffic at different scopes, while FakeDNS, LAN sharing and latency tests serve specific scenarios. The more features are enabled, the more important it is to verify that ports, permissions and routes do not conflict.
- System Proxy Traffic Capture Mode
- The system proxy is a client-managed operating system setting that sends traffic from applications that follow it to a local proxy port. Browsers usually read this setting, but some terminal programs, standalone networking tools and applications with their own network stacks do not. If the browser works but a terminal does not, check the system proxy and terminal environment variables separately.
- TUN Mode Virtual Network Interface
- TUN mode captures more application traffic through a virtual network interface and usually covers more than the system proxy. It requires the relevant network permissions and adds routes to the system routing table. Running another virtual networking tool at the same time can cause route contention, DNS path changes or repeated connection switching; keep one clear traffic-capture entry point.
- FakeDNS DNS Mapping
- FakeDNS returns mapped addresses to applications and stores the mapping between those addresses and the original domains inside the client. It is commonly used with TUN mode so traffic entering the core can still match domain rules instead of retaining only the destination IP. Ensure the FakeDNS address range does not overlap with existing LAN subnets, and route related DNS requests through the intended processing chain.
- Real Connection Latency Connection Test
- Real connection latency measures node response time by establishing an actual protocol connection, making it closer to the client's real operating process than a simple server reachability test. It still represents only one moment, target and probe method. Lower latency does not guarantee higher throughput; consider sustained connection performance and the intended use case when choosing a node.
Subscriptions and Nodes
Configuration Sources and Node Management
A subscription supplies node configurations, while a node is an individual record the client can select and connect to. Updates, grouping and latency tests are management actions; they do not replace checks of configuration completeness and connection logs.
- Subscription Configuration Collection
- A subscription is a URL or data collection provided by a server that contains a set of node configurations. After saving the URL, the client can request and parse its nodes as needed. Copy the full URL; local edits to subscribed nodes may be overwritten during the next update, so long-term adjustments are better handled in client routing or group settings.
- Node Connection Profile
- A node is a selectable server connection profile in the client. It typically combines an address, port, protocol, authentication details, transport layer and security layer. The node name is only an identifying label, so renaming it usually does not change connection parameters; missing a user ID, public key or server name can directly prevent a connection.
- Latency Response Time
- Latency is the time from the client's probe to the received response, usually measured in milliseconds. Different tests may use TCP connection establishment, a protocol handshake or access to a specified target, so their results should not be compared directly. Latency reflects response speed only; it does not by itself represent available bandwidth, sustained throughput or long-term stability.
- Subscription Group Source Management
- A subscription group is a way for the client to organize nodes by subscription source. It makes it easier to update, filter, enable or manage nodes from a particular source, and reduces the effort of identifying nodes from multiple sources. Before deleting a group, confirm the scope because the client may also remove nodes already imported under it.
- Subscription Update Sync Operation
- A subscription update requests the subscription URL again and synchronizes the node list. If it fails, check that the URL is complete, the current network can reach it, the system time is accurate and the request status in the logs is normal. If the update succeeds but the list is unchanged, the subscription content may be unchanged, or the current group filter may be hiding some nodes.
Routing and Traffic Splitting
Matching Conditions and Traffic Routes
The routing module reads information such as the domain, IP, port or process, then selects an outbound route according to rule order. The layer where DNS resolution occurs directly affects whether domain and IP rules receive the expected input.
- Routing Rule Matching Condition
- A routing rule selects a traffic route based on the domain, IP, port, protocol or process. Rules are normally matched in order, and matching stops once a condition is hit, so specific and broad rules must be positioned carefully. If a rule appears ineffective, first confirm which routing configuration is active, then check whether the target reaches the core as the expected domain or IP.
- Traffic Splitting Outbound Selection
- Traffic splitting sends traffic for different targets or applications through routes such as proxy, direct connection or block. It is not a single switch; it results from routing rules, DNS resolution, inbound information and the default outbound route working together. Existing long-lived connections may continue using the old path after a rule change, so restart the relevant application or client connection when verifying the result.
- GeoIP IP Rule Set
- GeoIP is a data set that matches IP addresses by region or category. It can participate only when the target has been resolved to an IP or the routing module obtains the target IP directly. GeoIP data becomes outdated as address ownership changes, so stale data can produce unexpected classifications; check the rule-data version when updating the client.
- GeoSite Domain Rule Set
- GeoSite is a rule data set organized by domain category for routing modules to match against target domains. It differs from GeoIP in what it evaluates: GeoSite targets domains, while GeoIP targets IP addresses. If a request reaches the core with only an IP, GeoSite may not match; check the DNS policy, sniffing settings and TUN traffic handling.
- DNS Leak Unexpected Resolution Path
- A DNS leak occurs when an application's domain lookup bypasses the intended DNS path and is handled directly by the system or another resolver. Check the client DNS, system DNS, browser secure DNS, TUN routing and the application's own resolution policy together. Changing one DNS address may not alter every application's lookup path; first determine who makes the query, who captures it and where it ultimately goes.
- Direct Connection Outbound Method
- A direct connection sends traffic to the target without using a proxy node, through the current network connection. Routing rules usually select it explicitly, though it may be the default route for unmatched traffic. A failed direct connection is not necessarily related to proxy nodes; check the local network, DNS resolution, target address and firewall settings separately.