Quick Reference
Start with protocols and cores, then learn how subscriptions, nodes, routing, DNS, and TUN mode fit together. Each entry explains what the term means and where it appears in settings.
Find by use case
When you encounter an unfamiliar field, first decide whether it belongs to the protocol, core, node, routing, or network layer. Once it is classified, the relevant glossary entry is usually faster than guessing from the field name.
VMess, VLESS, and Trojan describe how a client communicates with a server; TLS, REALITY, and SNI are more often part of transport security and connection parameters. They commonly appear together, but they belong to different conceptual layers.
v2rayN and v2rayNG provide the graphical interface, while the Xray or V2Fly core handles protocols, DNS, and routing. When troubleshooting, check the interface settings and core status separately.
Latency, real connection latency, and node speed tests use different methods. Results vary with the local network, server load, and test target, so one reading is not enough to judge long-term performance.
Protocol
These terms determine how connection parameters fit together. After importing a node, you usually do not need to enter each field manually, but understanding them helps verify the protocol, transport security, and server name.
VMess is an early client-server communication protocol in the Project V ecosystem. A node configuration typically includes the server address, port, user identifier, transport method, and security options.
When importing a configuration, keep every field matched as provided; copying only the address and port is not enough. If the user identifier, transport path, or security settings differ, network reachability alone will not complete the protocol connection.
VLESS is a lightweight proxy protocol that does not handle additional data encryption itself. In practice, it is commonly combined with TLS, REALITY, or another transport security solution.
When reviewing a VLESS node, check the user identifier, flow control, transport type, and security-layer parameters together. Matching protocol names do not mean that fields from two node configurations are interchangeable.
Trojan is a proxy protocol that relies on TLS for secure transport. Common settings include the server domain, port, password, and server name. The password is part of the protocol identity and must match the server configuration.
When troubleshooting a connection, check the password as well as the system clock, DNS resolution, TLS settings, and SNI. Being able to reach the server port does not prove that the complete handshake succeeded.
REALITY is a transport security solution in the Xray ecosystem and commonly appears with VLESS. Client settings may include a public key, short ID, server name, and fingerprint.
These fields are determined by the server configuration and should not be changed arbitrarily after import. A mismatched public key or short ID will usually cause the connection to fail during the security handshake.
TLS is a general-purpose security protocol that protects network traffic and verifies the identity of the communicating endpoint. In V2Ray clients, TLS settings commonly appear alongside the certificate domain, SNI, system clock, and transport method.
Certificate verification depends on the correct system clock and server name. For an expired certificate, name mismatch, or handshake failure, check these basics first instead of changing the protocol type.
Core & Client
A GUI client turns subscriptions, nodes, and switches into an interface you can operate, while the core executes connections, routing, and DNS rules. Versions and configuration state on both sides can affect the final result.
V2Ray generally refers to the network proxy platform and related configuration model in the Project V ecosystem. A complete configuration may include inbounds, outbounds, routing, DNS, logging, and policies.
When using a GUI client, many modules are generated automatically by the interface. For advanced configurations, follow the modules to understand where traffic enters, how rules match, and which exit it uses.
V2Fly is a community project and family of cores that continues the Project V technology stack. It handles protocol connections, routing decisions, DNS queries, and transport processing, and serves as the runtime core for some clients.
V2Fly and a GUI client belong to different product layers. When the interface offers a core choice or core version, it refers to the program that executes the configuration, not the subscription management interface.
Xray is an open-source core closely related to the V2Ray configuration model, supporting VLESS, REALITY, routing, and DNS. Common v2rayN and v2rayNG configurations may be executed by Xray.
If the client reports that the core failed to start, check the runtime log, core files, and configuration syntax. A visible node list only means the interface read the configuration; it does not mean the core established a connection.
v2rayN is a desktop GUI client for Windows, macOS, and Linux. It provides controls for subscription updates, node selection, the system proxy, TUN mode, routing, and log viewing.
Before enabling a proxy, first import a subscription and select a working node, then enable the system proxy or TUN mode for the situation at hand. Interface options are translated into core settings, so related services may need to restart after changes.
v2rayNG is an Android GUI client that commonly runs on the Xray core. It can import nodes from a subscription or individual link and provides node switching, routing settings, and runtime logs.
The system may request permission to create a local virtual network tunnel, which is necessary for the client to receive device traffic. If a particular application does not work as expected, check its own network settings and the client’s routing mode.
Subscription & Node
A subscription handles bulk distribution and updates, while a node is one specific connection profile. Test results show the current state but cannot replace checks of subscription validity and protocol parameters.
A subscription is a configuration collection URL published by a service provider. After reading it, the client converts node names, protocol parameters, and group information into a selectable list of profiles.
Adding a subscription and updating a subscription are separate actions: adding saves the URL, while updating fetches its content again. If the list does not change after an update, check the client message first, then confirm that the URL is still valid.
A node is a server connection profile in the client, usually containing an address, port, protocol, identity details, transport method, and security parameters. The node name is only a label for identification and does not affect the connection.
After selecting a node, the client still needs to start the core and take over the relevant traffic. If the node is visible but cannot connect, check the local network, system clock, configuration parameters, and server status separately.
Latency is the time a test request takes to travel from the local device to a response, usually shown in milliseconds. The test target, network path, server load, and local Wi-Fi can all affect the result.
Latency tests may use different methods across clients, so their numbers are not directly comparable. Lower latency usually means faster responses, but it does not necessarily mean higher download speeds or a consistently stable connection.
Real connection latency is the response time measured by establishing an actual proxy connection and accessing a test target. It includes the protocol handshake and proxy outbound, making it closer to the real connection process than a reachability check.
A failed test can be caused by node parameters, DNS, the target site, or the local network. Before running repeated tests, check the log so a protocol error is not mistaken for ordinary network fluctuation.
Node speed testing broadly means comparing current node performance with latency, real-connection, or transfer tests. Each test measures different factors: quick tests help with initial screening, while real-world experience also depends on sustained connections and the target service.
Batch tests create many network requests at once, and results can also be affected by test order. A more reliable approach is to shortlist a few candidates and verify each connection separately.
Routing
The routing module does not create connection nodes; it only decides which outbound should handle requests that have entered the core. Read the rule order, matching targets, and final outbound together.
A routing rule selects an outbound based on conditions such as a domain, IP, port, network type, or protocol. When rules are matched from top to bottom, more specific conditions generally belong in the appropriate higher-priority position.
At minimum, read both the matching conditions and the target outbound in a rule. Looking only at a domain list while ignoring the outbound label can make it unclear whether the rule proxies, connects directly, or blocks.
Traffic splitting sends different types of network requests through a proxy, direct connection, or blocking outbound. It relies on routing rules to identify the target and pass the request to the appropriate exit.
Traffic splitting is not simply a speed switch. Rules that cover too much may reroute requests unnecessarily, while rules that cover too little may miss a particular domain or application connection.
GeoIP is a data collection that classifies IP addresses by region or purpose. Routing rules can use its category names to match destination IPs in bulk. It works with resolved network addresses, not the language or name shown on a webpage.
GeoIP data needs updating as network allocations change. If a rule does not match, also check whether the request has been resolved to an IP and whether the current routing policy prioritizes domain or IP conditions.
GeoSite is a collection of domain rules organized by purpose or category, commonly used to match related domains in bulk. It reduces the work of maintaining domains individually, but category boundaries still depend on the rule data.
A service may use its main domain, API domains, and content delivery domains at the same time. Matching only some of them can send page and resource requests through different outbounds, so use logs to see which rules actually matched.
Domain matching determines where a request goes using a full domain, subdomain, keyword, regular expression, or rule set. Each method has a different scope: full-domain matching is usually the most precise, while keyword matching is broader.
When writing routing rules, prefer conditions that are specific enough. An overly broad keyword can match unrelated domains and send otherwise separate requests through the same outbound.
Transport & Network
These terms describe how the system hands traffic to the client. The system proxy and TUN mode cover different scopes, while DNS, FakeDNS, and SNI affect domain resolution and the connection handshake.
TUN mode receives system traffic through a virtual network interface, then lets the proxy core handle DNS, routing, and outbound processing. It can cover some applications that ignore system proxy settings and handle more types of connections.
Enabling it usually requires network-related system permission and may conflict with other virtual network tools over interfaces or routes. If the network goes down, exit TUN mode first and check whether the system routes have recovered.
FakeDNS first returns a temporary mapped address to the application, then the core restores the original domain when it receives the connection. This lets later routing continue to use domain conditions instead of being reduced to an IP too early.
A temporary address is meaningful only within its associated mapping environment; it is not the target service’s real address. If the mapping state is lost or traffic bypasses the core, the domain may not be restored as expected.
A DNS leak occurs when an application’s domain lookup bypasses the intended DNS path and is handled by another resolver. Common causes include an application choosing its own resolution method, multiple system network interfaces, or requests that never enter the proxy core.
First identify which program is actually making the query, then check the client DNS settings, system network configuration, and routing mode. Changing one DNS address alone may not change every application’s lookup path.
The system proxy is the proxy address and port exposed by the operating system for applications to read. Browsers and some desktop programs follow it, but applications that manage their own network connections may ignore it.
Turning on the system proxy does not mean all device traffic automatically enters the client. To cover programs that ignore system proxy settings, consider whether TUN mode is appropriate.
An inbound is the entry point where the proxy core receives connections. Common settings include a listen address, port, and access protocol. The system proxy typically sends application requests to a local HTTP or SOCKS inbound.
A listener bound to a local address is usually available only to the current device. If LAN connections are allowed, also consider the listen scope and system firewall. The core may fail to start if another program already occupies the inbound port.
An outbound is the exit used after the proxy core processes traffic. It can connect to a proxy server, access the target directly, or block the request. Each outbound usually has a separate tag referenced by routing rules.
A node configuration generally creates a proxy outbound, while the client also prepares direct and blocking outbounds. Compare the outbound tags in the routing rules with their definitions to understand where traffic ultimately goes.
DNS is the system that resolves domain names into network addresses. A client can configure DNS servers, domain matching rules, query types, and the outbound used for requests to work with routing.
Connection problems are not always caused by the node; failed domain resolution can also stop a request. During troubleshooting, distinguish between receiving no resolution result and receiving an address but timing out later.
SNI is the information in a TLS handshake that specifies the target server name. When one server address hosts multiple domain services, the server uses this name to select the appropriate certificate and connection settings.
The SNI in node parameters does not always exactly match the server address text, but it must comply with the server configuration. Clearing or replacing it arbitrarily can cause a certificate name mismatch or handshake failure.
Continue with Configuration
For a first configuration, start by importing a subscription, choosing a node, and selecting a proxy mode. When reading full JSON, break it down in order through inbounds, outbounds, routing, and DNS. For connection problems, check the runtime log to determine whether the issue is resolution, handshake, timeout, or an unmatched route, then return to the relevant glossary entry.