V2Ray Glossary

Protocols, core engines, clients and routing. Browse terms by configuration layer.

Options next to each other in an interface do not necessarily do the same thing. A protocol defines how the two sides communicate; the core handles connections and routing; the client provides the configuration interface. Identify the layer first, then decide which setting to change.

6 categories 24 terms Jump to any definition

Protocols & transports

A protocol name is not a complete connection setup. Check authentication, transport and security settings separately.

Protocols & transports

VMess

A proxy protocol in the Project V ecosystem that uses parameters such as a user ID for authentication. VMess and transports such as TCP and WebSocket are different configuration layers, and TLS must be checked separately. When troubleshooting, verify the user ID, transport path and server name individually. Keep the device clock accurate, too, as a time difference can interfere with authentication.

Protocols & transports

VLESS

A lightweight proxy protocol that does not encrypt payloads by itself; connections typically use TLS or REALITY. When importing a configuration, retain the transport type and any flow parameter required by the server, as well as the user ID. Do not simply change the protocol name in a VMess configuration to VLESS; the server must support it too.

Protocols & transports

Trojan

A proxy protocol that typically uses TLS for secure connections and password-based authentication. The password, server port, server name and certificate validation all affect the connection, so checking the password alone is not enough. If you see a certificate error, first check the domain name and system clock. Disabling certificate validation should not be a routine fix.

Protocols & transports

REALITY

A transport security mechanism in the Xray ecosystem, often used with VLESS. It is not a standalone proxy protocol. The required public key, server name and shortId should come from the corresponding server configuration, and the fields must match. If the client reports unsupported fields after import, check which core is actually in use and what it supports rather than deleting parameters at random.

Core engines & projects

Project names describe a tool’s origins and maintainers; the core engine currently running determines whether a configuration can be applied.

Core engines & projects

Project V

A project ecosystem built around networking tools, with V2Ray as a key component. In everyday conversation, “V2Ray” can refer to the broader ecosystem, but the software you install may be a graphical client or a network core. When following a guide, identify which one it covers; core configuration fields are not necessarily options in every client interface.

Core engines & projects

V2Fly V2Fly-core

A community project continuing V2Ray development and maintenance; its network engine is commonly called V2Fly-core. The core handles incoming traffic, processes protocols and creates outbound connections according to routing rules, while the client provides the graphical interface. Protocol and transport support depend on the core version, so using a particular client does not guarantee support for every configuration in the ecosystem.

Core engines & projects

Xray-core

A network core derived from V2Ray that handles protocols, routing and connections. It shares a history with V2Fly-core, but their later features and configuration fields are not identical. Before switching cores, confirm that the target supports the protocols, security mechanisms and transports in your current configuration, and keep a recoverable copy of the original settings.

Clients & configuration

Clients organize settings; system proxies and virtual interfaces determine how traffic enters the processing chain.

Clients & configuration

v2rayN

A graphical client for Windows, macOS and Linux, with tools for subscription management, routing and proxy settings. The interface manages configuration, while the bundled core handles network connections, so a working interface does not mean the core has started successfully. Menus may differ between desktop versions; follow the feature names in the version you are using.

Clients & configuration

v2rayNG

An Android graphical client that uses the Xray core to handle connections and supports server configurations and subscription groups. Its common VPN mode captures app traffic through Android’s VPN interface and requires permission. A VPN icon only confirms that the capture interface is established; test an actual request to verify the remote connection and routing.

Clients & configuration

v2flyNG

An Android graphical client built around the V2Fly core, suited to configurations supported by that core. Its name is similar to v2rayNG, but the two do not have identical core capabilities and are not the same app. Check your subscription requirements first, then decide whether the interface and management features suit your workflow; do not migrate a configuration based on the name alone.

Clients & configuration

System proxy System proxy

A setting that points the operating system’s proxy address to a local listening port on the client. Only apps that honor this setting send traffic through it. It determines whether traffic enters the client; routing rules determine which outbound route it takes afterward. If the client exits but leaves a broken local proxy address in place, affected apps may lose network access. Check the system proxy setting in that case.

Clients & configuration

TUN mode Virtual interface

A method of capturing IP packets through a virtual network interface and passing them to a proxy component. It can cover apps that do not follow the system proxy setting. Actual coverage depends on routing, permissions and DNS settings; it does not mean all traffic exits through the proxy. Check that the client supports TUN before enabling it. If multiple traffic-capture tools are running, rule out interface and routing conflicts.

Routing & traffic splitting

Check the match criteria first, then rule order, and finally whether the selected outbound route exists.

Routing & traffic splitting

Routing rules Routing rules

Settings that select an outbound route based on criteria such as domain, IP, port or inbound connection. Outbound routes are usually referenced by tag. Many core engines check rules in order, so a broad rule near the top can stop more specific rules below it from matching. Check both the conditions and whether the outbound tag is valid. Connections that match no rule are still handled according to the core’s default behavior.

Routing & traffic splitting

Traffic routing Traffic routing

Directing connections to a proxy, direct or blocked outbound route according to routing rules. Direct means the connection to its destination does not pass through a proxy server; it does not mean the local core skips its rule checks. Traffic routing does not automatically improve speed. Rule coverage, DNS results and the destination address actually used by the app all affect the route.

Routing & traffic splitting

GeoIP

A rule tool that uses categorized datasets to match IP address ranges. For example, geoip:private is commonly used to match private address ranges. It matches IP addresses, not the language of a website’s interface, and cannot guarantee which organization a site belongs to. If a domain must first be resolved to match an IP, check the core’s DNS strategy and the actual lookup result.

Routing & traffic splitting

GeoSite

A rule tool that groups domains by category; geosite:cn is a common reference. Whether a domain is included depends on the data file in use and whether it is up to date, not on the label alone. If an app provides only the destination IP, domain rules can work only if the core obtains the domain through another mechanism.

Subscriptions & server profiles

A subscription is a way to fetch configurations; a server profile defines a connection; a group organizes profiles.

Subscriptions & server profiles

Subscription Subscription

A way for a client to retrieve a set of server configurations from a URL, in a format the client can recognize. A successful update only means the content was fetched and parsed; it does not mean every server in it can connect. Subscription URLs may contain access credentials, so hide the full URL before sharing logs or screenshots. If an update fails, first check that the URL is valid and that the network path is working.

Subscriptions & server profiles

Server profile Server profile

A common name for a remote connection configuration in a client, usually containing an address, port, authentication details and transport settings. The list alias is only a display name; it does not prove the server’s location, performance or availability. Two profiles with different names may use the same address. Compare their actual fields to check for duplicates.

Subscriptions & server profiles

Subscription group Subscription group

A way to organize server configurations by subscription source, making them easier to update, filter and manage. A group is not a routing rule and does not automatically use all its profiles at once. Before manually changing subscription-generated entries, check how the client handles updates; the next update may regenerate configurations and overwrite some changes.

Networking basics

DNS resolution, traffic capture and actual requests are separate steps. Read test results in context of how the test was run.

Networking basics

DNS Domain Name System

A system that translates domain queries into records such as IP addresses, usually as a step before an app connects. Apps, the operating system and a proxy core may each perform their own lookups, so configuring DNS in the core does not mean every app uses it. When troubleshooting, distinguish who receives the DNS query from where the application connection goes; the two paths may follow different rules.

Networking basics

FakeDNS

A mechanism that returns a mapped address to an app while a proxy component keeps track of the address-to-domain mapping, so it can recover the destination domain for a later connection. It requires traffic capture and is not a standalone encrypted DNS service. If an app bypasses the proxy interface after receiving a mapped address, the connection may fail. Watch for stale DNS cache entries after leaving the relevant mode, too.

Networking basics

DNS leak DNS leak

A DNS query sent to an unintended resolver instead of following the expected resolution path. Before assessing a leak, establish which queries the core should handle and which may be resolved by the local network; the resolver’s location alone is not enough. Browser encrypted DNS, system resolver settings and app-specific resolvers can all change the path, so check them separately.

Networking basics

Latency Latency

The time from sending a particular probe to receiving a response. Tools may measure ICMP, TCP or an application-layer request, so results from different tests are not directly comparable. Low latency does not mean high download speed. A timeout may also mean the target rejects that type of probe; check an actual website or service request before removing a configuration based on a single result.

Networking basics

Real connection latency Real connection latency

The time taken by a client to make an actual request through the selected proxy configuration. It covers more connection steps than a simple port probe, but whether it includes DNS resolution, a handshake or connection reuse depends on the client and test endpoint. A successful test only confirms that this request completed; test other destinations separately, as routing, DNS or server policies may affect them.

From concepts to configuration

For a first-time setup, choose a client for your operating system, import a configuration and confirm the traffic entry point. If an existing configuration cannot reach a destination, note the symptoms and error message, then check core startup, subscription updates, DNS resolution and routing matches separately. Avoid changing settings across multiple layers at once.