Configuration Reference / 24 Common Terms
First distinguish how traffic enters the client, which outbound the rules select, and how the core connects to the server. Then check the settings. Similar menu labels do not necessarily refer to the same layer.
Traffic capture → Route selection → Outbound connection. System proxy and TUN determine how traffic enters the client. Routing rules choose direct, proxy or block; protocols such as VMess and VLESS define how a proxy connection is established. DNS provides address information for connections and rule matching, while the client organizes these settings and runs the core.
This page explains concepts; it does not replace server-side configuration details. For hands-on setup, see the getting started guide. If you already have an error, use the troubleshooting guide to diagnose it by symptom.
01 / Connection Settings
Protocol, transport and transport security are separate layers. After importing a configuration, keep the server-provided combination intact; changing only the protocol name is unlikely to make it work.
A proxy protocol in the Project V ecosystem that uses a user ID for authentication. A connection also involves protocol-specific security settings. VMess can use different transports; a node’s WebSocket path and TLS settings are not part of the protocol name. If a connection fails, check the system clock and settings on both ends. A reachable server address alone does not prove the configuration is correct.
A lightweight proxy protocol that does not encrypt transport traffic itself; deployments commonly pair it with TLS or REALITY for transport security. The user ID, transport, security settings and any flow parameter must match the server. Being able to import a VLESS link does not mean the current core supports every extension it uses.
A proxy protocol that typically protects connections with TLS and authenticates with a password. Check the password, port, server name and certificate verification settings separately; a failed TLS handshake does not necessarily mean the password is wrong. Trojan can also use specific transports, but the server-provided configuration is authoritative.
A transport security mechanism in the Xray ecosystem, not a standalone protocol on the same level as VMess or VLESS. The client usually needs a compatible core and matching settings, including the public key, server name and short ID. Check each setting when troubleshooting; disabling certificate verification is not a general fix for a REALITY misconfiguration.
02 / Software Layers
The client manages settings; the core runs them. If you see an unsupported protocol or unrecognized field error, first confirm which core is actually running.
A network proxy tool and related project names in the Project V ecosystem, organized around components such as inbounds, outbounds, routing and DNS. In everyday searches, “V2Ray client” often means a graphical app for managing related settings; it does not mean every app uses the same core. When discussing compatibility, include both the client and core names.
A community and core project maintained around V2Ray, and a common name in the Project V ecosystem. Check the actual core version for supported protocols, transports and configuration fields; examples for another core may not apply. On Android, v2flyNG is a graphical client option that uses the V2Fly core.
A proxy core derived from V2Ray-related code, with support for features such as VLESS and REALITY. It runs connection, routing and DNS settings. v2rayNG uses the Xray core, but the client interface and core are separate layers. If the core fails to start, check the startup log for invalid fields or port conflicts instead of repeatedly refreshing the subscription.
An app that provides subscription groups, server selection, configuration and system integration, such as desktop v2rayN and Android clients v2rayNG and v2flyNG. The client translates interface options into settings the core can run; some features may also rely on helper components. A menu option does not guarantee that every core and operating system can run it the same way.
Compare three clients →03 / Configuration Sources & Tests
Subscriptions deliver configurations; tests measure connections. Successful import, server reachability and normal browsing are three separate outcomes to verify.
A set of server configurations that a client retrieves from a subscription URL, usually stored in a subscription group. Refreshing it fetches the latest remote content. A successful refresh only means the content was retrieved and parsed; it does not guarantee that every profile can connect. Subscription URLs may contain access credentials, so hide the full URL before sharing logs or screenshots. Check whether refreshing will overwrite manual changes.
See how to import a subscription →A common term for a server connection profile in a client, typically containing an address, port, protocol, authentication details and transport security settings. The display name is only a label; it does not confirm the server’s physical location, exit region or connection quality. After selecting a server, app traffic still needs to enter the client and match the right outbound. Selecting a row alone does not do that.
Estimates connection time by opening a TCP connection to a specified address and port, mainly showing whether the target port is reachable on the current network. It does not verify full proxy protocol authentication or prove that the remote exit can reach a test website. If TCPing succeeds but a page will not load, check the handshake, routing and DNS; an open port does not mean the full connection works.
The client sends a request to a test address through the proxy and records the time according to its own implementation. This usually reflects the real browsing path more closely than a simple port test. Results depend on the test endpoint, DNS, handshake and connection reuse, so avoid direct comparisons across clients or test addresses. It is not a download speed test; check sustained browsing stability when choosing a profile.
Understand latency vs. download speed tests →04 / Outbound Selection
Rules determine where each connection goes. When reviewing them, consider the match conditions, rule order and outbound tag together.
A rule that selects an outbound based on conditions such as domain, destination IP, port or inbound. Rules are usually evaluated from top to bottom. A broad rule near the top can prevent more specific rules below it from matching. In a configuration, outboundTag references a defined outbound tag. Whether the tag is named direct or something else does not determine what it does; the outbound configuration does.
A policy that sends different connections to direct, proxy or block outbounds according to rules; it is not an additional proxy protocol. Accurate routing depends on rule order, available destination information and DNS strategy, not just the selected server. If a website uses the wrong outbound, first check whether the rule sees a domain or an IP, then identify the rule that matched.
See how to configure routing →A collection of IP addresses grouped by region or another category, commonly used for matching destinations, for example geoip:cn. Matching uses address ranges in the data file; it does not identify the company behind a domain or guarantee the server’s exact physical location. For IP-based rules, confirm that the destination IP is available and the relevant data file is accessible.
A collection of domains organized by category, commonly referenced with syntax such as geosite:cn for domain-based routing. Available tags and the domains they contain depend on the data file in use, not the client menu name. If an app provides only an IP and the domain cannot be recovered, a domain list alone may not match the intended rule.
05 / Domains & Destination Detection
When a page loads, domain resolution and the content connection may take different routes. To diagnose an issue, first identify which component performs the lookup and where the query goes.
A system that resolves domain names to IP addresses and other records. Common A and AAAA records provide IPv4 and IPv6 addresses, respectively. Apps, the operating system and the proxy core may each perform their own lookups, so changing the core’s DNS settings may not affect an app’s built-in encrypted DNS. If a domain fails but an existing IP connection works, check the resolution result, query path and cache before switching protocols.
A mechanism that assigns synthetic addresses to domains and uses a mapping to recover the destination domain when connections reach the core. The returned address is not the real server IP. This can preserve domain information, but it must work with compatible traffic capture and core settings. After enabling or disabling it, an app may temporarily misbehave if it still caches an old synthetic address; check that the cache and mapping match.
When DNS queries use a different channel from the one specified by policy, such as a query going through the system resolver when it should use a designated outbound. Whether this is a problem depends on the intended policy; lookups deliberately kept on the local network are not automatically leaks. Check system DNS, app-level encrypted DNS, IPv6 and TUN DNS capture settings together.
Attempts to identify details such as the destination domain from the initial connection data, providing more information for routing. The menu may use the English label Sniffing. This does not decrypt traffic; identification depends on the protocol and connection method. Whether the detected domain affects routing or the destination address depends on the core’s settings, so do not infer behavior from the feature simply being enabled.
06 / Traffic Entry & Presets
“System proxy” describes how apps connect to the client; “global proxy” usually describes a routing policy; TUN is a way to capture traffic. They operate at different layers.
Uses the operating system’s proxy settings to direct apps that honor them to the client’s local listening port. Some apps use their own proxy settings or connect directly, so enabling system proxy does not cover every app. If the network stops working after the client exits, check whether the system still points to a proxy port that is no longer listening, then use the client to clear the system proxy setting.
Usually a routing policy that sends all traffic already handled by the client to a proxy outbound; whether local network exceptions remain depends on the client. It cannot automatically capture apps that ignore system proxy settings, so “global” does not mean every connection on the operating system is covered. After switching modes, check app connectivity and outbound selection separately rather than treating them as the same issue.
Receives IP packets through a virtual network interface and passes them to the proxy, making it suitable when more app connections need to be captured. Actual coverage depends on permissions, system routes, DNS and exclusion rules; conflicts with other virtual network interfaces are also possible. When setting it up for the first time, confirm that a regular proxy connection works before enabling TUN. This helps distinguish server issues from traffic capture issues.
See how to enable TUN →A common client routing preset that typically sends connections matching mainland China domains or IP ranges directly, with other connections handled by subsequent rules. It does not identify website ownership in real time; results depend on rule data, DNS and custom rules. Presets with the same name may include different exceptions across clients. Expand the rules to compare behavior instead of relying on the menu label.