Configuration reference / 24 common terms

V2Ray Glossary

Look up terms by layer, from protocols and cores to traffic capture.

Identify which layer a term refers to before changing a setting. Protocols define how peers communicate, the core handles connections, and the client manages configuration. A subscription only provides connection settings; system proxy or TUN determines how app traffic reaches the client.

Configure a client step by step Browse guides for all platforms

Connection settings

Protocols and transports

Protocol, transport, and transport security are separate settings. After importing a configuration, keep the combination supplied by the server; changing only the protocol name is not enough.

VMessProxy protocol: VMess is a proxy protocol with user authentication and data protection. A typical configuration includes a server address, port, and UUID. It supports different transport options, but the client and server settings must match. If authentication fails, check the UUID, core support, and device clock rather than assuming the configuration is correct just because the port is reachable.

VLESSLightweight proxy protocol: VLESS focuses on lightweight authentication and forwarding; the protocol itself does not encrypt traffic, so deployments commonly pair it with TLS or REALITY. The UUID, transport, transport security, and any flow setting each serve a different purpose. Choosing VLESS does not make these settings optional, nor does it guarantee faster speeds on every network or device.

TrojanTLS-based proxy protocol: Trojan typically uses TLS to protect connections and a password for proxy authentication. A correct password and successful certificate validation are separate requirements. The connection may fail because of an incorrect server name, an expired certificate, or an inaccurate device clock. When troubleshooting, keep certificate validation enabled and first check the address, server name, and credentials provided by the server.

REALITYTransport security: REALITY is a transport security mechanism in the Xray ecosystem, commonly used with VLESS; it is not a proxy protocol that replaces VLESS. Clients typically need matching details such as the server name, public key, and short ID. Use the values provided by the operator. If required settings are missing or the core does not support REALITY, toggling a security option in the interface cannot make the connection work.

Runtime basics

Cores and ecosystem

A similar-looking interface does not mean the underlying capabilities are the same. To determine whether a setting is supported, check both the client and the core it actually runs.

Project VProject ecosystem: Project V is the project and ecosystem built around modular network proxy tools; V2Ray is one of its widely used core tools. “V2Ray client” is often used informally for graphical tools in this protocol ecosystem, but it does not guarantee that they all use the same core. For compatibility, check the specific client and core names.

XrayXray-core: Xray is an open-source proxy core derived from V2Ray that handles protocols, routing, and DNS. It shares technical roots with V2Fly, but their later features and configuration details are not identical. A feature may require a particular core version, and the graphical client must also generate the configuration correctly. The protocol name alone is not enough to establish compatibility.

V2FlyCommunity-maintained V2Ray: V2Fly is a community project that continues to maintain V2Ray-related implementations and develop modular proxy tools. It is not interchangeable with Xray for every configuration field. With v2flyNG or another client using V2Fly, check protocol, transport, and DNS support against the actual core version.

CoreCore / Runtime engine: The core is the underlying software that handles proxy protocols, routing rules, and name resolution; the graphical client manages settings and provides the interface. A client opening successfully does not mean the core is running. If startup fails, check the logs for configuration errors, permission issues, or port conflicts. Before switching cores, make sure the target core recognizes your connection settings.

Client interface

Clients and interfaces

For desktop, start with v2rayN. On Android, identify your core requirements first, then choose between v2rayNG and v2flyNG.

v2rayNDesktop client: v2rayN is a graphical client for Windows, macOS, and Linux, with tools for managing servers, updating subscriptions, and configuring proxy settings. Menus and features can vary by platform, interface version, and package. Match instructions to the interface you are using. Before downloading, choose the right operating system and processor architecture; then configure your subscription and traffic capture.

v2rayNGAndroid client / Xray: v2rayNG is an Android graphical client that uses the Xray core and can capture traffic after you grant Android's VPN permission. Selecting a server in the list is not enough; you must also start the service for app traffic to reach the core and follow its rules. If the service stops in the background, check battery optimization settings and VPN status rather than assuming the subscription has expired.

v2flyNGAndroid client / V2Fly: v2flyNG is an Android graphical client that uses the V2Fly core. It can be an alternative when you have a specific core compatibility requirement. Its name is similar to v2rayNG, but that does not mean the two clients support all the same extended settings. Before choosing it, check that the core supports your protocols and transports. After switching, review routing, DNS, and app traffic capture settings.

Inbound and outboundInbound / Outbound: Inbound receives traffic sent to the core by apps, such as connections to a local SOCKS listener. Outbound determines how traffic leaves the core, for example by connecting directly or forwarding through a remote server. Routing rules sit between the two and select an outbound based on conditions. The tags in a configuration are reference names; an outbound tag used by a rule must match a defined outbound, or startup or forwarding may fail.

Configuration sources

Subscriptions and servers

Importing, updating, selecting, and enabling are separate actions. A server appearing in a subscription only means its configuration has been added to the client.

SubscriptionSubscription: A subscription is a URL or data collection used to fetch and update server configurations in bulk. The client reads it and adds its entries to a list. An update may add or remove servers or change settings, but it does not prove that a server works or enable the system proxy. Subscription URLs may contain access credentials, so treat them as sensitive and hide the full URL before sharing screenshots or logs.

ServerServer profile / Node: A server is a common term for a set of connection settings in a client, usually including an address, port, protocol, authentication details, and transport settings. The label in the list is just for identification; it does not confirm the server's actual exit location or quality. After switching servers, confirm that the selected profile is active and reload the core if the client prompts you to.

Latency and real connection testLatency / End-to-end test: A basic latency test may only measure the time to connect to a server port, while a real connection test typically requests a test URL through the proxy and more closely reflects the forwarding path. The measurement method varies by client, so results are not always directly comparable. A low latency does not mean faster sustained downloads. Test failures can also stem from the test URL, DNS, or routing; check actual access and logs too.

Traffic destination

Routing and DNS

First confirm that traffic reaches the core, then check how the rules match it. If an app resolves domain names on its own, the core may see different information.

Routing rules and traffic selectionRouting / Traffic selection: Traffic routing selects an outbound for a connection based on conditions such as its domain, destination address, port, or protocol. Routing rules express those conditions. Rule order matters: a broad rule may match before a more specific one. When troubleshooting, check the match conditions, outbound tag, and fallback for unmatched traffic. Mode names in the interface are only summaries of preset rules.

GeoIP and GeoSiteIP sets / Domain sets: GeoIP typically provides address lists, while GeoSite provides domain lists that the core can use to simplify routing rules. These are rule-matching datasets, not live speed tests, and their classifications are not guaranteed to remain accurate. The data source, category names, and version all affect matches. If domain and address rules produce different results, check the DNS strategy as well.

DNS and FakeDNSName resolution / Synthetic mapping: DNS resolves domain names to addresses and other records that apps need to establish connections. FakeDNS returns synthetic addresses and keeps a mapping to the original domains so a compatible traffic-capture path can recover the destination. It cannot be enabled simply by changing the DNS server address. Resolution, core support, and traffic capture must work together, or synthetic addresses may not be routed correctly.

DNS leakUnexpected DNS path: A DNS leak usually means name queries are not following the intended resolution path—for example, a browser or the operating system is still querying another resolver directly. It describes a routing deviation, not necessarily a resolution failure. Check system DNS, client DNS, encrypted DNS in the browser, and routing settings separately. A resolver name shown in a single test does not prove how every app handles DNS.

Traffic entry points

System proxy and TUN

Consider traffic capture and outbound routing separately: traffic that enters the client may still connect directly under the routing rules instead of going through a remote server.

System proxySystem proxy: A system proxy is an entry point the operating system provides to apps that support the setting, often letting a browser connect to a local HTTP proxy. It does not capture traffic from every program. Command-line tools may use their own environment variables or ignore system settings entirely. If a browser works but a terminal does not, check each one's proxy settings first, then decide whether broader traffic capture is needed.

TUN modeVirtual network interface: TUN captures traffic at the network layer through a virtual network interface and can cover some apps that ignore system proxy settings. Enabling it usually requires additional permissions and coordinated routing and DNS settings; capabilities depend on the platform and client implementation. TUN does not mean every connection uses a proxy: traffic entering it can still connect directly according to routing rules. Check for routing conflicts when using it alongside another VPN or virtual network adapter.

SOCKS and HTTP proxy portsLocal proxy listener: A local port is the entry point apps use to connect to a proxy service. SOCKS and HTTP are different proxy protocols, so the app's protocol, address, and port must match the client's listener settings. For example, 127.0.0.1:10808 works only if the required service is listening on that port. The loopback address points to the local device; before listening on a LAN address, define who should have access and configure appropriate access controls.

VpnService and per-app proxyAndroid traffic capture: VpnService is an Android system API that lets an app create a VPN traffic entry point. The permission prompt means the app is requesting access to it. Per-app proxy settings determine which apps are captured; common options include capturing only selected apps or excluding selected apps, which mean opposite things. Traffic can still be routed by domain or address after entering the VPN, so selecting an app does not mean every connection it makes is forwarded through a remote server.