V2Ray Glossary: Protocols, Cores, Subscriptions & Routing

Connection Settings

Protocols & Transport

Protocols, transport methods, and security layers are separate dimensions. Nodes with the same protocol can still use different transport and security settings.

VMess: VMess is a proxy protocol in the Project V ecosystem with authentication and data protection mechanisms. Common settings include a user ID, server address, and port. It can use different underlying transports, so the protocol name alone does not tell you which transport settings to enter. If a connection fails, check both ends' settings and the system time rather than replacing authentication details at random.

VLESS: VLESS is a lightweight proxy protocol that does not encrypt payloads on its own and is usually paired with a security layer such as TLS or REALITY. The user ID, transport, security layer, and flow-control settings must match the server, and not every setting applies to every combination. When you see VLESS, check the exact combination and core support; simply renaming a VMess configuration will not make it work.

Trojan: Trojan typically establishes a secure connection through TLS and authenticates with a password; here, the name refers to the proxy protocol. Along with the address and port, check the password, server name, and certificate settings. If you see a certificate error, first check the system time, server name, and server configuration. Disabling certificate verification is not a routine fix.

REALITY: REALITY is a transport security mechanism in the Xray ecosystem, not a standalone proxy protocol on the same level as VLESS; the two are commonly used together. Enter the applicable server name, public key, short ID, and other parameters provided by the server. Field names can vary between client versions. If fields are missing after import, first check client and core support rather than substituting settings from another security layer.

How the Components Work

Cores & Ecosystem

The interface manages configuration; the core handles connections. Identifying which layer has the problem is more useful than reinstalling repeatedly.

Project V: Project V refers to the proxy-tool ecosystem represented by V2Ray, with configurations commonly organized around inbounds, routing, and outbounds. Inbounds receive app traffic, routing decides how to handle it, and outbounds provide direct, proxied, or other connections. Understanding this flow helps you place listener ports, routing rules, and server settings in the right context.

V2Fly: V2Fly is a community project that continues V2Ray development. Its core handles protocol implementations, connections, DNS, and routing. v2flyNG is one Android GUI client built around this core ecosystem; the client name and core name are not interchangeable. To check whether a feature is available, verify both core support and whether the client exposes the relevant setting.

Xray: Xray is a proxy core derived from the V2Ray project, with its own development roadmap. v2rayNG uses the Xray core. The two cores share some configuration concepts, but support for specific protocol features, security layers, and fields is not identical. Check each setting when migrating a configuration; related ecosystems do not guarantee drop-in compatibility.

Clients and Cores: A client is the GUI application used to manage subscriptions, edit settings, and control startup; the core actually handles traffic and protocols. v2rayN, v2rayNG, and v2flyNG are client names. Core updates and interface updates may fix different problems. When troubleshooting, check the logs: an open interface does not mean the core started successfully, and a running core does not mean apps are using the proxy.

Traffic Entry

Client Features

First check whether app traffic reaches the client, then see which outbound it uses.

System Proxy: System proxy registers a local proxy address with the operating system. Usually, only apps that read these settings will use it. In v2rayN, enabling automatic system proxy configuration still requires the core to be listening on the local port; the setting alone does not establish a connection. Some apps have their own proxy settings, so access in a browser does not prove that every app is using the proxy.

TUN Mode: TUN mode uses a virtual network interface to receive traffic and can handle apps that ignore system proxy settings. Its actual coverage depends on system routing and the client implementation. It may require additional permissions, and DNS, routing, and other networking software must work together. Verify a regular proxy connection first, then troubleshoot TUN separately to avoid multiple traffic-capture tools changing the network path at once.

Local Mixed Listener: A mixed listener accepts both HTTP proxy and SOCKS requests on the same local port, which apps can use according to the proxy type they support. This is the local entry port, not the remote server port; they serve different purposes. If the listener is bound only to the loopback address, other devices cannot access it. Before allowing LAN access, consider firewall rules and access controls.

Multiple Core Support: Multiple core support lets a client use different proxy cores according to its configuration. Available options depend on the client version and installed components. Switching cores changes support for protocols, security layers, and routing features; it is more than changing a display name. If a configuration is unsupported, check which features it requires, choose a compatible core, then review the startup logs and test the connection.

Configuration Sources

Subscriptions & Nodes

A successful import only means the configuration was read. To find a working connection, check the settings, test destination, and current network.

Subscription: A subscription is a link or data source for fetching server configurations in bulk. The client reads it and converts the contents into manageable nodes. Updating a subscription fetches the configuration again; it does not renew access, fix nodes, or guarantee a working connection. Subscription URLs may contain personal access credentials, so do not share them publicly. If parsing fails, check that the URL is valid, the returned format is supported, and the update request completes.

Proxy Node: A node is a common term for a set of remote server connection settings, typically including the address, port, protocol, authentication, and transport. Its display name is only a label for management; it does not reliably indicate the actual exit location, bandwidth, or stability. After importing, test the connection and confirm the selected node matches the outbound in use.

Subscription Group: Subscription groups organize configurations by source or purpose, making nodes easier to update, filter, and manage separately. They do not inherently provide load balancing or failover; the client must support and be configured for those features. Keep manually added configurations separate from auto-updating subscriptions to avoid duplicates or unexpected changes during updates.

Real Connection Latency: Real connection latency usually means the time taken to request a test destination through the selected proxy, which is more representative of an actual visit than a simple port check. Test methods vary by client, and results depend on the target, connection setup, and current network conditions. To compare nodes, use the same target and test more than once. A lower result in one test does not mean faster sustained downloads.

Choosing an Outbound

Routing & Proxy Rules

Rules need matching criteria and an available outbound. Rule names, data versions, and ordering can all affect the result.

Routing Rule: Routing rules select an outbound for a connection based on conditions such as domain, IP address, port, or protocol. Many cores check rules in order and use the first match, so a broad rule can override more specific rules below it. After making changes, confirm the outbound tag exists and check the logs to see which rule actually matched; saving a rule does not prove it is working.

GeoIP: GeoIP is a collection of IP address ranges organized by region or purpose; rules can use a tag to reference a set of addresses. It is used for IP matching, not real-time measurement of a server's physical location, and address assignments can change as networks evolve. Before using it, check that the current data file contains the target tag. If the destination IP has not been resolved yet, DNS strategy may also affect matching.

GeoSite: GeoSite is a collection of domains organized by site, service, or category, useful for building rules based on domain names. Categories and included domains depend on the data file, so different sources are not necessarily identical. If the core receives only the destination IP and has no usable domain name, domain rules may not match as expected. Check the DNS path or applicable domain-detection settings.

Rule-Based Routing and Global Proxy: Rule-based routing sends connections to different outbounds according to conditions—for example, direct connections for LAN addresses and proxy connections for specified domains. Global proxy usually means sending all traffic within its scope through a proxy, though the exact meaning depends on the client settings. It does not guarantee that every app's traffic reaches the client; distinguish traffic capture scope from routing decisions made after traffic arrives.

DNS & Performance

Networking Basics

Web access involves several steps, including name resolution, connection setup, and data transfer. A single test result reflects only part of the process.

DNS: DNS, the Domain Name System, commonly resolves domain names to IP addresses that can be reached. Queries may come from the operating system, an app, or the proxy core. Where a name is resolved and which resolver is used can affect the result and subsequent routing decisions. If a domain will not load, check name resolution and the destination connection separately rather than attributing both failures to a bad node.

FakeDNS: FakeDNS first returns a mapped address to the app; the proxy core then recovers the original domain when handling the connection, helping preserve domain information. The mapped address is not the real address of the destination service, and this only works when DNS queries and subsequent traffic follow a compatible processing path. After disabling the feature or changing modes, old mappings may remain in the app cache. Restart the app and clear relevant caches if needed.

DNS Leak: A DNS leak occurs when queries do not follow the intended resolution path and are handled by the operating system, browser, or another resolver. Whether that counts as a leak depends on the DNS policy you set; resolving a domain directly according to your rules is not necessarily a configuration error. Check browser Secure DNS, system resolver settings, and the client's DNS policy together. The exit IP alone does not reveal the query path.

Latency and Bandwidth: Latency measures communication wait time; bandwidth measures how much data can be transferred per unit of time. They describe different things. The time it takes a webpage to open can also depend on DNS, connection handshakes, server response, and packet loss, so low latency does not guarantee faster downloads. For a fair comparison, test repeatedly under similar network conditions and use the same destination.