V2Ray / Glossary
Understand the layers before looking up individual fields. Protocols define how the two ends communicate; the core applies the configuration; and the graphical client manages nodes, subscriptions, and controls.
This page covers 30 common terms. Each card has an anchor you can link to directly from the address bar. Whether a field is supported depends on the core and version currently used by the client.
01 / Protocol & transport
Protocol, transport, and transport security are three distinct layers. A node name that lists only the protocol is usually not enough to reconstruct the full connection settings.
VMess is a proxy protocol with user authentication, typically identified by a UUID. The client and server must also use matching transport and security settings. An address and port alone are not enough to connect. Authentication depends on time, so check the device clock when troubleshooting a failed connection instead of simply switching nodes.
VLESS is a lightweight proxy protocol that does not provide the same payload encryption as VMess. In practice, it is usually deployed with TLS or REALITY. Set the user ID, transport, and optional flow parameter as required by the server. VLESS support does not guarantee support for every combination; confirm that the core supports the features you need.
Trojan typically carries proxy traffic over a TLS connection and uses a password for authentication. The password and TLS server name are separate fields and cannot replace one another; the connection address may also differ from the domain used by the certificate. If you see a certificate error, check the server name, system time, and certificate chain rather than disabling certificate verification.
REALITY is a transport security mechanism in the Xray ecosystem, not a standalone proxy protocol alongside VLESS. Its settings typically include the server public key, server name, short ID, and client fingerprint. It does not use certificates in the same way as a standard TLS server, so changing only the security option does not convert a TLS node to REALITY.
Transport determines how proxy data travels over the underlying connection, such as TCP, WebSocket, or gRPC. Settings like paths, service names, and request headers depend on the transport and are not used by every protocol. Check the protocol, transport, and security settings separately when configuring a node; a mismatched path can also cause a handshake failure.
02 / Core & ecosystem
The client window provides controls; the core handles connections. Compatibility checks need to account for both layers.
Project V is a commonly used name for the ecosystem around V2Ray and related network tools. It is neither a node protocol nor the name of a graphical client. Distinguish the proxy core, client, and config format when discussing the ecosystem. Tools with similar names may use different cores, so check their capabilities separately.
V2Fly is a community project continuing the development of V2Ray. Its core handles tasks such as parsing configuration, accepting inbounds, and making outbound connections. The Android client v2flyNG is one option that uses this core. V2Fly and Xray evolve independently, so check that your nodes and config fields are compatible before switching cores.
Xray is a proxy core derived from V2Ray; features such as REALITY require support from the relevant implementation. v2rayNG uses Xray, while the core used by desktop client v2rayN should be checked in the current interface and logs. Updating the client is not the same as updating the core. When troubleshooting field errors, note the actual core version.
A graphical client provides controls for node lists, subscription updates, mode switching, and logs. It typically generates a config and calls the core. v2rayN is for desktop, while v2rayNG and v2flyNG are for Android. Display names and groups in the interface are management details and may not appear as fields with the same names in the core config.
03 / JSON structure
Connections enter through inbounds, then rules select an outbound. Tags link config objects, while policies constrain some connection behavior.
config.json is a common filename for a core config, typically containing sections such as log, inbounds, outbounds, routing, and dns. JSON requires precise syntax for commas, quotes, and data types, so a snippet from the docs may not run by itself. A client may regenerate its runtime config and overwrite manual edits; check where custom settings should go first.
The inbounds array defines how the core accepts connections. Common local proxy endpoints use SOCKS or HTTP. The listening address and port determine where apps should connect; changing the address from loopback to all interfaces broadens access. If you change the port, update the app's proxy settings too, and make sure another process is not already using it.
The outbounds array defines how connections leave the core: through a remote proxy, directly, or by being blocked. Routing rules usually reference an outbound by its tag, not by the node name shown in the client. The default outbound also matters when no rule matches, so check the full outbound list rather than just one rule.
A tag is a reference name for a config object. For example, name a direct outbound direct, then point a rule's outboundTag to it. A rule's inboundTag can restrict which inbounds it matches. Tags are not protocol keywords; choose names to suit the config, but keep references consistent and avoid duplicate outbound tags that could cause ambiguity.
policy configures some core behavior, such as handshake or idle connection timeouts and specific statistics options. It is different from routing: policy does not choose a proxy or direct outbound based on a domain. Core support for fields, user levels, and statistics conditions varies, so consult the relevant documentation instead of copying policy settings from another tool.
Field examples and configuration: Inbound config · Outbound config · Policy config
04 / Routing & DNS
First determine whether a rule can see a domain or an IP address, then find out where DNS resolution happens. Check rule matching and the DNS query path separately.
Traffic splitting sends connections to different outbounds based on conditions such as domain, IP, port, or inbound tag. Rules are usually checked in order, so an earlier match can affect what happens next; different condition types within a rule generally all need to match. After changing rules, check the logs to confirm the actual destination and matched rule rather than relying on the mode name shown in the interface.
GeoIP matches destination addresses against IP ranges in a data file. geoip:private is commonly used for private address ranges. These classifications reflect the data source and do not prove a precise physical location. If a destination is initially a domain, whether and how it is resolved for IP-based rules also depends on the routing resolution strategy.
GeoSite uses named domain sets to organize rules, with set contents determined by the data file in use. Even when labels match, check the data source and its update date; a set may not include every domain for a service. Referencing a set that does not exist can prevent the config from loading, so check the rules and data file together.
DNS resolves domain names to IP addresses and other records. Resolution may be handled by an app, the operating system, the proxy core, or a remote component. Configuring the core's dns section does not automatically route every app's DNS queries through it. Check the query entry point, upstream resolver, outbound used for the query, and how the resulting address is used for routing.
FakeDNS returns a virtual address to an app and later maps it back to the original domain when the connection enters the relevant processing flow. These are not real server addresses and cannot be used directly by network paths that do not know about the mapping. The DNS entry point, virtual address range, and traffic interception method must work together; adding a single field does not set up the entire flow.
A DNS leak occurs when queries bypass the expected resolution path and go to another resolver; not every local DNS lookup should be described as a leak. Encrypted DNS in a browser, the system cache, and app-specific DNS can all change the query path. Check against the intended DNS policy: seeing the expected proxy exit IP does not prove DNS queries took the expected route.
Read next: Routing fields and rule order · DNS config
05 / Subscription & node
Subscriptions retrieve settings, nodes store connection settings, and tests report results under specific conditions. They are not interchangeable.
A subscription link is a remote URL a client uses to retrieve a set of node configs. The client must recognize the response format. Links may contain personal access credentials, so do not include them in public screenshots or logs. When an update fails, distinguish an invalid URL from a request failure or a format parsing error. Installing the client does not automatically provide a usable subscription.
A node is a set of remote connection settings saved in a client, typically including an address, port, protocol, authentication, and transport security. Its display name is just a label; it does not confirm the actual hosting region or connection quality. Selecting a node sets the candidate outbound parameters, but whether app traffic uses it depends on the proxy entry point and routing rules.
Subscription groups organize sources and node lists for easier updates, filtering, and maintenance. Group names usually do not participate directly in core routing rules and are not the same as rule sets. Updating a subscription may replace its node records; whether manual edits are preserved depends on the client. Manage important changes in a separate config where possible.
TCPing generally estimates whether a destination port is reachable and how long it takes to establish a TCP connection. The exact test depends on the client. It usually does not perform proxy authentication or confirm that TLS, the transport path, and remote forwarding all work. A successful TCPing result alongside a failed proxy request is not a contradiction; check the full connection test and core logs.
Proxy latency is measured by sending an actual request through the selected node, so it typically covers more of the connection path than a basic port test. Results depend on the test destination, DNS, handshake, server response, and current network conditions; clients may also measure it differently. Latency is not throughput. Compare nodes under the same test conditions, then check how they perform with real app requests.
06 / Client functions
Route traffic into the proxy flow before considering outbound selection. After switching an interface setting, check what actually takes effect.
A system proxy is a set of proxy settings provided by the operating system for apps to read. Only apps that honor these settings will use the specified endpoint. Writing the system settings does not start the core, and the port must match its local listener. If a program still connects directly, first check whether it supports the system proxy and whether it has its own proxy settings.
TUN uses a virtual network interface to receive IP traffic, then lets the client's chosen implementation handle connections. It can cover some apps that do not read system proxy settings. Actual coverage depends on system routes, exclusions, permissions, and component capabilities; it does not mean every connection will go through a remote proxy. TUN is a feature that relies on the client and companion network components working together, not a generic top-level V2Ray field.
PAC uses a script to choose a proxy address or a direct connection for each request, provided the app supports and uses the script. This decision happens when the app selects a connection path, not when the core matches routing rules. Requests that PAC sends directly do not pass through the proxy entry point, so core rules cannot intercept them later.
Sniffing attempts to identify domain or protocol information from the initial connection data, providing additional input for features such as routing. What it can see depends on the protocol, encryption, and core implementation; it does not read all encrypted content. Check the specific options to distinguish using a detected domain in place of the destination address from using it only for routing.
The log level controls how much detail the core outputs. warning typically shows warnings and errors; you can temporarily increase detail when troubleshooting. Client operation logs and core runtime logs may appear separately, so identify which component reported the error. Logs may contain connection destinations, config paths, or subscription details; remove sensitive information before sharing them.