Project V · Xray · V2Fly
Six categories of the terms that come up again and again in V2Ray clients and configuration files. Each entry explains one thing only: what a given field, toggle or protocol name actually means in v2rayN, v2rayNG or a config file.
35 terms in total
Clients and interface
Subscriptions and servers
Routing and split routing
Transport and security
Troubleshooting and logs
The protocol names that show up in config files, and the two core branches that run them.
Project V is the collective name for the V2Ray family of tools: an open-source set of proxy programs built around the same JSON configuration format. The client handles the interface and process management, while the core does the actual forwarding. Two core branches, V2Fly and Xray, dominate the ecosystem today, and their configuration file structures are largely interchangeable.
Xray is the most actively developed core branch in the Project V ecosystem, extending the original protocols with features such as VLESS, XTLS and REALITY. v2rayNG uses the Xray core by default, and v2rayN lets you switch core type in its settings. Its configuration fields are broadly the same as V2Ray's, so most server parameters work with either one.
V2Fly is the core branch kept alive by the community after the original repository was archived, and it stays compatible with the existing V2Ray configuration format. v2flyNG is the Android client built on the V2Fly core, a good fit when the server side runs the same branch. Its release cadence is steady rather than fast, and most of its configuration fields overlap with Xray's.
VMess is the proxy protocol Project V developed in its early days; the client and server identify each other with a UUID and alterId. The protocol derives a connection check value from the current time, so a large clock difference between the two ends can produce a server that passes latency tests but refuses to connect. Newer cores have reduced alterId to a minor role, so leaving it at the default or setting it to 0 is enough.
VLESS is the lightweight replacement for VMess: it drops the built-in encryption layer and leaves encryption to TLS or REALITY. Identification needs only a UUID, the configuration has fewer fields, and the handshake costs less. Both ends must support it, and cores that are too old will not recognize the protocol at all.
Trojan is designed so that proxy traffic looks like ordinary HTTPS at the transport layer, which is why it must run with TLS. The configuration needs a server address, port and password, and the password doubles as the credential. V2Ray family cores support it as an outbound protocol, so Trojan servers can sit in the same subscription as VMess and VLESS ones.
REALITY is the transport security scheme introduced by Xray. It borrows the TLS handshake characteristics of a real site instead of a self-signed certificate, so the client needs no certificate files. Its configuration includes publicKey, shortId and serverName fields, all of which must match the server exactly. It only shapes the transport-layer handshake and does not affect which upper-layer protocol you choose.
Shadowsocks is an early lightweight proxy protocol that V2Ray family cores support as one of the outbound options. Its configuration fields cover the server address, port, encryption method and password, and the encryption method must match the server exactly. When a subscription contains this protocol, the client list usually shows only the encryption method and no transport options.
How the three clients differ, and the few switches in the interface that affect everything.
v2rayN is the desktop client for Windows, macOS and Linux, handling subscription management, server latency tests and core process control. Subscription groups and the server list sit on the left of the window, while the right side shows the configuration fields and switches of the selected server. The client itself only provides the interface and process management; the local core does the actual forwarding.
v2rayNG is the graphical client for Android and uses the Xray core by default. It takes over traffic through the system VpnService, and the first connection triggers a system permission prompt. Subscriptions, routing rules and per-app proxy settings are all configured in the same interface.
v2flyNG has essentially the same interface as v2rayNG; the difference is that it bundles the V2Fly core branch. It suits setups where the server also runs V2Fly and you want both ends on the same branch. The two apps can be installed side by side, and each keeps its own subscription data.
System proxy means the client edits the operating system's proxy settings so that browser requests go to a local listening port. It only covers programs that honor those settings, and some apps bypass them on their own. After you close the client, check that the settings were restored, or the browser may end up with no connectivity.
TUN mode creates a virtual network adapter and takes over all system-level traffic, including programs that ignore the system proxy settings. Turning it on usually requires administrator rights or system authorization, and the core decides where traffic goes according to the routing rules. Desktop and Android implement it differently, but the matching configuration fields are much the same.
Per-app proxy is the Android client's per-application routing feature: you choose which apps go through the proxy and which connect directly. It works at the VpnService level and applies to all traffic from a given app. A common setup is to proxy browsers and apps that need outside resources, while letting local service apps connect directly.
What happens between a subscription URL and one row in the server list.
A subscription is a URL maintained by the provider that lists servers; the client fetches it at a fixed interval and refreshes its local server list. The content can be a base64-encoded set of share links or a complete JSON configuration. With a subscription in place, servers are added and removed on the provider side, so you never have to enter them one by one.
Subscription conversion turns one subscription format into another, for example rewriting a base64 link collection as JSON that a client can read directly. Transport-layer fields and TLS parameters are the ones most easily lost along the way. Once the conversion is done, make an actual connection instead of only checking that the server count matches.
A share link packs the protocol, address, port, credentials and transport parameters of a single server into one URI, usually starting with vmess:// or vless://. It is meant for sharing one server on the fly and carries no grouping or routing information. The base64 section in the middle decodes to a JSON block whose field names map one-to-one onto the configuration file.
A server is one reachable machine together with its protocol parameters, shown as a single row in the client list. One subscription usually covers servers in several regions, with names chosen by the provider. A server carries no client logic of its own; switching servers only changes the outbound target.
Latency is the time between a test request from the client and the response, usually measured in milliseconds, where a smaller number means a faster round trip. The figures in the list come from active tests and shift with your local network and server load. They only reflect how quickly the connection answers, not real download speed or long-term stability.
A real delay test completes a full protocol handshake instead of only probing TCP connectivity. The result comes closer to what you actually experience, but it takes longer and puts more load on the server. When the list is long, narrow it down with ordinary latency first and run this test on just a few servers.
Rate is the weighting factor applied when traffic is counted for a server: a 1x server is charged at actual usage, a 2x server at twice that. The rate is set by the provider and has no direct link to how fast the server is. When picking a server, filter out the high-rate ones first, then compare latency and region.
The rule system that decides where traffic goes, and the two kinds of data files those rules depend on.
A routing rule decides which outbound a connection uses, and it combines conditions such as domain, IP and port with a target outbound. Rules are matched in order and stop at the first hit, so specific rules belong above general ones. In the configuration file they live in the routing.rules array, and the client interface presents them as checkable entries.
Split routing sends traffic to different outbounds based on the destination: local addresses connect directly, certain domains go through the proxy, ad domains get blocked. Sensible split routing cuts unnecessary proxy traffic and keeps LAN services off the proxy path. The result depends on both the rule sets and DNS resolution, and a poor setup on either side can interfere with the other.
GeoIP is a data file built from IP ranges grouped by region, referenced in routing rules as geoip:cn and similar. It judges the IP ownership of the destination, so a domain has to resolve to an IP before it can match. The data file needs regular updates, or newly allocated ranges may not match at all.
GeoSite is a data file built from domains grouped by category, referenced in routing rules as geosite:category-ads and similar. Unlike GeoIP, it matches domain names directly without waiting for resolution. The two are usually used together: domain rules first, IP rules as a fallback.
Inbounds describe which port and protocol accept incoming connections; outbounds describe where connections are finally sent. On a desktop client the inbound is usually a local listening port and the outbounds are the servers from your subscription. These two top-level arrays are where the whole configuration file begins.
The layer beneath the outbound protocol, handling the handshake, encryption and connection reuse.
TLS is the transport-layer encryption protocol, and in VLESS, Trojan and similar setups it handles encryption and certificate validation. The client has to fill in fields such as serverName and allowInsecure as the server requires. If the certificate domain does not match the address you actually connect to, the handshake fails outright.
WebSocket is a protocol that carries data in both directions over a single TCP connection, and it is often used as the transport layer for proxy traffic. The configuration needs path and host values that match the server exactly. It suits deployments that forward traffic through a reverse proxy.
gRPC is an HTTP/2-based remote procedure call framework used as one of the transport options in V2Ray family configurations. The key field is serviceName, and both ends must use exactly the same value. It handles multiplexing well, but the server has to enable the matching configuration too.
uTLS lets the client present the fingerprint of a chosen browser during the TLS handshake, selected through the fingerprint field. It changes how recognizable the handshake looks, not the strength of the encryption. Leave the field empty to use the core's default fingerprint.
mux merges several connections into one underlying connection, cutting the overhead of repeated handshakes. The gain is clearest on high-latency servers with many simultaneous connections. Some servers do not support mux, so if connections misbehave after you enable it, turn it off first and troubleshoot from there.
The first fields and switches to check when a connection goes wrong.
The log level controls how much runtime information the client records, with warning, info and debug as the usual values. Keep it at warning for everyday use and switch to debug temporarily when chasing a connection problem. debug writes a great deal of output, so set it back once you have found the cause.
A DNS leak means name resolution requests leave through the local network instead of the proxy path. It does not break the proxy, but the resolution result no longer matches the actual exit, and some sites treat that as suspicious. Letting the proxy side handle resolution, or naming a trusted DNS server in the configuration, reduces the problem.
FakeDNS has the core return a temporary address first and swap in the real destination once the connection is actually established, saving one resolution round trip. It is usually paired with TUN mode and requires the matching switch on both the client and the core. After turning it off, clear the local cache so old mappings do not linger.
Clock skew is the difference between local and server time, and the VMess protocol uses it to derive the connection check value. When the gap exceeds the allowed range, the usual symptom is a server that passes latency tests but fails the moment you connect. Setting the system clock to sync automatically normally clears this up.
No matching terms. Try another keyword, or clear the box to see all 35 entries.
This glossary is only an index. To see where each field sits in a config file and what values it takes, continue with the pages below.