Configuration concepts

V2Ray Glossary

Learn what subscriptions, protocols, cores, traffic routing, and DNS mean. Find terms by setup scenario, then check the corresponding client options.

Each term has its own anchor, so you can copy its URL to point to a specific explanation. For a first-time setup, start with the subscription import and connection guide. If you already know the symptoms, Troubleshooting provides a more focused checklist.

01 / Connection settings

Protocols and transports

Protocols, transports, and security layers are separate settings. Knowing the protocol name does not mean the other parameters can be omitted or changed at will.

VMess: Protocols and transportsA proxy protocol in the Project V ecosystem that uses a user ID for authentication and can be paired with different transports. Some authentication steps rely on system time, so a significantly incorrect device clock can prevent connections. Preserve the original transport and security settings after importing; VMess is a protocol, not a transport like WebSocket.

VLESS: Protocols and transportsA lightweight proxy protocol that does not encrypt data in typical configurations and is usually paired with a security layer such as TLS or REALITY. A working connection may also require transport and flow-control settings, so an address and user ID alone may not be enough. If a configuration imports but cannot connect, check that the core supports the entire configuration, not just the protocol name.

Trojan: Protocols and transportsA proxy protocol that typically runs over a TLS connection and uses a password for authentication. A correct password alone is not enough: the server name, certificate validation, and transport settings must also match the server. For certificate errors, check the device clock and server configuration rather than permanently skipping certificate validation.

REALITY: Protocols and transportsA transport security mechanism in the Xray ecosystem, not a standalone node protocol. It is commonly used with VLESS. Import all required fields, such as the public key, server name, and short ID, exactly as provided by the server. Changing only the security layer to REALITY does not add support for it to an existing configuration.

02 / How the components work

Cores and clients

The GUI is for managing settings; the core executes them. A field appearing in the interface does not mean the running core supports it.

v2rayN: Cores and clientsA desktop GUI client for Windows, macOS, and Linux that manages subscriptions, connection settings, routing, and core processes. It turns interface settings into a configuration the core can run; supported protocols depend on the selected core and its version. When troubleshooting, note the client version, active core, and specific error separately rather than treating them as the same thing.

v2rayNG: Cores and clientsAn Android GUI client that uses the Xray core for proxy connections and commonly routes app traffic through the system VPN service. A connection indicator means the traffic-capture service is running, not that the remote node is reachable. On first use, confirm system permissions. If the connection drops, check background restrictions, app routing, and network changes.

Xray: Cores and clientsThe core handles proxy connections, protocols, routing, and DNS; it is separate from the GUI client that displays the menus. Changing cores may affect supported protocols, configuration fields, and logs, so do not choose one by name alone. After updating the client, confirm the version of the core actually launched and check that it still supports your configuration.

V2Fly: Cores and clientsA community project in the Project V ecosystem that maintains the V2Ray core and related components; the project name is not the same as a client name. v2flyNG is an Android client option that uses this core and may support different configurations from clients using Xray. When switching, check protocol and transport support individually rather than assuming all configurations are interchangeable.

03 / Configuration sources and testing

Subscriptions and nodes

A subscription fetches configurations, a node is a specific set of connection settings, and a test result reflects performance under a particular test method.

Subscription: Subscriptions and nodesA URL for fetching and updating connection configurations in bulk; it is not a node and does not grant access to a service by itself. After adding and saving the URL, you usually need to select “Update all subscriptions” to fetch the configuration list. Treat URLs containing access credentials as sensitive information, and remove the full URL before sharing logs or screenshots.

Node: Subscriptions and nodesA common name for a set of remote connection settings in a client, usually including the server address, port, protocol, authentication, and transport. The name shown in the list is just a label and cannot confirm a node's location, availability, or performance. Selecting a node chooses an outbound configuration; whether an app uses it also depends on traffic capture and routing rules.

Latency: Subscriptions and nodesThe time taken to complete a probe, interpreted in light of the test method: a TCP connection test, an HTTP request, and other probes measure different things. Results also depend on the test target, current network, and connection reuse. Low latency does not mean high download speeds. For a useful node comparison, keep the test method, target, and timing consistent.

Real connection latency: Subscriptions and nodesThe time taken to send a request through a proxy connection to a specified test URL. It is usually closer to real-world access than a basic port check, but results still depend on the test site, DNS, routing, and the core's test implementation. If a test fails, check whether the test URL is reachable before assuming the node is down.

04 / Choosing an outbound route

Routing and traffic rules

Traffic must enter the core before rules can choose an outbound route. Before changing a rule, identify the destination, match conditions, and intended action.

Routing rule: Routing and traffic rulesA rule that selects an outbound route—such as proxy, direct, or block—based on conditions like domain, IP, port, or protocol. Rules are usually evaluated in order; a broad match near the top can prevent a more specific rule from taking effect. To understand what happens to unmatched traffic, check the default route and client-generated configuration, not just individual rules.

Traffic routing: Routing and traffic rulesA policy for sending different traffic over different routes, commonly implemented with routing rules—for example, sending local network addresses direct and specified services through a proxy. It determines how captured traffic is handled; it does not automatically capture apps that are not using the client endpoint. To verify the rules, test destinations expected to go direct and through the proxy separately.

GeoIP: Routing and traffic rulesA set of IP addresses used for routing matches; the labels and ranges are defined by the rule data. The common label geoip:private matches private and other non-public address ranges, and can be paired with a direct route for local network access. GeoIP matches address ranges, not website content, and does not replace domain rules.

GeoSite: Routing and traffic rulesA collection of domains grouped by site or category for bulk matching in routing rules, reducing the need to maintain entries individually. Available labels and domains depend on the rule data in use; labels from another source may not work. Domain matching also requires the core to know the domain, so a destination IP alone may not match the expected rule.

05 / Domain resolution

DNS and networking

A domain usually needs to be resolved before a connection can reach its destination. The system, browser, and proxy core may use different DNS paths, so check them separately.

DNS: DNS and networkingA system that resolves domain names to IP addresses and other records so apps can locate their destinations. Queries may come from the operating system, browser, or proxy core, so changing one DNS setting may not affect every app. If a remote connection works but domains do not resolve, check the resolver, query route, and cache separately before switching nodes.

Remote DNS: DNS and networkingA DNS service configured in the client for a specific resolution path. It may be entered as a standard address or an encrypted DNS address. “Remote” does not guarantee that queries go through the proxy; the actual route depends on the core, DNS routing, and related settings. After changing it, verify that the resolver is reachable and check for dependencies during startup resolution.

FakeDNS: DNS and networkingA mechanism that returns virtual IPs to apps and maintains virtual address-to-domain mappings in the core, helping preserve domain information for later connections. It requires DNS interception, mapping, and traffic capture to work together; it is not a regular public DNS address. If apps keep using old addresses after enabling or disabling it, check the cache and connection state for stale mappings.

DNS leak: DNS and networkingA situation where DNS requests do not follow the expected resolution policy—for example, queries expected to go through a proxy are instead sent along a different system path. First clarify the expected behavior, then check browser Secure DNS, system resolution, and core DNS settings. Online tests are clues, not proof of where all traffic is routed; a resolver name alone cannot tell the whole story.

06 / Routing traffic into the core

System proxy and TUN

The proxy endpoint determines how an app connects to the client; the remote node determines how the client connects to the server. Their addresses and ports are not interchangeable.

System proxy: System proxy and TUNA proxy endpoint provided by the operating system to apps that honor the setting; it does not automatically cover every program. “Set system proxy” applies the relevant settings, “Clear system proxy” removes them, and “Do not change system proxy” leaves the current settings untouched. Terminal tools and apps with their own network settings may need separate configuration, so a working browser does not mean other programs are using the proxy.

TUN mode: System proxy and TUNA way to route traffic into the proxy core through a virtual network interface, usually covering more apps that do not honor system proxy settings. Desktop use may require administrator privileges and depends on routing and DNS settings; enabling TUN does not guarantee that all traffic uses the remote proxy. If other virtual networking software is running, check for interface, route, and DNS conflicts.

HTTP proxy: System proxy and TUNA way for an app to send requests through an HTTP proxy endpoint. HTTPS connections typically use CONNECT to establish a tunnel. Read the local endpoint address and port from the client settings; do not enter the remote server details from a subscription. For local use, prefer a loopback address. Before allowing other devices to connect, define the access scope and firewall rules.

SOCKS proxy: System proxy and TUNA common application-layer proxy endpoint. SOCKS5 can pass a destination domain or IP, and some implementations also support UDP. Whether the app asks the proxy to resolve domains depends on its implementation and settings, so using SOCKS alone does not reveal the DNS path. Check the port the client is actually listening on, and make sure it is not the HTTP proxy port.