Configuration layers · Overview
Conceptual diagram, not a client interface.
V2Ray Glossary
Browse common terms across six categories. First identify which layer a setting belongs to, then match it to the relevant option in your client.
Protocols define how connections communicate, cores execute the configuration, and clients provide the management interface. Similar names do not mean the same function or interchangeable settings.
Read the user guide →Protocols & Transport
A protocol name is only one part of a configuration. The transport, authentication settings, and transport security must also match.
- Protocols & TransportVMess
- A proxy protocol in the Project V ecosystem that authenticates using settings such as a user ID and includes its own data protection. A working connection also depends on the transport and outer security settings, so the protocol name alone cannot confirm compatibility. If a connection fails after import, check the user ID, server time, and transport settings rather than just changing the node name.
- Protocols & TransportVLESS
- A lightweight proxy protocol that does not encrypt payloads by itself and is commonly paired with mechanisms such as TLS or REALITY. VLESS, the transport, and the security layer are separate settings; seeing VLESS does not tell you what the other settings should be. Keep the user ID, server name, and other required options consistent with the server.
- Protocols & TransportTrojan
- A proxy protocol that typically relies on TLS to protect connections and uses a password for authentication. The password, server name, and transport settings in the client must match the server; reaching the server port does not mean authentication succeeded. For certificate errors, check the server name and system clock instead of routinely disabling certificate verification.
- Protocols & TransportREALITY
- A transport security mechanism in the Xray ecosystem, often used in VLESS connection profiles. It is not a subscription format or a graphical client. The public key, server name, short ID, and other server-provided settings must match; exact fields depend on the client and core versions. If an option is unsupported, first check the core's capabilities instead of removing settings based only on the protocol name.
Cores & Ecosystem
V2Ray, V2Fly, Xray, and v2rayN belong to different layers. Distinguish project names, the core that runs the configuration, and the client application.
- Cores & EcosystemProject V
- A project ecosystem built around V2Ray and related networking tools, covering protocol implementations, traffic handling, and associated utilities. It is not the name of a particular desktop app or installer, and does not by itself indicate whether a feature is available. When choosing a client, check which core it uses and which settings that core supports.
- Cores & EcosystemV2Fly
- A community project that continues to maintain the V2Ray core and is part of the open-source proxy ecosystem. The Android client v2flyNG uses this core family, but the client interface and core capabilities are separate concepts. Check support for the specific version in use; do not assume settings from other forks will work unchanged.
- Cores & EcosystemXray
- A proxy core project based on V2Ray's codebase that has since developed independently, with its own protocol implementations and features. v2rayNG uses the Xray core, which is also needed for settings such as REALITY. Xray and V2Fly share technical roots, but their configuration details and supported features are not always identical.
- Cores & EcosystemCore
- The component that handles protocol connections, routing decisions, DNS, and related tasks. The graphical client edits settings, selects connections, and manages runtime status. Client updates and core updates may be separate, and a field in the interface does not guarantee the current core recognizes it. When troubleshooting, note the client name, core type, and full error message separately.
Read next: V2Ray cores explained and how to choose a client →
Subscriptions & Nodes
A subscription fetches and updates configurations; a node is an imported connection profile. Neither means a proxy connection is already active.
- Subscriptions & NodesSubscription
- A mechanism for retrieving a set of connection profiles from a URL and reloading them from that source when updated. The response may be encoded text, a collection of share links, or another format supported by the client, so opening the URL in a browser does not guarantee the client can import it. Subscription URLs may contain credentials; hide the full URL in screenshots, logs, and support requests.
- Subscriptions & NodesNode
- A selectable connection profile in a client, typically containing a server address, port, protocol, authentication, and transport settings. A node alias is mainly for identification: one server can have multiple profiles, and different aliases do not necessarily mean different devices. Selecting a node only chooses a profile; the core must also be running and app traffic must be routed to it.
- Subscriptions & NodesSubscription group
- A client-side unit for organizing subscription URLs and imported profiles by source, making it easier to manage different sources and update scopes. The group name is for organization; it does not change the protocol, proxy entry method, or routing outcome. Before editing a URL or deleting a group, check where its profiles came from. Manually edited subscription-generated nodes may be overwritten on the next update.
Subscription update failed? Check the URL, format, and network in order →
Routing & Split Tunneling
First confirm that app traffic reaches the client, then check how routing rules choose an exit. Traffic entry and routing settings are not interchangeable.
- Routing & Split TunnelingRouting rule
- A setting that directs connections to an exit based on conditions such as domain, destination IP, port, or protocol. Rules are commonly evaluated in order, so a broad rule earlier in the list can prevent a specific rule from matching. Unmatched traffic is also affected by the default route. If results differ from expectations, check rule order, available destination data, and the default action.
- Routing & Split TunnelingSplit tunneling
- Routing different traffic to exits such as direct, proxy, or block according to rules; it is not a standalone protocol. The system proxy controls how some apps connect, while split tunneling decides what happens after traffic reaches the client. Global proxy usually means selecting the proxy route more broadly; it does not automatically capture traffic from every app.
- Routing & Split TunnelingGeoIP
- Data and rule syntax for matching traffic against IP address ranges, which may be grouped by region or other criteria. IP ownership and service deployment can change, so a match is not definitive proof of a server's current location. When changing these rules, check the data file and tags actually loaded by the client, along with the domain resolution strategy.
- Routing & Split TunnelingGeoSite
- A data mechanism that groups domains by service, category, or other criteria for use in routing rules. Unlike GeoIP, it matches domains rather than IP addresses. Available tags and the domains they contain depend on the loaded data source. Rules based only on domain groups may not match when an app uses IP addresses directly or the client cannot identify the domain.
See how to choose a routing mode and configure split tunneling →
Client Settings
Option names may vary by platform and version. Understanding what a setting does matters more than copying another device's switch settings.
- Client SettingsSystem proxy
- A proxy configuration provided by the operating system, usually pointing to a proxy listener opened locally by the client. Only apps that honor this setting use it; apps may set their own proxy or ignore the system setting entirely. If the client exits but leaves the system proxy pointing to a closed port, affected apps may lose network access. Restore the relevant system setting if needed.
- Client SettingsTUN mode
- A traffic entry method that uses a virtual network interface to pass traffic to the proxy component, potentially covering apps that ignore the system proxy. It may require additional permissions and interact with system routes, DNS, or other virtual networking software. After enabling it, verify which traffic is actually captured. TUN being on does not guarantee a working connection or that all traffic uses the same route.
- Client SettingsLocal listening port
- The local port where the client accepts proxy requests from the system or apps; it is separate from the remote server port. When configuring an app manually, its address, port, and proxy type (such as HTTP or SOCKS) must match the listener. The listening address also determines who can connect, so do not expose it to other devices unless needed.
- Client SettingsTraffic sniffing
- Identifies protocols or destination domains from information visible early in a connection to help with routing and related tasks. It does not decrypt all app traffic or guarantee that a domain can be identified from every connection. Whether to enable it or allow destination overrides depends on the core configuration and routing goals; it is not a universal fix for connection problems.
Networking Basics
Successful DNS resolution, an accessible port, and a completed request are different outcomes. Interpret test results in light of the test target, resolution method, and traffic entry mode.
- Networking BasicsDNS
- A system that resolves domain names into IP addresses and other records, usually before an app connects. System DNS, a client's built-in DNS, and encrypted DNS used by an app may follow different paths, so changing one does not necessarily affect the others. To troubleshoot, identify who makes the request, which resolver handles it, and how the result affects subsequent routing.
- Networking BasicsFakeDNS
- A DNS mechanism that returns virtual addresses to apps while keeping an internal mapping between those addresses and the original domains. When traffic re-enters the client, the mapping can restore the domain instead of treating the virtual address as a real server address. DNS resolution, traffic capture, and mapping recovery must work together; stale caches or incomplete capture can cause connection issues.
- Networking BasicsDNS leak
- When DNS requests that should follow the intended resolution path are sent to a different resolver. Whether this counts as a leak depends on the expected policy; resolving some domains locally by rule is not necessarily a configuration error. Check DNS settings in the operating system, browser, client, and other apps rather than drawing conclusions from a single IP test.
- Networking BasicsReal connection latency
- The time measured when accessing a test target through the selected proxy; the stages included depend on the client's test implementation. It is closer to a real request than Tcping, which only checks a TCP connection, but is still affected by the test address, DNS, and target response. Low latency does not mean high download throughput, and a successful test does not guarantee that every site or app will work.