Organized into six categories: clients and cores, protocols and transport, subscriptions and nodes, routing and split tunneling, network and ports, logs and diagnostics. Each of the 29 common terms starts with a one-line definition, then explains where it sits in the config and when it matters.
How to use this page
Start from the category index to find a section, then follow the cross-links under each term card to related concepts. The mapping between terms and config file fields is collected in the table at the end of the page.
The three GUI clients handle the interface and configuration management, while the actual forwarding is carried out by the Xray or V2Fly core; the two roles work together rather than replacing each other.
v2rayN
A V2Ray GUI client for Windows, macOS and Linux that manages subscriptions, node selection, routing settings and the local listening port. It does not implement proxy protocols itself: the actual forwarding is done by the Xray or V2Fly core, and the interface only generates configs and manages the core process. The desktop build comes in two interface forms, the desktop version and the classic WPF version.
v2rayNG
A V2Ray GUI client that runs on Android, paired with the Xray core by default. It takes over traffic through the system VPN service without root access, and its subscription, routing and DNS settings follow the same configuration semantics as the desktop client.
v2flyNG
Another Android GUI client that runs on the V2Fly core, with an interface structure close to v2rayNG. It works as an alternative entry point when nodes use older VMess parameters or need transport combinations specific to V2Fly.
Xray core
A core branch in the Project V ecosystem that handles protocol parsing, encryption, routing matches and outbound connections. Clients write a JSON config and hand it over to execute; upgrading the core brings new protocol support without changing the interface.
V2Fly core
A community-maintained branch of Project V used as the runtime core by v2flyNG and some desktop clients. It is largely compatible with Xray in config structure, but the supported protocol set and transport options are not identical, so check which branch is running before troubleshooting.
These terms appear in the first two sections of a config file: the protocol decides how identity is verified, the transport layer decides what the packets look like.
VMess
An early flagship V2Ray protocol in which client and server verify identity through a UUID and timestamp, so the system clocks on both ends need to be roughly in sync. The config usually still carries an alterId parameter, which newer cores treat as a compatibility option.
VLESS
Compared with VMess it drops the extra encryption layer and timestamp verification; authentication relies only on a UUID, so the handshake is shorter and the overhead lower. VLESS provides no encryption itself and is usually combined with TLS or REALITY, leaving confidentiality to the transport layer.
Trojan
Proxy traffic is placed inside a standard TLS connection, so the server looks like an ordinary HTTPS site and falls back to the real site content when the password does not match. It has very few config options and depends mainly on a domain and certificate, which suits setups that already have a certificate.
REALITY
During the handshake the client negotiates TLS directly with a real target site, so no domain or certificate of its own is needed. The server only relays the handshake and holds the private key, and the certificate chain is inherently trusted; the trade-off is that the target site must stay reliably reachable.
XTLS Vision
A set of techniques that shape TLS record-layer fingerprints; by controlling fragmentation and padding they make encrypted traffic length distributions closer to ordinary web browsing. They only make sense together with TLS or REALITY.
Where nodes come from, how they are updated and what a single entry looks like: these terms cover the import step.
Subscription URL
A URL that returns a node list; the client requests it and parses the response into individual nodes. The link usually carries a token parameter that identifies the user, so it counts as account credentials and should not be shared publicly.
Subscription update
The process in which the client requests the node list again from the subscription URL and replaces the old local entries with the new result. Most clients support both manual and scheduled updates; updating once before switching nodes avoids connecting to addresses that are already offline.
Node
A complete node description covers server address, port, protocol, transport and authentication parameters. The client arranges nodesintoa list, and routing rules decide which traffic goes to which node.
Share link
A single node's parameters encoded as text with a protocol prefix; common prefixes are vmess://, vless:// and trojan://. After import the client restores it as one node entry; unlike a subscription it holds only one node and never updates automatically.
The whole matching mechanism that decides whether traffic goes through the proxy or connects directly; order and match targets are the two keys to understanding it.
Routing rule
A set of conditions matched in order; each rule states the match target (domain, IP, port, process) and the action on a hit (proxy, direct, block). Matching runs from top to bottom and stops at the first hit, so rule order directly affects the result.
Split tunneling
A way of sending some traffic through the proxy and connecting the rest directly. A common setup marks mainland China domains and IP ranges as direct and sends everything else through the proxy, which eases the load on nodes and keeps local services from being routed around.
GeoIP
An IP geolocation database built into or attached to the core, referenced in routing rules as geoip:cn. It answers which region an IP belongs to and works for targets reached directly by IP; domain targets must be resolved to an address before they can match.
GeoSite
A domain list grouped by site category, written in rules as geosite:category-ads. Compared with listing domain suffixes one by one, it handles common site groups in bulk, and the database can be updated together with the core.
Inbound and outbound
Inbound describes where traffic enters the core, such as a local SOCKS port or a TUN virtual adapter; outbound describes how it leaves, such as a particular node or a direct connection. Routing rules exist to choose between inbound and outbound.
The entry points the core opens on the local machine, the two ways of taking over traffic, and where resolution requests should go.
Local listening port
The port the core listens on locally, commonly SOCKS 10808 and HTTP 10809. The browser or system points traffic at this port and the core forwards it according to routing rules; if another program already holds the port, the client fails to start and writes the reason to the log.
SOCKS5
A proxy protocol that forwards both TCP and UDP and only passes traffic to the proxy side, without caring whether the layer above is HTTP or something else. Desktop clients usually use SOCKS5 as the local entry point for the best compatibility.
System proxy
The client changes the operating system proxy settings so HTTP and SOCKS requests point at the local listening port. It only covers apps that honor the system proxy; applications that read network settings themselves still connect directly, and those need TUN mode instead.
TUN mode
The core creates a virtual network adapter and points the default route at it, so app traffic is taken over at the network layer and no longer depends on per-app proxy settings. The trade-off is that it needs higher system privileges, and DNS handling must be configured separately or resolution errors are likely.
FakeDNS
The core first returns a fake IP from a reserved range for a domain, then restores the domain from the mapping when the app actually opens a connection and hands it to routing rules. This lets IP-based connections benefit from domain-based split tunneling, at the cost of clearing the local DNS cache when needed.
DNS leak
An app performs a DNS query before opening a connection; if that query goes out over the local network instead of the proxy tunnel, the target domain is exposed to the local resolver. The usual fixes are to specify DNS servers explicitly in the core or let TUN mode take over DNS traffic.
What to look at first when something breaks and which numbers are worth comparing: these terms are the starting point of troubleshooting.
Runtime log
The core records startup, config loading, connection setup and errors in chronological order; it is the first source of evidence when troubleshooting. Timestamps, outbound tags and error keywords in the log narrow a problem down to a specific step.
Log level
Common values are warning, info and debug; the more detailed the level, the more is recorded and the faster the log file grows. Keep it at info for everyday use and switch to debug only while reproducing a problem, then switch back.
Real connection delay
The client actually opens a connection to the node and waits for a response, measuring the round-trip time including handshake and authentication. It reflects real experience better than ping, at the cost of one connection per test; an unavailable node shows up as a timeout.
Handshake
The process in which client and server exchange identities and negotiate encryption parameters before sending data. Handshake time shows up directly in first-connection speed and is the part that TLS, REALITY and XTLS focus on optimizing.
The terms you see in the interface usually map to the fields below in the config file. Field names follow the core documentation and may differ slightly between versions.
| Term | Config file location | Common interface location |
|---|---|---|
| Local listening port | inbounds[].port |
Settings → Local listening port |
| Routing rule | routing.rules |
Routing settings → Rule list |
| Inbound and outbound | inbounds / outbounds |
Node list and routing settings |
| GeoIP and GeoSite | the domain and ip fields of routing.rules |
Routing settings → Rule list |
| FakeDNS and DNS | dns.servers、dns.fakeDns |
DNS settings → Servers |
| Log level | log.loglevel |
Settings → Log level |
| TUN mode | the tun protocol under inbound | Settings → TUN mode |
| Subscription update | Managed locally by the client, not written to the core config | Subscriptions → Update subscription |
Terms map to concrete operations across the tutorial and troubleshooting pages; when a real error appears, you can jump straight to the troubleshooting flow.