V2RAY / TERMINOLOGY
Protocols, cores, configuration fields and diagnostic metrics. Find terms by the layer they belong to, and distinguish traffic capture, proxy protocols and transport security.
This page covers 30 common terms. Start with each term's meaning, then check the core and version your client actually uses. Settings with the same name may produce different configurations, and example fields do not make a complete, ready-to-connect file.
Find terms by what you're troubleshooting
Not sure what a node parameter means? Start with protocols and transports. Editing JSON? Read about configuration structure first. If the connection works but apps behave differently, check routing, DNS and the system proxy. For step-by-step instructions, see the user guide; for examples by configuration section, see the configuration reference.
01 / PROTOCOLS
A proxy protocol defines authentication and data exchange. The transport carries the connection, while TLS and REALITY provide transport security. Check each layer separately when configuring a connection.
A proxy protocol in the Project V ecosystem that identifies users with UUIDs and has its own traffic protection. Current configurations commonly use AEAD. Avoid adding the legacy alterId parameter without a specific reason; modern configurations typically set it to zero. If authentication fails, check the UUID and transport parameters, and make sure the device clock is accurate.
"protocol": "vmess"
A lightweight proxy protocol authenticated with a UUID; it is not simply another VMess encryption option. Common deployments protect traffic with an outer layer such as TLS or REALITY, so check both security and transport parameters. Some newer features require specific core versions, so a link prefix alone cannot confirm client compatibility.
"protocol": "vless"
A proxy protocol that typically runs over TLS and commonly uses a password for authentication. The password authenticates the user; certificate validation confirms the TLS peer's identity. Neither replaces the other. If certificate validation fails, check the server name, certificate validity period and device clock instead of disabling verification.
"protocol": "trojan"
A protocol that protects proxy traffic with an agreed encryption method and key. A node usually includes a server address, port, method and password. Methods differ in key format and core support; in particular, do not mix legacy parameters with those for the 2022 methods. A matching protocol name does not guarantee that every client version can read the node.
"protocol": "shadowsocks"
A transport security mechanism in the Xray ecosystem, often paired with VLESS. It is not a standalone proxy protocol. Clients typically need matching server name, public key, shortId and fingerprint parameters; use the field names supported by the current core. REALITY is not the same as ordinary TLS, and changing only the security type will not complete the configuration.
"security": "reality"
A flow-control option in Xray often paired with VLESS to optimize handling of eligible TLS traffic and reduce unnecessary encapsulation and encryption overhead. Select it with flow; it is not a transport protocol and does not guarantee faster requests. The client and server need compatible flow control, security and transport settings.
"flow": "xtls-rprx-vision"
02 / CORE & CLIENT
The interface manages settings; the core handles execution. To confirm that a feature works, check both client support and the core actually running.
A modular network proxy project and ecosystem concept built around V2Ray, combining capabilities such as access, transport and routing. V2Ray, V2Fly, Xray and GUI clients operate at different layers; they are not different names for the same software. When reading a guide, first check whether it covers the ecosystem, core configuration or interface steps.
A proxy core developed from the V2Ray codebase. It handles connections, protocols, routing and DNS. Check which Xray versions support configurations such as REALITY and Vision. An option shown in the client interface does not guarantee that the bundled or selected core can run it.
A community project that continues to maintain core implementations related to V2Ray and is an important part of the Project V ecosystem. V2Fly and Xray share technical roots, but differ in later features, release cycles and configuration formats. When migrating a configuration, check the target core's documentation rather than copying core-specific fields unchanged.
An app with interfaces for node lists, subscription updates, routing settings and runtime logs, such as v2rayN, v2rayNG and v2flyNG. Clients typically generate configuration and call a core; interface labels may not match JSON field names exactly. Check your operating system and required node features first, then choose the right option on the client downloads page.
03 / CONFIGURATION
A configuration is easiest to understand in this order: receive traffic, select an outbound, then establish the connection. Knowing which layer a field belongs to matters more than memorizing its spelling.
A text format that uses objects, arrays and key-value pairs to describe core settings. Keys and strings use double quotes; Boolean values are written as true or false. Strict JSON does not allow comments or trailing commas, and permissive parsing by some tools is not a general rule. After validating the syntax, check that the fields are supported by the current core and configuration version.
Defines how the core receives app traffic, commonly including a listen address, port and inbound protocol such as SOCKS or HTTP. The local listening port is not the remote server port; they serve different purposes. For local use, bind to a loopback address. Before allowing connections from your LAN, review access controls and device firewall settings.
"listen": "127.0.0.1"
Defines how the core establishes outbound connections, with options such as proxy, direct and block. An outbound's tag is a label referenced by routing rules, not a protocol name; a tag called proxy does not create a proxy connection by itself. When troubleshooting rules, make sure the referenced tag exactly matches the intended outbound.
"outboundTag": "proxy"
Defines runtime policies such as connection timeouts, user-level limits and some statistics options; the available settings vary by core. This is not where you assign a website to an outbound—that is handled by routing. Before changing timeouts, use the logs to identify where the connection fails. Simply waiting longer will not fix authentication or routing errors.
04 / ROUTING & DNS
Traffic routing depends on identifiable destination details. If domains, resolved addresses and the traffic capture path do not line up, a correctly written rule may still fail to match.
Selects an outbound for each request based on conditions such as domain, IP, port, network type or inbound tag. Rules are commonly checked in list order; the first valid match determines the outbound. Conditions within a rule generally all need to match. When troubleshooting, check rule order first, then verify outboundTag—not just the domain spelling.
"type": "field"
GeoIP classifies IP address lists, while GeoSite classifies domain lists; both can reduce repetitive routing rules. Category names, included entries and update status depend on the data files actually loaded, so a category name does not guarantee coverage of every target. Domain lists and IP lists are not interchangeable. If a rule does not match, check both the resolved address and the data source.
"ip": ["geoip:private"]
Directing different requests through different outbounds according to rules, such as proxying specific domains and connecting to LAN addresses directly. The system proxy determines whether some app traffic enters the client; routing determines where those requests go. They are separate settings. Client mode names are just entry points to rule combinations, so check the generated routing rules to understand what they do.
DNS resolves domains to addresses. In routing, domainStrategy determines when to try resolution while evaluating rules. IPIfNonMatch typically tries matching the resolved IP after the domain fails to match; IPOnDemand can trigger resolution when an IP rule is encountered. A field with the same name elsewhere may mean something different, so read it in the context of its containing object.
"domainStrategy": "IPIfNonMatch"
The mechanism first returns a mapped address to an app, then lets the core use that mapping to recover the original domain for further processing and routing. These are not the target website's real addresses, so DNS requests, traffic capture and inbound detection must work together. Enabling one option without capturing the relevant traffic may leave the app with a mapped address it cannot connect to.
A DNS leak occurs when queries do not follow the intended resolution path—for example, when they are expected to go through the client but are instead resolved by the system or browser. Check system DNS, encrypted DNS in the browser, app caches and the client's built-in resolver separately; one test page is not enough. Determine whether a query deviated from the intended path based on a clearly defined network policy.
A way to capture IP traffic through a virtual network interface and routing settings, useful for apps that do not follow the system proxy. TUN is not a proxy protocol and does not replace remote node or DNS configuration; it may also rely on additional components called by the client. If LAN access stops working after enabling it, check route exclusions, permissions and DNS capture settings.
05 / SUBSCRIPTIONS
A subscription provides content, a node contains connection parameters, and a share link expresses those parameters as text. A successful import does not mean the connection has been tested.
A URL for retrieving a set of nodes or configuration data. The client fetches the content again when you update the subscription. The response may be a list of encoded share links, a native configuration or another format, so use the matching import option. The URL may contain access credentials; treat it as sensitive and redact it from screenshots, logs and public support requests.
A displayed set of remote connection parameters in a client, usually including server address, port, authentication and transport security settings. The content provider or user sets the node name; any region or route in the name is not a measured performance result. To troubleshoot a connection, check the actual address and parameters rather than comparing display names.
A share link represents the parameters for a single node as importable text, such as content beginning with vmess:// or vless://. Common VMess share links encode a parameter object with Base64, while VLESS links typically express settings through the address and query parameters. Base64 is encoding, not encryption; successfully decoding the content does not guarantee that its fields are compatible.
Parsing and mapping fields between subscription or configuration formats—not simply changing a file extension. Options the target format cannot represent may be discarded, and conversion cannot add features the target core does not support. After conversion, check the security layer, flow, server name and transport parameters. For sensitive content, prefer a local conversion method.
06 / MEASUREMENT
First identify which part of the connection a test covers, then compare results. Port reachability, a successful proxy request and sustained download speed are different measurements.
An operating system setting that gives apps a proxy entry point, usually the client's local HTTP or SOCKS listening address. Only apps that follow this setting use that entry point, so enabling the system proxy does not capture all traffic. If a browser cannot connect after you close the client, check whether the system proxy still points to a port that is no longer listening.
Latency is the time taken by a specific operation, so the measurement target must be clear. A regular ping usually measures ICMP round-trip time; TCPing typically measures how long it takes to establish a TCP connection to a target port. A successful TCPing only shows that the port is reachable under the test conditions; it does not verify proxy authentication or TLS settings. A probe that gets no response does not necessarily mean all connection methods are unavailable.
The time measured by sending a request to a test address through a proxy, typically closer to real-world browsing than a simple port probe. Results depend on DNS, handshakes, connection reuse, server response and test address; the exact timing method varies by client. Compare nodes using the same test address at roughly the same time, and consider how actual app requests perform.
The amount of usable data received per unit of time, estimated by transferring test data. This is different from how long a single request takes. Test server capacity, network congestion, device performance and concurrency all affect results; low latency does not necessarily mean high throughput. Speed tests use data, so check connectivity and latency first, then test a small number of candidate nodes.
Identifies protocol or domain clues in a connection's initial data for use by later steps such as routing—for example, a visible HTTP host name or TLS handshake information. It is not full decryption and cannot recover the target domain from all app traffic. Check the specific options to see whether it rewrites the target, only informs routing or works with FakeDNS; the main toggle alone does not tell the whole story.
"sniffing": {"enabled": true}