Configuration reference · 25 terms

V2Ray Glossary

Browse protocols, cores, subscriptions, routing, and DNS by configuration layer.

Identify which layer a term refers to before changing its settings. Protocols define connection conventions, cores handle network processing, and clients provide the interface; they are not interchangeable. Each term heading has a direct link you can save or share.

Protocols & transport

A protocol can use different transport methods. After importing a configuration, check compatibility against the full set of parameters, not just the protocol name.

Protocols & transport

VMess

A proxy protocol in the Project V ecosystem that uses a user ID for authentication, commonly found in existing configurations and subscriptions. The connection must also match the server address, port, transport, and security settings; a user ID alone is not enough. If authentication fails, check the imported configuration and make sure the device clock is accurate, as clock drift can affect authentication.

Protocols & transport

VLESS

A lightweight proxy protocol that authenticates with a user ID but does not encrypt traffic itself. In practice, it is usually paired with security settings such as TLS or REALITY; the protocol name alone does not mean the traffic is encrypted. When editing a server entry, use the server-provided transport, security, and flow control parameters rather than guessing from another configuration.

Protocols & transport

Trojan

A proxy protocol commonly used with TLS that authenticates with a password. The client needs the server address, port, password, and TLS settings; the domain and certificate settings can also affect the connection. If a handshake fails, distinguish an authentication error from a certificate verification error. Disabling certificate verification is not a routine fix.

Protocols & transport

REALITY

A transport security method in the Xray ecosystem, not a standalone proxy protocol alongside VLESS. Configuration typically requires server-provided details such as the public key, server name, and short ID, and these fields must match. Seeing an option in the interface does not mean the current core supports every combination; check both the core version and server requirements.

Protocols & transport

Transport settings

Settings that define how a proxy connection carries data, commonly TCP, WebSocket, or gRPC. Transport is separate from proxy protocols such as VMess and VLESS, and it does not replace TLS settings. Additional fields such as the WebSocket path or gRPC service name must match the server; changing only the dropdown while leaving outdated parameters can break the connection.

Cores & clients

Clients import and edit configurations; cores handle connections and apply rules. When troubleshooting compatibility, note the details of both.

Cores & clients

Project V

A project and technology ecosystem built around modular network proxies, with V2Ray as a key part of it. In documentation, the name usually describes the project’s background and architecture, not a switch in a particular client. Implementations in the ecosystem may share concepts, but their features, fields, and defaults still need to be checked individually; configurations are not necessarily interchangeable.

Cores & clients

V2Fly

A community project that maintains V2Ray-related code and documentation and provides a proxy core implementation. It is not on the same layer as a graphical client: the client can generate a configuration for the core to run. Before following instructions written for another core, check which fields are supported, especially proprietary transport security options.

Cores & clients

Xray

A proxy core developed from the V2Ray technology stack that handles protocols, routing, DNS, and other network tasks. It is not a subscription source and does not provide remote servers to connect to. Feature support depends on the core implementation and version, as well as whether the client generates the right parameters. After updating the interface, check which core is actually running.

Cores & clients

v2rayN

A desktop graphical client with controls for subscription groups, server selection, routing, and system proxy settings. The client and proxy core do different jobs, so the client version number does not tell you the core version. When troubleshooting, check the runtime logs and active core first, then confirm whether the operating system proxy or TUN settings are working.

Cores & clients

v2rayNG

An Android graphical client that receives device traffic through the system VPN interface and processes it with the core according to its configuration. System authorization on first connection only allows a local traffic tunnel; it does not mean the remote connection succeeded. If per-app proxying is enabled, check the app list and its include or exclude behavior before assuming a server is at fault.

Subscriptions & servers

Retrieving configurations, selecting a server, and testing a connection are three separate actions. A successful subscription update does not mean every server in the list works.

Subscriptions & servers

Subscription

A way for a client to retrieve server configurations in bulk from a single URL. The response must use a format the client can read. Updating a subscription reloads configurations; it does not renew a service or fix remote connections. Subscription URLs may contain credentials, so redact sensitive parts before sharing the full URL in screenshots, logs, or support requests.

Subscriptions & servers

Server

A common name for a set of remote server connection parameters; some client interfaces call it a “server.” An entry typically includes an address, port, protocol, authentication, and transport settings—not just an IP address. Its display name is only a label and cannot confirm its location, bandwidth, or availability; check test results and service details instead.

Subscriptions & servers

Subscription group

A way for clients to organize subscriptions by source and management scope, making it easier to update, filter, and manage servers separately. Groups do not usually become routing rules automatically, and moving a server into a group does not make specific apps use it. Before deleting or updating, check whether the action applies to the current group or all groups to avoid overwriting manually managed entries.

Subscriptions & servers

Latency

The time from starting a particular test to receiving a response; interpret it in the context of the test type. A TCP port check, an HTTP request, and a full proxy connection measure different stages and cannot be compared directly. Lower latency does not guarantee faster downloads. The test target, network congestion, and remote server load all affect results; a timeout only means the test did not finish within the allotted time.

Subscriptions & servers

Real connection latency

Usually the time measured when accessing a test address through a proxy connection, making it more representative of a real request path than a simple server port check. It may include proxy negotiation, DNS resolution, and the target’s response; the exact process depends on the client. If the test fails, check the logs to tell a server connection failure from an unreachable test site. One result alone cannot determine whether all traffic will work.

Routing

Identify the match conditions first, then choose the outbound. Domain sets, IP sets, and system proxy settings apply at different stages and are not interchangeable.

Routing

Routing rule

A configuration that matches requests by criteria such as domain, IP, port, or protocol, then selects an outbound. Common conditions include domain:example.com and geosite:private; supported syntax depends on the core and configuration editor. Rule order and the default behavior for unmatched traffic affect the result. Check the logs to see which rule matched rather than only confirming that the rule was saved.

Routing

Traffic routing

Directing requests to different outbounds, such as direct, proxy, or block, based on conditions. This is not a proxy protocol. A single app may contact multiple domains, so its requests can take different routes. When troubleshooting, check the routing conditions, DNS results, and whether the target information can be identified; do not assume one request’s result applies to the whole app.

Routing

GeoIP

An IP address collection grouped by category for routing rules to match, for example geoip:private. A label refers to a set in the data file; it does not confirm a target’s live location or measure connection speed. The collection’s contents and update schedule affect matching. A target with multiple addresses or changing DNS results may also match different rules.

Routing

GeoSite

A collection of domains grouped by service or purpose, reducing the need to maintain domain lists one entry at a time. Unlike GeoIP, it matches domains rather than IP addresses. Whether a label is available depends on whether the loaded data file contains it, not whether the label seems reasonable. If a rule does not match, check that the connection retains its domain name and that the accessed domain belongs to the set.

Routing

System proxy

Adding the local proxy endpoint to the operating system’s proxy settings for apps that honor them, such as a local HTTP listening port. It does not automatically route all traffic. Terminal tools, some apps, and browsers with their own proxy settings may use a different route. After enabling it, test the target app and confirm that the listening port matches the system settings; a running client alone is not proof.

DNS & networking

Resolving a domain and connecting to it are separate stages. When changing DNS, TUN, or sniffing settings, record the original values and change one setting at a time.

DNS & networking

DNS

The system that resolves domain names to IP addresses and other records. Apps usually need a DNS result before they can connect to a target. Which DNS resolver is used and which route traffic takes to reach it are separate questions. A browser’s encrypted DNS, the system resolver, and a client’s built-in DNS may all be active, so changing one setting may not affect every app.

DNS & networking

TUN mode

A way to capture traffic through a virtual network interface and process it in software, useful for apps that do not honor system proxy settings. It is a separate setting from the system proxy and may also involve permissions, system routes, DNS, and exclusion rules. After enabling it, check how it interacts with local network access and other virtual adapters; it does not guarantee that every connection is handled correctly.

DNS & networking

FakeDNS

A DNS method that assigns synthetic IP addresses to domains and stores the mapping; these are not the target services’ real public IP addresses. Subsequent connections must pass back through a processing chain that can recognize the mapping, restore the domain, and continue routing. If one program resolves the domain but another handles the connection, access may fail. FakeDNS therefore needs to work with traffic capture and routes for its IP address pool.

DNS & networking

DNS leak

When DNS requests are sent to other resolvers instead of following the expected path. Before checking for a leak, define which DNS route you expect. A test page’s resolver name alone cannot reveal every step the request took. Check system DNS, browser encrypted DNS, client rules, and app-specific settings separately; encrypted DNS does not automatically mean the request used the intended outbound.

DNS & networking

Traffic sniffing

A feature that identifies protocols or target domains from initial connection data to help match routing rules, for example by using information visible during part of a handshake. It does not decrypt application traffic and cannot extract a domain from every connection. Whether sniffed data is used only for matching or also changes the target address depends on the specific options. If compatibility problems occur, check the scope of the settings and compare the logs with sniffing enabled and disabled.