V2Ray / Configuration Terms

V2Ray Glossary

Protocols determine how connections are established; the core handles execution, and the client manages settings. Browse five categories to identify each setting's role before checking its parameters.

26 terms Protocols & cores · Traffic capture & routing · Testing & DNS

Configuring a client? Start with system proxy and routing rules. Importing a configuration? Start with subscription links and share links.

PROTOCOL / TRANSPORT

Protocols & Transports

A node type is only one layer of a configuration. The proxy protocol, transport, and connection security mechanism must each match the server settings.

Protocols & TransportsVMess: VMess is a proxy protocol in the Project V ecosystem with authentication and data encryption, and commonly identifies users by UUID. VMess and transports such as TCP and WebSocket are separate layers, so checking only the protocol name is not enough when importing a configuration. Some verification steps depend on the system clock, and a time mismatch can cause connection failures. New configurations generally use AEAD; avoid blindly applying parameters from older guides.
Protocols & TransportsVLESS: VLESS is a lightweight proxy protocol commonly used in the Xray ecosystem. Typical setups rely on TLS or REALITY to secure the connection rather than VLESS alone. The UUID, transport, server name, and any flow setting must match the server. Configurations using the same VLESS type are not necessarily interchangeable, so check that the core supports the complete set of parameters.
Protocols & TransportsTrojan: Trojan is typically used over TLS and uses a password for proxy-level authentication. The password authenticates the user, while the server name and certificate verification confirm the TLS connection's destination; neither replaces the other. If you see a certificate error, check the domain, system clock, and certificate configuration first. Skipping certificate verification should not be a routine setting.
Protocols & TransportsShadowsocks (SS): Shadowsocks is a family of protocols built around encrypted proxying, often abbreviated to SS in clients. The encryption method and password must match the server; AEAD methods and newer protocol variants are not interchangeable. Support for specific encryption methods, UDP, and extensions depends on the core, so check the other fields rather than relying on the SS type alone.
Protocols & TransportsREALITY: REALITY is a connection security mechanism in Xray, often paired with VLESS; it is not a standalone node type that replaces a proxy protocol. The public key, server name, and parameters such as shortId must match the server and should not be pieced together from unrelated configurations. A client displaying the relevant fields does not guarantee that its running core supports the combination.

Compare protocol and core options →

PROJECT / CORE

Cores & Ecosystem

A graphical client and a proxy core are different programs. Similar interfaces do not guarantee identical features or configuration formats.

Cores & EcosystemProject V: Project V refers to the project and technology ecosystem built around modular network proxy tools, with V2Ray as a key component. It is not the name of a desktop or Android client, nor a protocol type to enter directly for a node. When consulting documentation, check which core, configuration format, and graphical client's settings it covers.
Cores & EcosystemV2Fly: V2Fly is a community project continuing V2Ray's development, with its core handling protocol connections, routing, and DNS. v2flyNG is an Android client built around this core ecosystem; keep the project and client names distinct. V2Fly and Xray share some configuration concepts, but independently evolving fields and features should not be assumed to be compatible.
Cores & EcosystemXray: Xray grew out of the V2Ray technology stack and has since developed its own features and configuration. Capabilities such as REALITY require a compatible core. v2rayNG uses the Xray core; v2rayN's capabilities depend on the selected core and version. Changing cores can affect connection parameters, routing behavior, and logs, even when the interface looks the same.
Cores & EcosystemCore: The core is the program that actually handles proxy protocols, connections, routing, and DNS configuration; the graphical client organizes settings and invokes it. When troubleshooting, a successful save in the interface only confirms that the configuration was accepted—you still need to check whether the core starts correctly. Client and core versions are separate details. Record both when reporting compatibility issues to distinguish missing interface options from core errors.

CLIENT / INBOUND

Client Features

First, determine how app traffic enters the processing chain. System proxy settings, virtual network interfaces, and per-app controls each cover different traffic.

Client FeaturesSystem proxy: A system proxy registers a local proxy address with the operating system and mainly affects apps that follow that setting; it does not capture all network traffic. In v2rayN, automatically setting or clearing the system proxy changes this entry point, not the server. An app's own proxy settings may override the system setting. Once a connection reaches the core, routing rules determine whether it uses the proxy or connects directly.
Client FeaturesTUN mode: TUN mode captures IP packets through a virtual network interface and can cover apps that ignore system proxy settings. Actual coverage also depends on system routes, permissions, exclusions, and the client implementation, so the toggle alone does not tell you what is captured. If name resolution fails after enabling it, check DNS capture and other virtual network interfaces to avoid competing routes.
Client FeaturesVpnService: VpnService is an Android virtual network interface service that v2rayNG can use to capture app traffic and pass it to the core. The system's VPN permission prompt allows the interface to be created; it does not mean every connection is sent to a remote server. Other VPN services in the same environment may compete for access. If background connections drop, check the system's battery restrictions too.
Client FeaturesPer-app proxy: Per-app proxy settings determine which apps send traffic through the client's proxy processing chain. Common options include capturing only selected apps or bypassing selected apps. What the list means depends on the current mode, so read the interface description before selecting apps. Even captured traffic may use a direct outbound because of routing rules; troubleshoot the app list and domain routing rules separately.
Client FeaturesInbound: An inbound is where the core accepts connections. Common configurations include local HTTP or SOCKS listeners; the listen address, port, and protocol determine how apps connect. The local proxy port entered in an app must match the actual inbound—do not enter the server port here. A listener on a loopback address is usually available only to the local device; before exposing it on other interfaces, consider access controls and network exposure.

Follow the client setup and traffic capture steps →

SUBSCRIPTION / TEST

Subscriptions & Nodes

A subscription is a configuration source, a node is a configuration entry, and a test result is an observation under specific conditions. They are not interchangeable.

Subscriptions & NodesSubscription link: A subscription link retrieves a set of server configurations. When a client updates a subscription, it requests the content again and organizes the nodes according to its own logic. The returned format must be supported by the client; an arbitrary web page URL cannot be imported as a subscription. The link may contain credentials and should be treated as sensitive. Before updating, consider whether manually edited node settings will be overwritten.
Subscriptions & NodesNode: A node is a common term for a selectable server configuration in a client, typically containing an address, port, authentication details, transport, and connection security parameters. A display name does not necessarily represent a separate server; the same address may offer different entry points on different ports or with different parameters. To determine whether a configuration is duplicated or invalid, compare its actual fields and connection logs rather than its name.
Subscriptions & NodesShare link: A share link packages a single server configuration in a format such as vmess:// or vless://, making it easy to copy or scan for import. Unlike a subscription URL, it does not keep fetching configuration updates; an imported link usually will not reflect later changes. It may contain credentials, so check access permissions before forwarding it. After importing into another client, verify that all extended parameters were preserved.
Subscriptions & NodesLatency: Latency is the time a test takes to get a specified response; a number is meaningful only alongside the test method. ICMP ping measures network-layer round-trip time, TCP tests often measure a port handshake, and application requests may also include protocol negotiation and the target's response. Low latency does not mean high download speeds. For a fair node comparison, keep the test target, method, and timing conditions consistent.
Subscriptions & NodesReal connection latency: Real connection latency usually means the time taken to send an actual request to a test target through the current proxy configuration; the precise timing depends on the client. It may be affected by DNS resolution, the protocol handshake, the target's response, and connection reuse, so it is not simply a measure of network-path latency. A failed test does not necessarily mean the node is down; first rule out issues with the test target and local settings.

ROUTING / RESOLUTION

Routing & DNS

Rules need information they can match. Whether a domain is preserved, when it is resolved to an IP address, and where the query is sent can all affect routing.

Routing & DNSRouting rule: Routing rules select an outbound based on conditions such as domain, IP, or port. Common V2Ray and Xray rules are evaluated from top to bottom. The outboundTag in a matching rule must correspond to a defined outbound tag; multiple conditions within the same rule generally all need to match. Before changing rules, check their order and match criteria to prevent a broad rule from catching connections too early.
Routing & DNSTraffic routing: Traffic routing assigns connections to outbounds such as proxy, direct, or block; it is not a standalone protocol. The outcome depends on traffic capture coverage, rule order, domain information, and DNS settings. If an app uses the wrong route, first confirm that its traffic enters the core, then check which rule matches. Switching nodes alone usually does not change existing direct-routing rules.
Routing & DNSGeoIP: GeoIP refers here to sets of IP addresses organized by tag, which routing can reference with expressions such as geoip:private. Available tags and their address ranges depend on the rule data and core support. IP geolocation does not indicate network quality or necessarily where a service is operated. Whether a domain connection can match an IP rule also depends on the DNS resolution strategy.
Routing & DNSGeoSite: GeoSite is a collection of domains organized by tag, unlike GeoIP, which matches IP addresses. Tags in expressions come from the rule data files; guessing a tag from a website name will not make a rule work. If a rule sees only the destination IP and no domain, it may not be able to match a domain set. Check what information the inbound provides and review sniffing settings.
Routing & DNSDNS: DNS resolves domain names to records such as IP addresses. Apps, the operating system, and the proxy core may each issue queries. DNS settings in the core do not necessarily capture all system queries, and a browser's encrypted DNS may create another resolution path. To troubleshoot, identify who makes each query, which resolver receives it, and which outbound carries it—not just the DNS address.
Routing & DNSFakeDNS: FakeDNS returns mapped addresses to apps and internally keeps track of the mapping to the original domain so the domain can be restored for subsequent connections. It must work with traffic capture and the mapping lookup process; it is not an address for an arbitrary public DNS server. If an app still has a mapped address cached after the feature is disabled or its mapping state is lost, connections may fail.
Routing & DNSDNS leak: A DNS leak occurs when queries do not follow the intended resolution path—for example, when queries meant to use a specific route are still sent to the local network resolver. Whether this is a problem depends on the actual policy; seeing multiple resolvers in a test does not automatically indicate a leak. Check system DNS, encrypted DNS in apps, traffic capture coverage, and core logs. Switching nodes will not automatically fix every query path.

Continue with the protocol and core guide → Find answers by issue in the FAQ →