A reference for reading client settings · 26 common terms

V2Ray Glossary

Start by distinguishing protocols, cores and transport methods, then make sense of routing and test results. Look up terms as they appear in your client, with a direct anchor for every entry.

How the Pieces Fit Together

The client manages configurations → the core handles connections → the protocol structures requests → transport and security settings carry the data. Subscriptions update configurations; they do not determine connection quality.

Request Format & Authentication

Proxy Protocols

The protocol name is only one part of a connection configuration. Check the transport method, security layer and server parameters separately.

Proxy Protocols

VMess

A proxy protocol in the Project V ecosystem, with user authentication and data protection mechanisms. Configurations commonly use a UUID to identify the user. VMess works with different transport methods, so the protocol name alone does not tell you whether a connection uses WebSocket or TLS. If authentication fails, check the user ID, system clock and whether the configuration format is supported by the current core.

Next: WebSocket Transport →
Proxy Protocols

VLESS

A lightweight proxy protocol that does not encrypt application data on its own; connection security is usually provided by an outer layer such as TLS or REALITY. Check the UUID, transport, security settings and flow together rather than changing only the server address. The flow setting is not a speed tier; use it only when both the client core and server support that combination.

Next: REALITY Security Settings →
Proxy Protocols

Trojan

A protocol that usually carries proxy requests over TLS and authenticates with a password. A correct password does not mean the entire connection is configured correctly: the server name, certificate verification and port must also match. If the TLS handshake fails, check the security layer first; troubleshoot authentication parameters only after the handshake succeeds.

Next: TLS & Certificate Verification →
Proxy Protocols

Shadowsocks

A family of protocols that protects proxy traffic with specified encryption methods and keys; different methods and extensions are not necessarily interoperable. Keep the method name, password and any extension parameters consistent with the original configuration. Importing a node only means the client parsed its format; confirm that the selected core supports the method.

Next: Node Configuration Parameters →

The interface manages; the core does the work

Cores & Clients

When reporting an issue, include the client name, client version and active core separately to avoid conflating interface problems with connection problems.

Cores & Clients

V2Ray

The name of a network proxy tool in the Project V ecosystem, also commonly used as a catch-all for related clients and configurations. So “V2Ray won't connect” does not identify which layer is failing. For troubleshooting, specify the GUI client, the core actually running and their versions, then use the logs to locate the problem.

See the step-by-step troubleshooting guide →
Cores & Clients

V2Fly

A community project continuing development related to V2Ray. Its proxy core handles connections, routing and DNS. In a client interface, “v2fly” generally names a core option, not a subscription format or node protocol. If a subscription includes settings specific to another core, they may not carry over to V2Fly; check feature compatibility first.

Compare: Xray Core →
Cores & Clients

Xray

A proxy core project with shared technical roots with V2Ray, responsible for protocol connections, routing and transport. Its features, fields and supported combinations differ from V2Fly, so the names are not fully interchangeable. For REALITY or a specific flow, check both the core type and whether the running version supports the server requirements.

Next: REALITY & Core Support →
Cores & Clients

v2rayN

A desktop GUI client for managing proxy configurations and subscription groups and running a core, available for Windows, macOS and Linux. Interface options, permissions and core support depend on the version and distribution package; classic and cross-platform interfaces may differ. When following a tutorial, match the setting by name and function rather than expecting every button to be in the same place.

Get started with the desktop client →
Cores & Clients

v2rayNG

An Android GUI proxy client that commonly uses the Xray core for connections. The VPN permission requested at startup establishes a local traffic-tunneling interface; it does not mean traffic has reached a remote node. Whether requests use the proxy also depends on per-app settings, routing rules and node availability.

See VPN permissions & per-app settings →
Cores & Clients

v2flyNG

An Android GUI client that uses the V2Fly core and can serve as an alternative for compatible configurations. Similar names and workflows do not mean it supports exactly the same core features as v2rayNG. When moving nodes, check the protocol and transport settings again, along with system permissions and background-running restrictions.

Android client guide →

How connections carry and protect data

Transport & Encryption

Terms are grouped here to match common client settings. TLS and REALITY are security mechanisms; WebSocket and gRPC are commonly used as transport methods. They operate at different layers.

Transport & Encryption

TLS

A security protocol that protects transport connections and verifies the identity of the other endpoint. Proxy protocols can carry data through the secure channel it establishes. The server name usually participates in certificate verification and the handshake, so do not substitute a different domain. For certificate errors, check the system clock, server name, certificate validity and trust chain rather than enabling certificate verification bypass.

Compare: Trojan's Security Layer →
Transport & Encryption

WebSocket(ws)

A transport method that establishes two-way communication through an HTTP handshake, commonly abbreviated as ws in configuration. It is not a proxy protocol and does not automatically enable TLS; the same proxy protocol can use different transports. The path, Host and TLS server name are separate settings and must each match the server configuration when using a reverse proxy.

Next: TLS Server Name →
Transport & Encryption

gRPC

A communication framework commonly based on HTTP/2 that proxy cores can use as a transport. The service name in the client must match the server and reverse proxy settings; do not substitute a WebSocket path. If traffic passes through a reverse proxy, confirm that the intermediary correctly handles HTTP/2 and gRPC requests.

Troubleshoot connection and transport errors →
Transport & Encryption

REALITY

A transport security mechanism in the Xray ecosystem, often used with VLESS but not a standalone proxy protocol. The server name, public key, shortId and other parameters must match; fields and supported combinations depend on the core version. Do not confuse the public key required by the client with the server's private key, or assume the configuration is complete just because REALITY is selected in the interface.

Compare: VLESS & flow →

Whether a request enters the proxy, and where it goes next

Routing & DNS

Before troubleshooting routing rules, confirm that the app's traffic reaches the client. Before troubleshooting resolution, identify whether the app, system or core handles the domain.

Routing & DNS

Routing Rules

A ruleset that selects direct, proxy or blocked outbound traffic based on conditions such as domain, IP or port. The matching order, how multiple conditions within a rule are combined and the default outbound for unmatched requests all determine the result. “Global” in a client usually names a routing preset; it does not mean every app automatically sends traffic to the client.

Compare: System Proxy →
Routing & DNS

GeoIP

Rule data containing IP address ranges for routing matches, commonly organized by region or purpose. It is not a real-time location service; IP assignments can change with network deployments, and accuracy depends on how recently the data was updated. If a destination uses multiple service addresses, the rule matched also depends on the IP actually used for the connection.

Compare: GeoSite Domain Matching →
Routing & DNS

GeoSite

Rule data that groups domains by site, service or category for selecting an outbound by name. Available categories depend on the data file the client actually loads; not every label can be used directly. Domain categories do not necessarily correspond one-to-one with IP categories. After adding a rule, check the match in the logs.

Next: Rule Order & Default Outbound →
Routing & DNS

DNS

The system that resolves domain names to IP addresses and other records, forming one step in the domain access path. The app, operating system and proxy core may each handle resolution, so changing one DNS address in the client does not route every query through it. Check who sends the query, which outbound it uses and whether the result came from cache.

Next: DNS Query Paths →
Routing & DNS

FakeDNS

A mechanism that uses virtual IP addresses mapped to domain names to handle traffic; returned addresses are not the destination server's real addresses. When the request later reaches the core, it must recover the domain from the saved mapping before routing and connecting. Access can fail if DNS responses and traffic capture cover different scopes, or if a mapping is lost while the app still has it cached.

FakeDNS: How It Works & When to Use It →
Routing & DNS

DNS Leak

A DNS query sent through a different channel than the one specified by the intended resolution policy. Clarify the expected policy before deciding whether a query is a leak; a direct query may be an intentional local-resolution rule. Check system DNS, browser secure DNS, in-app resolution and core DNS separately rather than relying on a single test page.

Review the DNS resolution flow →
Routing & DNS

System Proxy

Proxy address settings provided by the operating system to applications; whether an app uses them depends on its implementation, and some programs use their own network settings. The system proxy determines whether a request reaches the local proxy, while core routing selects its outbound destination. After changing the listening port, check the address configured in the system proxy. Before closing the client, make sure the proxy settings are restored correctly.

Compare: TUN Traffic Capture →
Routing & DNS

TUN Mode

A way to capture IP traffic through a virtual network interface and system routing, useful for apps that do not use the system proxy. It usually requires additional permissions and interacts with DNS settings, the routing table and other network software, but does not guarantee that every app or protocol will be captured. If the network stops working after startup, check for routing conflicts and DNS paths; avoid stacking multiple traffic-capture tools.

Troubleshoot system networking & permissions →

Configuration Sources & Connection Tests

Subscriptions & Nodes

A successful update, a working node and suitable speeds are three different things. When testing, keep the method and target consistent before comparing results.

Subscriptions & Nodes

Subscription

A way to distribute and update a set of node configurations through a link, usually managed as a subscription group in the client. A successful update means the content was fetched and parsed, not that every node can connect. Subscription links may contain access credentials; do not show them in full in screenshots, public logs or support requests.

How to import a subscription →
Subscriptions & Nodes

Node

A selectable remote connection configuration in a client, typically containing a server address, port, protocol, authentication and transport parameters. The display name is just a label and does not confirm the server location, network path or actual performance. Nodes with the same name may use different configurations; compare their specific fields when troubleshooting.

Troubleshoot node timeouts →
Subscriptions & Nodes

Latency Test

A measurement of how long a particular test takes, such as an ICMP response, establishing a TCP connection or sending a request through a proxy. Different methods cover different parts of the connection and their results are not directly comparable. Low latency does not guarantee high sustained download speeds, which also depend on bandwidth, congestion, the destination service and device load.

Next: Real Connection Latency →
Subscriptions & Nodes

Real Connection Latency

Usually the time measured when a client sends an actual request to a specified test address through the selected proxy; implementation varies by client version. It covers more steps than a simple port connectivity test, but still reflects only that target and the conditions at the time. A timeout may be caused by the test address, DNS, handshake or routing. Check logs and actual access results; a timeout does not by itself mean the server is down.

Troubleshoot test timeouts & access issues →

Continue with the right guide

For hands-on help, follow the tutorial to import a configuration, choose a mode and verify the connection. If an error has already occurred, look up the symptoms in the troubleshooting guide. This glossary explains concepts and does not prescribe default ports or interface locations across client versions.

Download v2rayN