REFERENCE / TERMINOLOGY
Browse protocols, cores, subscriptions, routing, and client settings by category. Each entry explains the term, related configuration, and usage limits. Use an entry's anchor link to save or share it.
PROTOCOL / TRANSPORT
Proxy protocols define connection semantics, transports carry data, and security layers protect connections. Seeing these options together in a node editor does not mean they belong to the same layer.
A proxy protocol in the V2Ray ecosystem that provides authentication and data protection. The common protocol value in configuration is vmess. The user ID, server address, port, and transport settings must match the server; a correct address alone is not enough to connect. If authentication fails, check the settings and make sure the device clock is accurate. Do not apply legacy fields from old guides to current configurations without checking them.
A lightweight proxy protocol that does not encrypt data on its own and is typically used with a security layer such as TLS or REALITY. It is configured separately from the transport carrying the connection, so “VLESS node” alone does not tell you how the full connection is set up. After importing, check the security layer, server name, flow control, and other parameters. The supported fields depend on the selected core and server configuration.
A proxy protocol that typically runs over TLS and uses a password for authentication. The password, server name, and transport parameters in the client must match the server. The server address may differ from the name on its certificate. If a handshake fails, check the name, device clock, and certificate trust chain rather than hiding a configuration error by disabling certificate verification.
A proxy protocol that establishes connections using parameters such as an encryption method and password. Common configuration fields include method and password. Key requirements and core support vary by encryption method, so not every password can be paired with every method. If an imported link reports an unsupported method, first check core capabilities and the supplied parameters before deciding whether to use a different profile.
A transport security mechanism in the Xray ecosystem, not a standalone node protocol; a node typically also needs a proxy protocol such as VLESS. Check the server name, public key, short ID, and other parameters, noting that client labels may differ from the underlying field names. A REALITY option does not mean every core can run it. First confirm which core is actually in use and whether it supports the configuration.
CORE / ECOSYSTEM
Project names, executable programs, and graphical interfaces serve different purposes. When troubleshooting an error, first determine whether it came from the client interface or the core logs.
The name of the project ecosystem associated with V2Ray's origins, useful for understanding the background of this proxy technology—not a protocol value in a node configuration. The client interface, proxy protocol, and core that handles connections are distinct concepts. When reading documentation, check whether it covers V2Fly, Xray, or a particular client; the word “V2Ray” alone does not tell you which features are supported.
A community project continuing the V2Ray technology stack; its core is commonly called v2fly-core. v2flyNG is an Android client that uses this core. Check the actual core version for supported configuration formats and protocols; do not assume an example for another core is compatible. Before switching, review the protocol, security layer, and JSON structure, then check the startup logs afterward.
A proxy core developed from the V2Ray technology stack, with capabilities such as REALITY; v2rayNG uses the Xray core. Some basic settings are similar to V2Fly, but protocol extensions, fields, and behavior may differ, so full compatibility is not guaranteed. Choose a core based on the capabilities your node requires. For a detailed comparison, see Core Support Comparison.
The program that parses configuration, accepts inbound connections, applies routing rules, and establishes outbound connections, usually running behind a graphical client. The client window opening does not mean the core has started. A port conflict, unknown field, or missing rule data can prevent startup. Start troubleshooting with the first clear error in the core logs, then inspect the relevant configuration section. Avoid changing several unrelated settings at once.
An app with interfaces for managing subscriptions, selecting nodes, switching modes, and viewing logs, such as v2rayN, v2rayNG, and v2flyNG. Update intervals, window preferences, and subscription groups are usually saved by the client and may not appear in the core's config.json. For installation options, see the client page. When configuring, distinguish interface settings from the core fields they generate.
SUBSCRIPTION / PROFILE
A subscription is a source of configurations, a node is an individual connection profile, and a test result is an observation at a particular time. They are not interchangeable.
A URL or data source that lets a client retrieve a set of connection configurations, usually displayed as a node list after parsing. Updating a subscription fetches the latest source data, but does not guarantee that every node can connect; access may also fail while fetching the configurations. Subscription URLs may contain credentials, so do not expose them in public screenshots, logs, or shared text. Before updating, check whether your manual changes will be overwritten.
A common name for an individual connection profile in a client, usually containing an address, port, protocol, and authentication settings. Its display name is only a label; it does not prove the server's location or performance, or guarantee compatibility with the current core. If a connection fails, check each field instead of just renaming the profile. After selecting a node, make sure the client has applied it to the active configuration.
A client-side structure for organizing nodes by source or purpose, making them easier to update, filter, and select. It is not a standard field in V2Ray core JSON, and a group name is not a routing outbound tag. When using multiple subscriptions, check the active group before updating. For details, see v2rayN Subscription Groups and Node Filtering.
The time from starting a test operation to receiving a response; the result must be interpreted in light of the test method. TCP connection tests, protocol handshakes, and full requests use different procedures, so their results are not directly comparable or a measure of download speed. To compare nodes, use the same target and method, then consider performance over time. A single timeout only means that particular test did not finish within the deadline.
The time recorded after a client sends a request to a test address through the selected proxy profile. The exact timing boundaries depend on the client implementation. Results are affected by the test target, timeout, DNS resolution, and remote response, so this is not simply the network round-trip time. A successful test only shows that the target was reachable in that test; it does not mean every app or destination will work.
ROUTING / RESOLUTION
Domain rules, address rules, and DNS strategies can depend on each other. First check what information the core actually received, then investigate why a rule matched or did not.
Selecting an outbound based on conditions such as domain, destination address, port, or inbound tag. Rules are usually checked in order, and a match determines the handling path. The outboundTag in a rule must match a tag in outbounds; it references a name and does not create an outbound automatically. When checking split tunneling, verify the rule order, match conditions, and default behavior when nothing matches.
A rule data system for referencing sets of IP addresses. For example, geoip:private can match private address ranges. It matches address ranges, not application names; geographic tags also cannot guarantee an address's current physical location. Before using one, confirm that the rule data has loaded. Whether a domain connection is subsequently matched by address also depends on the core's DNS resolution strategy.
A rule data system for referencing sets of domains. For example, geosite:cn refers to a set named cn; it does not simply guess based on domain suffixes. Available tags depend on the data files loaded, and the contents can vary by data source. If a rule does not work, check that the tag exists, the target domain is included, and the connection still has its domain information.
A system that resolves domain names to records such as addresses. Resolution results affect connection destinations and some routing decisions. The operating system, browser, client, and core may each have separate DNS settings, so changing one does not necessarily update the others. When troubleshooting, note what initiated the query, which resolver received it, and whether it followed the expected outbound path; then check caching and address-family settings.
A mechanism that assigns synthetic addresses to domains and stores mappings, allowing later connections to recover the original domain for proxy forwarding and routing. Subsequent connections must enter a handling path that can recognize the mapping; the synthetic address is not the server's real address. Changing DNS without taking over the corresponding connections can break access, so confirm the client provides full support before enabling this feature.
A DNS query that bypasses the expected resolution path and is sent through another resolver; determine whether the actual path matches the intended one. Browser-specific DNS settings, operating system fallback behavior, and app-level resolution can all affect the result, so changing one DNS address is not enough to tell. Check query logs, browser settings, and client routing. Encrypted DNS does not automatically mean the query followed the expected path.
CLIENT / NETWORK ENTRY
The proxy mode determines how traffic enters the client. Similar mode names do not mean they cover the same connections, require the same permissions, or handle DNS the same way.
A mode that receives IP packets through a virtual network interface and passes them to a proxy component. It can cover some connections that do not follow the system proxy setting. Support depends on the client, forwarding components, and system permissions; TUN is not a universal JSON switch for every V2Ray core. If enabling it cuts off network access, check for routing conflicts, DNS dependencies, and other virtual network software, then restore settings one at a time to find the cause.
Registering a proxy address and port with the operating system, usually pointing to the client's local inbound, so apps that honor the setting use the proxy. It does not automatically handle every network connection on the device; some programs need separate settings or another way to connect. Before closing the client, make sure the system proxy has been restored. A browser still pointing to a local port that is no longer listening may be unable to connect.
A listening endpoint where the proxy core accepts app connections. Common types include HTTP and SOCKS, represented by inbounds in the configuration. The listen address, port, and authentication settings determine who can access it. A loopback address is usually available only on the local machine; wildcard listening requires additional access controls. The proxy type configured in an app must match the inbound type: an HTTP proxy port cannot be used as SOCKS just because both accept proxy connections.
A mechanism that extracts information such as domain names from protocol signatures at the start of a connection to help with routing. The common configuration name is sniffing. It does not decrypt all of an app's encrypted data, nor does it guarantee a domain can be extracted from every connection. After enabling it, distinguish between sniffing used only for routing and behavior that rewrites the destination. Check the core version and existing DNS setup before choosing options.
Allowing other devices on the same local network to access a proxy inbound on your computer requires checking the listen address, port, device connectivity, and firewall rules. Other devices must use the computer's LAN address, not a loopback address; network isolation may prevent devices on the same Wi-Fi from communicating. Share only on trusted networks and enable authentication when needed. For setup steps, see Allow LAN Connections.
Terms describe concepts; fields describe implementation. If an interface uses different labels or an example will not load, start by checking the configuration generated by the current client and the core logs. For common issues, see FAQ.
Back to glossary ↑