glossary
Look up terms by where they fit in the setup, from connection parameters to traffic routing. This glossary covers 30 common concepts, clarifying what each means, where its boundaries lie, and what it is often confused with. Protocol names alone do not tell you how well a connection will perform.
When reading a configuration, first identify the client, core, proxy protocol, transport, and security layer. Then check the subscription source, traffic entry point, and routing outbound. For hands-on steps, see the Getting Started guide; for a detailed walkthrough, consult the user guide.
protocols
Protocols define how data is encapsulated and authenticated; transport determines how it is carried; security layers protect the connection. Consider these separately.
VMess is a proxy protocol in the Project V ecosystem. It authenticates users with an ID, and modern configurations typically use AEAD. VMess can use different transport methods, so seeing VMess does not tell you whether the connection uses TCP or WebSocket. Client and server authentication settings must match. A significant system clock mismatch can also cause connection failures.
Compare VLESS encryption boundaries →VLESS handles proxy data encapsulation and authentication but does not encrypt content on its own. It is commonly used with TLS or REALITY. The user ID, transport type, security layer, and flow-control settings all affect whether a connection can be established. You cannot turn an existing node into VLESS just by changing its protocol name; the server must also be configured for it.
Explore security layer terms →Trojan is a proxy protocol typically run over a TLS connection and authenticated with a password. The server address, password, and TLS server name each serve a different purpose. Entering the right password does not guarantee that certificate verification will succeed. When a connection fails, check whether the issue is authentication, the TLS handshake, or basic network reachability.
Learn what TLS does →Shadowsocks is an encrypted proxy protocol that uses a pre-shared key. Both ends must use compatible encryption methods and keys. Requirements can vary between protocol versions and methods, so similar names do not mean they are interchangeable. After importing a configuration, keep the encryption method provided by its source rather than changing it at random while troubleshooting.
See which parameters a node contains →Here, transport means the connection method that carries proxy protocol data, such as TCP, WebSocket, or gRPC. It is not the same as the proxy protocol. The WebSocket path and Host header, as well as the gRPC service name, may need to match the server configuration. The right transport depends on how the server is set up; you cannot compare speeds in isolation.
Read the full configuration guide →cores
A setting appearing in the interface does not mean the active core can use it. To troubleshoot compatibility, check both the client and the core it actually starts.
Project V is the open-source proxy tools ecosystem built around V2Ray, encompassing protocols, configuration, and related implementations. In everyday use, “V2Ray” can refer to this ecosystem or specifically to the core program. Use context when reading a guide; the name does not always mean a particular graphical client.
Tell the ecosystem apart from the proxy core →The proxy core is the program that handles connections, protocols, DNS, and routing rules. The graphical client generates its configuration and starts it. If the core fails to start, having nodes in the interface will not provide a working local proxy. Checking the runtime logs usually reveals more than repeatedly toggling interface settings.
Learn what a graphical client does →Xray is an open-source proxy core developed from V2Ray-related code, with support for VLESS, REALITY, XTLS Vision, and related features. What is available depends on the core version, build, and configuration; the core’s name alone does not guarantee every parameter is supported. v2rayNG uses the Xray core. For desktop v2rayN, check the current node and core settings.
Understand REALITY parameters →V2Fly is a community project continuing V2Ray development, and its core is commonly called V2Fly Core. It shares an ecosystem background with Xray, but their features and configuration support are not identical. v2flyNG is an Android client that uses the V2Fly core. Check that a configuration is compatible before relying on a core-specific feature.
Explore Android client options →A graphical client provides controls for node lists, subscriptions, proxy modes, and logs, reducing the need to edit configurations by hand. This site covers desktop v2rayN and the Android clients v2rayNG and v2flyNG. The same setting may have a different name or location in each client, so follow the current interface and the core in use.
Compare clients and platforms →subscription
Subscriptions distribute configurations; nodes describe connections. A test result reflects a single probe and does not replace testing with the apps you actually use.
A subscription fetches and updates multiple node configurations from a single URL; it is not an individual node. After adding a subscription group, you usually need to update it before its nodes appear in the list. A failed update does not necessarily mean existing nodes are no longer working. Subscription URLs may contain access credentials, so treat them as sensitive and remove them from logs before sharing.
Follow the subscription import steps →A node is a set of parameters for connecting to a remote proxy server, usually including its address, port, protocol, authentication, transport, and security settings. Its display name is for identification and does not change connection settings. A successful import only means the client recognized the configuration; you still need to check server reachability, authentication, and parameter compatibility.
Understand the limits of connection tests →A share link encodes node settings as text; a QR code usually carries the same text in another format. Importing an individual share link does not create an automatically updated subscription. If the settings change, import or edit them again. Links and QR codes may contain authentication details, so hide their full contents in screenshots before posting.
Read the Android import guide →Latency is the time a probe takes to make a round trip, but different test methods measure different things. A TCP probe may only measure how long it takes to establish a connection to a port, without proxy authentication or a web request. For a fair comparison, use the same method and target under similar network conditions. Lower latency does not necessarily mean higher bandwidth.
Compare real connection latency →In a client, real connection latency usually measures a request to a test target through the proxy, making it closer to the actual connection path than a port probe alone. The target, DNS, handshake, and network conditions can all affect the result, and the timing details depend on the client. A failed test does not mean every target is unavailable; a successful one does not mean every app is using the proxy.
Check whether an app is using the proxy →routing
Routing only applies to traffic that has already entered the core. Whether a rule matches depends on its order, conditions, and the information available to the core at the time.
Routing rules select an outbound based on conditions such as domain, IP, port, or protocol. In many configurations, rules are checked in order and the first match is used. How multiple conditions combine depends on the syntax of the core in use. Put specific exceptions before broader rules, then check the logs to confirm the actual outbound after making changes.
Read the routing setup section →GeoIP is a collection of IP addresses grouped by region or category. For example, a rule can reference geoip:cn. It matches addresses, not a domain suffix or the country where its operator is registered. IP assignments and datasets change, so if a rule behaves unexpectedly, check both the resolved destination address and whether the data in use is appropriate.
GeoSite is a collection of domains grouped by category, commonly referenced in configurations with tags such as geosite:cn. It does not look up a website’s location in real time; matching uses the category data loaded by the core. Available category names and their domain lists depend on the data file in use. A correctly spelled tag still needs a matching dataset entry.
Traffic routing sends different traffic through different outbounds according to rules, for example direct, proxy, or block. “Global” and “bypass mainland China” are usually routing presets offered by a client, not proxy protocols. Global routing only affects traffic that enters the client; apps that ignore system proxy settings may still use their own network path.
Tell traffic entry and egress apart →An outbound defines how the core sends traffic. outboundTag references the tag of a configured outbound. Names such as direct and proxy are conventions; the outbound definition determines what they actually do. Referencing a missing tag or using a name from a different configuration can cause startup errors or send traffic somewhere unexpected.
proxy / tun
First check how apps send traffic to the client, then look at DNS and routing. Traffic entry settings and routing presets are separate concerns.
A system proxy is an operating-system setting for apps that support it. Only those apps send traffic to the local proxy. Browsers, command-line tools, and games may handle system proxy settings differently, so being able to open a webpage does not mean every app is connected. On Linux, check desktop network proxy settings and command-line environment variables separately.
Follow the steps to enable the proxy →SOCKS and HTTP are two types of local proxy endpoint provided by a client. Apps must use a compatible type, address, and port. 127.0.0.1 refers to the current device, not the remote node; use the port shown in the client’s settings. Whether the proxy resolves domain names depends on the protocol and app, so using SOCKS alone does not prove that DNS requests take a different route.
TUN mode captures system traffic through a virtual network interface and passes it to components associated with the client, usually covering more apps than a system proxy. It may involve permissions, system routes, DNS, and exclusion rules; it does not guarantee that every connection on the device passes through the proxy. If something breaks after enabling it, first disable other software that manages network traffic, then check the logs and route changes.
Set up and maintain TUN →FakeDNS returns a synthetic IP address for a domain query and saves the mapping to the original domain for later connection handling. The synthetic address is not the destination server’s real address; it must be used with the corresponding traffic interception and mapping restoration mechanism. If a query goes through FakeDNS but the connection bypasses that path, the app may try to connect to a synthetic address and fail.
Read the DNS configuration section →A DNS leak occurs when domain queries take an unintended route and are handled by another resolver or network egress. An app’s built-in encrypted DNS, the system resolver, and the client’s DNS settings can all be active at once. Routing webpage traffic through a proxy does not prove that DNS takes the same path. To troubleshoot, identify what initiated the query, which resolver it uses, and which outbound carries the query.
Read the DNS troubleshooting guide →security
Authentication identifies a connection; security layers protect data in transit. Match the settings to the server rather than masking configuration errors by disabling verification.
TLS encrypts connections and protects authentication and data integrity in transit. In a standard setup, a certificate verifies the server’s identity. The connection address can differ from the name used for certificate verification, but the verification name must match the certificate and server configuration. For certificate errors, check the system clock, server name, and trust chain instead of leaving certificate verification disabled.
Learn what the server name means →REALITY is a security layer provided by Xray. The client verifies the server using parameters such as a public key, without requiring the server to deploy a standard certificate for its own domain. The public key, server name, and shortId must still match the server configuration; they cannot be assembled at random. REALITY is not a proxy protocol and does not guarantee better performance than every TLS setup.
See how REALITY and VLESS differ →XTLS Vision is a flow-control mechanism in Xray for specific VLESS configurations. When conditions allow, it can reduce redundant encryption overhead for TLS traffic. A common flow-control value is xtls-rprx-vision. It is not a transport protocol or another name for REALITY. Support depends on the client, server, and transport combination.
SNI is the server name sent during a TLS handshake. The client’s serverName parameter is typically used for the handshake name and certificate verification. It is not the node’s connection address, nor is it interchangeable with the Host field in a WebSocket request. Even when connecting by IP address, you may need to specify a server name for the handshake to succeed.
A UUID can serve as the user ID for VMess or VLESS; Trojan passwords and Shadowsocks keys use other forms of authentication. The UUID’s text format says nothing about node quality, and it does not mean the value is safe to share. A complete node configuration may let others use the associated service. When asking for help publicly, hide authentication fields, subscription URLs, and QR codes while keeping non-sensitive error details.
See configuration and troubleshooting answers →