Configuration reference / 28 common terms
Protocols define how data is exchanged, cores handle connections, and clients manage settings. Know which layer you're working with before checking its fields.
Terms are grouped by the concepts you encounter while configuring V2Ray. Each entry explains what a term means and where its use begins and ends, with links to jump directly to it. Menu labels in v2rayN, v2rayNG and v2flyNG can change between versions; an option in the interface does not mean every core supports the same parameters.
Need complete rule examples? See Advanced Setup →01 / Connection structure
Proxy protocols, transport methods and transport security are separate layers. Check each one when reviewing connection settings; the protocol name alone is not enough.
Proxy protocol · Authentication and encryption
VMess is a proxy protocol in the Project V ecosystem, with authentication and encryption. The user ID is usually a UUID. After importing a profile, check its transport, security settings and server requirements rather than comparing UUIDs alone. Significant clock drift can also cause authentication to fail, so check the device's time when troubleshooting a connection.
Proxy protocol · Separate from transport security
VLESS is a lightweight proxy protocol that does not encrypt traffic on its own; connections commonly use TLS or REALITY. A UUID authenticates the user but does not describe the full security of a connection. Check the security layer, transport and any applicable flow field. Do not copy VMess fields over unchanged.
Proxy protocol · Carries traffic over TLS
Trojan typically carries proxy traffic over TLS and authenticates with a password. The server address, port, password and TLS server name must match; certificate verification is also part of the connection. For handshake errors, check the server name and certificate requirements first. Disabling certificate verification should not be treated as a standard fix.
Encrypted proxy protocol family
Shadowsocks establishes a proxy connection using an agreed encryption method and password. Parameter formats vary between protocol generations, and a client listing Shadowsocks does not mean its core supports every encryption method. If import fails or connections behave unexpectedly, check the method name, password format and the current core's supported implementations.
Transport security · Not a proxy protocol
REALITY is a transport security solution in the Xray ecosystem, often paired with VLESS. It is not a protocol field at the same level as VMess or Trojan. Clients typically need connection details such as the server name, public key and short ID. These fields must come from the same server configuration, and the selected core must support the combination.
Transport · TCP, WebSocket and more
Here, transport means how the proxy protocol carries data, such as over TCP or WebSocket; it is not the node's display name. A WebSocket path and request headers are separate from the TLS server name and cannot replace it. If the transport settings on each end differ, the connection may fail even when the address and authentication details are correct.
02 / Execution and management
The graphical interface edits and manages settings; the core handles the traffic. To check whether a feature is available, verify both the client interface and the core version.
Configurable network proxy ecosystem
Project V is an ecosystem of configurable network proxy tools, with V2Ray as one of its major projects. In everyday use, “V2Ray client” often means a graphical app that manages a related core, not the name of a specific software package. When following a guide, identify whether it refers to a protocol, core or interface to find the right configuration settings.
Community project maintaining V2Ray Core
The V2Fly community maintains V2Ray Core, which handles proxy connections, routing and DNS. v2flyNG uses this core family; its capabilities depend on the version bundled with the client. If a configuration example is for a different core, do not import it just because the JSON looks similar.
Proxy core · Technically related to V2Ray
Xray is a proxy core project with technical roots in V2Ray and its own protocol and configuration capabilities. v2rayNG commonly uses Xray, and desktop clients may also offer it as a core option. If a field is not recognized, check which core and version is actually running rather than relying on the client name.
Desktop graphical client
v2rayN provides a desktop interface for managing servers, subscription groups, routing and network modes, with desktop versions for Windows, macOS and Linux. The interface typically generates the runtime configuration from your selections, while the chosen core handles connections. Before editing a generated file, check whether the client will rewrite it on restart or when you switch configurations.
Android graphical client · Xray
v2rayNG is an Android graphical proxy client for importing share links, managing subscriptions and adjusting routing. Its common VPN mode routes device traffic through Android's VPN interface, but still requires a valid remote connection profile. A VPN icon only indicates that the interface is active; it does not confirm that a site or app is reachable.
Android graphical client · V2Fly
v2flyNG is an alternative Android client built on the V2Fly core, suited to configurations that rely on its core-specific behavior. Some concepts overlap with v2rayNG, but protocol combinations and advanced field support are not necessarily identical. Before switching clients, check whether your current connection relies on a feature specific to its core.
03 / Configuration sources
Subscriptions deliver configurations; nodes describe individual connections. Updating, importing and testing are separate actions, and success at one does not replace full connection testing.
Subscription · Source for updating configuration lists
A subscription provides an updatable list of server configurations through a link. Its response may contain an encoded list of share links or another format supported by the client. Subscription URLs often include access credentials; do not post them publicly or submit them to a conversion service without checking first. A successful update means the content was retrieved and parsed, not that every connection works.
Server connection profile
Node is a common client-side term for a remote proxy connection profile, including its address, port, authentication, protocol and transport settings. The name in the list is only a label and does not determine where traffic goes. The same address with a different port or authentication detail can represent a separate profile, so compare each field when troubleshooting.
Source management · Updates and filtering
Subscription groups organize server configurations by source or purpose, making it easier to update, filter and check for inactive entries. Managing groups in a client is not the same as setting routing policies in the core; creating a group does not automatically send traffic from a particular app through it. Also note that the next update may regenerate or overwrite some manually edited subscription nodes.
URI · A way to share a single configuration
Share links represent connection profiles with prefixes such as vmess:// and vless://, followed by encoded data or URI parameters. Missing query parameters, altered escape characters or added line breaks can leave fields incomplete after import. Share links may also contain authentication details, so check their contents before taking screenshots or forwarding them.
Time taken by a test request through the proxy
Real connection latency usually means the time taken for the client to send a request to a test target through the selected proxy; which stages are included depends on the test implementation. It reflects the actual request path more closely than a basic port check, but is not a measure of download speed or long-term reliability. Compare results using the same target and test conditions, and check the logs before drawing conclusions from a single timeout.
04 / Matching and outbounds
First check whether the connection has a domain name or only an IP address, then review rule order and outbound tags. Categories in rules only work when the corresponding data is available.
Routing rule · Condition matching
Routing rules select an outbound based on conditions such as domain, IP, port or inbound. Common V2Ray field rules are evaluated from top to bottom, so put specific exceptions before broad categories. Multiple different conditions in a single rule usually all need to match; adding another condition can narrow the match rather than broaden it.
Routing traffic by destination and connection conditions
Traffic routing directs traffic to an outbound such as direct, proxy or block; it is not a proxy protocol. The outcome depends on rule order, domain information, DNS resolution and the default route when no rule matches. “Global” in a client interface must also be understood in the context of how traffic is captured; it does not prove that every app is routed through the proxy core.
IP range classification dataset
GeoIP organizes IP address ranges by region or purpose. Routing rules can reference categories such as geoip:cn or geoip:private. Matches reflect the current data file, not a live measurement of a server's physical location. If a connection provides only a domain name, whether IP rules can be evaluated also depends on the domain resolution strategy.
Domain classification dataset
GeoSite groups domains by category, and routing rules reference them with the geosite: prefix, for example geosite:cn. Available categories and their domains depend on the loaded data file and its version. If a connection provides only a destination IP, another mechanism may be needed to identify the domain before domain-based rules can apply.
outboundTag · Outbound reference name
An outbound tag identifies an outbound configuration and is referenced by routing rules through outboundTag. proxy, direct and block are common naming conventions; the names themselves do not create proxy, direct or blocking behavior. Before copying a rule, confirm that the running configuration contains an outbound with the same name and purpose.
05 / Resolution and traffic entry
How DNS queries are sent and how app connections reach the core are separate paths that need to work together. After changing network modes, test name resolution and actual connectivity separately.
Domain Name System · Domain resolution
DNS resolves domain names to IP addresses and other records. The proxy core, operating system and apps may each have their own resolution path. Changing the core's DNS settings may not affect every app's queries, and a resolver address alone does not show which outbound handles requests. Check who sends the query, how it is sent and how the result is used for routing.
Registering a local proxy endpoint with the system
The system proxy registers a local proxy address and port with the operating system for apps that honor the setting. It does not capture every network connection, and some apps require HTTP or SOCKS proxy settings of their own. If the client closes but leaves a stale system proxy address behind, apps may keep trying to connect to it and become unreachable.
Virtual network interface · Capturing IP traffic
TUN mode captures IP traffic through a virtual network interface and can cover apps that ignore system proxy settings. Actual coverage depends on permissions, system routes, exclusions and other network tools; it does not mean all traffic uses the same proxy outbound. Coordinate DNS after enabling TUN, and preserve the correct route for connections to the proxy server to avoid routing loops.
Synthetic IP · Domain mapping
FakeDNS returns synthetic IP addresses and maps them to their original domains so later processing can recover domain information. These addresses do not belong to real servers; subsequent connections must pass through a processing chain that recognizes the mapping. When enabling or disabling FakeDNS, check that the address pool, system routes and app DNS caches are in sync to prevent stale addresses from causing connection problems.
Queries bypassing the intended resolution path
A DNS leak occurs when domain lookups do not follow the intended path—for example, when queries are expected to use a specific outbound but are handled by another system resolver. Troubleshooting means distinguishing system queries, browser-specific DNS, the core's DNS outbound and TUN coverage. The resolver shown by a single test page is only a clue; verify it against local settings and request logs.
Sniffing · Identifying initial connection data
Traffic sniffing identifies protocol or domain clues in the initial connection data, such as some HTTP headers and TLS handshake details, to provide additional routing information. It cannot arbitrarily decrypt app traffic, and not every connection reveals a recognizable domain. Whether the destination address is rewritten depends on the relevant options; enabling sniffing is not a substitute for DNS configuration.
If your settings look right but connections still fail, see Troubleshooting. For setup and connection steps, see the client setup guide.