Configuration Reference · Glossary

V2Ray Glossary and Configuration Terms

From subscription URLs to routing outbounds, understand what each setting controls. This glossary groups common v2rayN, v2rayNG, and v2flyNG terms into six categories, with a direct link to every entry.

New to configuration? Start with “Subscriptions and Nodes.” If a connection fails, distinguish client settings from core behavior and server parameters, then check the relevant section.

View the Setup Guide Troubleshoot by symptom →

Protocols and Transports

The protocol defines how the two sides exchange proxy data; transport settings define how that data is carried. Using the same protocol name does not mean you can omit the address, authentication, or transport parameters.

VMessproxy protocol
VMess is a proxy protocol with authentication and encryption, commonly configured with a server address, port, and user ID. The client and server must also use compatible transport and security settings, so a correct user ID alone is not enough to establish a connection. If authentication fails, check that the system clock is synchronized—a significant time difference can disrupt verification. Support for legacy configuration fields depends on the core version in use.
VLESSproxy protocol
VLESS separates authentication from data transport and does not encrypt data on its own, so it is usually paired with a security layer such as TLS or REALITY. The user ID, security layer, and transport settings must match the server. A VMess configuration cannot be reused just by changing its protocol name. Support for a particular combination depends on the core and its version, not on whether the graphical interface shows a similarly named option.
TrojanTLS proxy protocol
Trojan typically uses TLS to secure the connection and a password for authentication. If the password is correct but the handshake still fails, check the server name, certificate trust, and transport settings instead of repeatedly changing the password. The connection address in a node may differ from the domain used for TLS, so keep the corresponding server-provided parameters intact. Check core support before using additional transports.
ShadowsocksSS · encrypted proxy protocol
Shadowsocks establishes a proxy connection using an agreed encryption method and password or key. Different protocol versions may require different key formats, and the client core must support the selected encryption method; do not switch it arbitrarily to another option in the list. After importing a share link, check that the server, port, and encryption method are all present. Usability also depends on the server and network path.

Cores and Ecosystem

The graphical client manages configuration; the core handles connections. Understanding the distinction helps you figure out where to set a feature and where to start when something goes wrong.

Project Vmodular proxy ecosystem
Project V is an ecosystem built around modular proxy capabilities, with V2Ray as one of its widely used core projects. Concepts such as inbounds, outbounds, routing, and transports come from this modular design, which lets different components work together. Project V is not another name for a desktop app: when you import a node into v2rayN, the client organizes the configuration and passes it to the selected core to run.
V2FlyV2Ray community core lineage
V2Fly is a community project that continues development of the V2Ray core, providing foundational capabilities such as protocol handling, routing, and DNS. v2flyNG follows this core lineage and is suited to configurations that match its capabilities. V2Fly and Xray share technical roots, but their features have developed independently. Before using a configuration, confirm that the target core supports its protocols, fields, and security transport combination.
Xrayindependent proxy core
Xray is an independently developed core project with technical roots in V2Ray, and commonly supports configuration features such as REALITY and XTLS Vision. v2rayNG uses the Xray core. For desktop v2rayN, check the current version and settings to see which core is actually in use. Similar protocol names do not guarantee full configuration compatibility; when copying a configuration, check the security layer, flow-control parameters, and version requirements.
Corecore
The core is the program that establishes connections, handles proxy protocols, and applies routing and DNS policies. The graphical client mainly provides the interface and generates configuration. A running interface does not mean the core started successfully: a port conflict or invalid configuration field can still prevent startup. Check the core startup log first, then the request log; these offer more useful evidence than the presence of a tray icon.

Routing

Routing determines which outbound handles a connection. Check the matching conditions, rule order, and default route for traffic that matches no rule together.

Routingrouting
Routing directs traffic to different outbounds based on domains, IP addresses, or other connection details. Common labels include direct, proxy, and block, indicating direct, proxied, and blocked traffic; the corresponding outbound definitions determine what they actually do. A routing mode is not the same as the system proxy toggle: traffic must reach the core before rules can be evaluated.
GeoSitedomain category list
GeoSite organizes domains into categories. Routing rules commonly refer to these lists with entries such as geosite:cn or geosite:category-ads-all. GeoSite matches domain categories, not the geographic coordinates of target servers, and results depend on the data file in use. If a rule does not match, check that the list exists and its data is current, and that the core has a domain name available to match.
GeoIPIP address range list
GeoIP organizes IP address ranges into categories. For example, geoip:private identifies private addresses and similar targets. Its matching criteria differ from GeoSite: GeoIP works with address ranges, while GeoSite uses domain lists, and the two can be used together. Whether a domain request reaches IP matching also depends on DNS resolution, so a website's name alone cannot tell you whether it will match a GeoIP category.
Routing rulerouting rule
A routing rule consists of matching conditions and a target outbound. Conditions can include domains, addresses, ports, or protocol characteristics. Rules are usually evaluated in order: put specific conditions first, then broader ones, and confirm the default outbound for traffic that matches none. Read the core's syntax to understand how multiple fields in one rule combine and how domain lists match; do not infer this from their order in the interface alone.

Subscriptions and Nodes

A subscription fetches configuration, a node describes a connection, and a test checks a particular path. A successful update, an available node, and a working connection are three different things.

Subscriptionsubscription
A subscription fetches and updates a set of node configurations from a URL. The client parses the response and adds the nodes to a specified group. A successful update only means the configuration was refreshed; it does not mean every node can connect or that the currently selected node has changed. Subscription URLs may contain access credentials, so hide the full URL before sharing screenshots, asking for help, or syncing to another device. Also check that the client supports the returned format.
Nodeserver profile
A node is a set of server connection parameters saved by the client, usually including the address, port, protocol, authentication, and transport settings. The name in the list is just a label to help identify the configuration; it does not establish the server's location, availability, or performance. If a connection times out after import, check the selected node, its parameters, and server reachability instead of simply reordering nodes by name.
Latencylatency
Latency is a response time measured using a particular test method. TCP reachability tests, protocol handshakes, and webpage requests measure different stages. A low result does not guarantee high download throughput or prove that every app uses the same outbound. For meaningful node comparisons, use the same test method and destination at roughly the same time. If a test fails, use the logs to distinguish a timeout from a resolution or authentication error.
Real connection latencyreal connection latency
Real connection latency usually means the time taken to access a test URL through a specified proxy outbound, though the exact process depends on the client. It may include DNS resolution, connection setup, the protocol handshake, and the destination's response, making it closer to a real request than a simple server port test. Results still depend on the test site and route, and a successful test does not guarantee that other sites or apps will work.

Security and Encryption

Security parameters must match the server. Diagnose handshake errors step by step; disabling verification is not a general fix.

TLSTransport Layer Security
TLS protects data in transit and authenticates the server using certificates, among other mechanisms. It is commonly used as a secure transport layer for proxy protocols. Certificate trust and validity, domain name matching, and the system clock can all affect the handshake. If you see a certificate error, check these conditions first. Skipping certificate verification weakens authentication and is no substitute for correcting invalid parameters.
REALITYXray secure transport
REALITY is a secure transport mechanism in the Xray ecosystem, often used with VLESS and XTLS Vision. It is not a switch that can replace any TLS setting. The client public key, server name, shortId, and related fingerprint parameters must meet the server's requirements; available fields depend on the version in use. If the handshake fails, check the full set of parameters and core support instead of changing only the connection address.
SNIServer Name Indication
SNI is an extension that sends the server name during the TLS handshake, helping the server select the right site and certificate. A node's connection address can be an IP address or differ from the server name, but the name you enter must match the server configuration and certificate requirements. The client may label this field “Server Name” or serverName. If the domain does not match, check the node's supplied parameters rather than entering an arbitrary common domain.
DNS leakDNS leak
A DNS leak occurs when queries take an unexpected resolution path; not every direct DNS query is necessarily a problem. The operating system, browser, and client may each use different resolution methods, so a working proxy connection does not by itself confirm that DNS is following the expected path. First determine which path should resolve each domain, then check the client logs, browser secure DNS settings, and system DNS configuration.

Client Features

These features control how traffic reaches the core and how the core identifies destinations. Support can vary by client and core version, even when a feature has the same name.

System proxysystem proxy
System proxy settings are provided by the operating system. Apps that honor them send requests to the specified proxy address. Some programs use their own proxy settings or connect directly, so enabling the system proxy does not route all traffic. With v2rayN, also confirm that the core is running, the local listening port is correct, and the app uses system settings. After closing the client, check that it has not left an unusable proxy address behind.
TUN modevirtual network interface
TUN mode receives traffic through a virtual network interface and passes it to a supporting program, making it useful when more app connections need to be covered. It typically involves system routes, permissions, and DNS settings, unlike simply changing the system proxy. If the network stops working after enabling it, check that the virtual interface was created, look for route conflicts, and verify DNS resolution. After disabling TUN mode, confirm that the original network settings have been restored.
FakeDNSsynthetic IP and domain mapping
FakeDNS returns a synthetic IP address for a domain and saves the mapping so the core can restore the original destination for later connections. It does not randomly change the real server address or automatically block ads. It requires core support and compatible inbound and traffic-capture settings. Apps that bypass this DNS path or retain old cached results may behave unexpectedly, so check the cache, mappings, and actual connection path after changing settings.
Traffic sniffingsniffing
Traffic sniffing attempts to identify details such as domain names from protocol metadata in some connections, including readable HTTP host information or TLS server names. This can help with domain-based routing, but it cannot identify every connection or decrypt encrypted content. Check the specific settings to understand whether sniffing only affects routing decisions or can also override the destination address. If compatibility issues arise, temporarily disable it and compare the logs.

From Concepts to Configuration

First confirm that the node parameters match the server. Then check which inbound receives the traffic and which outbound the routing rules select. This glossary explains what settings mean; step-by-step instructions and error fixes are covered in the setup guide and troubleshooting pages.

Download v2rayN