Look up terms by layer, from protocols and cores to routing and DNS. Each entry has a direct anchor for checking menus in v2rayN, v2rayNG, and v2flyNG.
Protocols define connection behavior; transport and security settings determine how data is carried and protected.
Protocols and Transport
A proxy protocol in the Project V ecosystem that authenticates connections using parameters such as a user ID. Protocol, transport, and TLS are separate layers; after importing a configuration, check that each setting matches the server. If authentication fails, also check that the device clock is accurate rather than repeatedly switching routing modes.
Protocols and Transport
A lightweight proxy protocol that does not encrypt payloads on its own and is typically used with security mechanisms such as TLS or REALITY. Set the user ID, transport, and fields such as flow to match the server configuration. Two VLESS configurations can use different security mechanisms, so their parameters are not necessarily interchangeable.
Protocols and Transport
A proxy protocol that typically uses TLS to secure connections and password-based authentication. Configure the correct server address, port, password, and TLS settings, and keep certificate verification enabled. The server address and TLS server name serve different purposes; if certificate validation fails, check that the names match.
Protocols and Transport
A transport security mechanism in the Xray ecosystem, commonly used with VLESS. The public key, shortId, serverName, and other parameters must match the server requirements; the server address alone is not enough to reconstruct a complete configuration. Preserve all fields provided by the subscription and confirm that the client core supports the combination.
The client provides the settings interface; the core handles connections and rules. Feature support depends on the version in use.
Cores and Ecosystem
A project and technology ecosystem built around modular network proxy tools. GUI clients let you edit settings, while cores handle connections; they are different layers. When following a V2Ray guide, first check whether it covers a protocol, core configuration, or a particular client's menus.
Cores and Ecosystem
A proxy core with shared technical roots with V2Ray, supporting configurations such as VLESS and REALITY. v2rayNG uses the Xray core; available features also depend on the core version bundled with the client. In v2rayN, check the “Core Type” against the server protocol in use; don't switch cores just because the names differ.
Cores and Ecosystem
The community and core implementation continuing the development of the V2Ray project, commonly known as V2Fly Core. v2flyNG follows this core lineage; supported fields and protocols depend on the version in use. Examples for other cores may not work as-is, so check transport security fields and routing configuration syntax carefully.
Cores and Ecosystem
An interface for managing subscriptions, editing server settings, and controlling the core. v2rayN runs on Windows, macOS, and Linux; v2rayNG and v2flyNG run on Android. Their menus and configuration storage differ. When moving between platforms, use a subscription or share format supported by both clients instead of copying the entire app configuration folder.
Keep configuration sources, server entries, and test results distinct. A successful import does not guarantee a working connection.
Subscriptions and Servers
A link or configuration source used to fetch and update server settings in bulk. Subscription content may contain credentials. A successful update means the content was retrieved and parsed, not that the connection will work. After saving the link under “Subscription Groups” or “Subscription Group Settings,” run an update and check for filters.
Subscriptions and Servers
A common client term for a set of connection parameters for a remote server, typically including its address, port, protocol, and authentication details. The entry name is just a label; it says nothing about connection quality or protocol compatibility. Edits to subscription-generated entries may be overwritten on the next update, so create a separate entry if you need to keep your changes.
Subscriptions and Servers
A client feature for managing server entries from different configuration sources separately. In v2rayN, “Subscription Groups” help distinguish sources and update scope; a group is not a routing policy. If the list suddenly goes empty, check the selected group, server filters, and update results before assuming the subscription has expired.
Subscriptions and Servers
The time measured when the client reaches a test target through the proxy route; the exact measurement depends on the implementation. This differs from testing the server port directly and does not, by itself, indicate throughput or the experience across all websites. If a test fails, check the logs and whether the test target is reachable; it does not necessarily mean all app connections will fail.
Routing determines which outbound handles a connection; rule data provides domain and IP match sets.
Routing and Traffic Rules
A rule that directs a connection to a specified outbound based on conditions such as domain, IP, port, or inbound. Many cores process rules in order, so check whether an earlier, broader rule overrides a more specific one. After changing “Routing Settings,” make sure the edited routing configuration is the one currently enabled.
Routing and Traffic Rules
A configuration that sends connections to different destinations through direct, proxy, or blocked outbounds. It relies on routing rules and available domain or IP information; enabling the system proxy alone is not enough. After choosing a preset such as “Bypass mainland China,” check the rule data and DNS strategy to confirm what the rules actually match.
Routing and Traffic Rules
Rule data for matching IP addresses against address ranges, commonly written as geoip:cn. Results depend on the data version and the destination IP; the label is not a precise, real-time location lookup. For destinations using a content delivery network, resolved addresses can change, so the IP rule result for the same domain may vary.
Routing and Traffic Rules
Rule data that groups domains by category, commonly written as geosite:cn. Matching usually requires the destination domain and the relevant category to be present in the current rule data. The interface text “geosite:cn → direct” describes routing a domain set to a direct outbound; it is not a complete JSON rule you can paste as-is.
First identify which resolver handles queries and which route they take; then adjust the domain strategy or FakeDNS.
DNS and Networking
A system that resolves domain names to IP addresses and other records. Client DNS, system DNS, and app-specific resolvers may all be in use, so changing one does not necessarily affect every query. After changing a setting such as “Enable Local DNS” in v2rayNG, reconnect and check whether the app is still using cached results.
DNS and Networking
A routing domain strategy that resolves a domain to an IP and retries rule matching if the domain does not match any rule. It determines when routing needs an IP address; it is not a DNS server address and does not specify the query's outbound. When changing this option in “Routing Settings,” also check whether any rules require IP information.
DNS and Networking
A mechanism that answers domain queries with synthetic addresses and maintains a mapping between those addresses and domains. Subsequent connections must be handled by a component that can recognize the mapping; enabling the option alone does not guarantee the full resolution path will work. After turning it off, apps may still have synthetic addresses cached. If connections fail, restart the affected apps and refresh their DNS state.
DNS and Networking
When DNS queries go to a resolver outside the intended path. To troubleshoot, distinguish system resolution, encrypted DNS in the browser, and client DNS, then confirm the actual query route. A resolver name shown by a test page is only a clue; compare it with the client configuration to determine whether it is expected.
Traffic capture, inbounds and outbounds, and domain detection each have distinct roles. Enabling more options does not automatically make a configuration more accurate.
Client Features
A way to provide a local proxy endpoint to apps that follow the system proxy settings. v2rayN's “Automatically Configure System Proxy” changes related system settings, but not all apps use this endpoint. “Clear System Proxy” and “Do Not Change System Proxy” work differently: the latter preserves the current system state, including proxy settings written by other programs.
Client Features
A way to capture traffic through a virtual network interface and system routes. Before enabling it, check permissions, DNS, and conflicts with existing VPNs. Captured traffic is still governed by routing rules. “Enable Tun” on desktop and VPN connection authorization on Android are different interface actions; steps for one platform do not directly apply to the other.
Client Features
An inbound is where the core receives connections; an outbound is how it connects to a destination or remote server. Routing rules send inbound traffic to the appropriate outbound, and referenced tags must match the configuration. In tutorials, direct usually refers to the direct outbound tag, but custom configurations must still define it; the name alone does not create an outbound.
Client Features
A feature that attempts to identify metadata such as the destination domain from a connection's initial data for routing decisions. It cannot decrypt arbitrary encrypted content; what it can identify depends on the protocol and client settings. When adjusting related options, distinguish “for routing only” from behavior such as “override destination,” so an identified domain does not replace the connection target with an unsuitable one.