TERMS REFERENCE / CONCEPT REFERENCE
Understand the boundaries between protocols, cores, configuration and routing. Identify the layer a term belongs to, then compare it with client settings and JSON fields.
01 / PROTOCOL & TRANSPORT
Proxy protocols define authentication and data formats; transports carry connections; security layers protect communications. A node usually combines parameters from all three, and similar names are not interchangeable.
A proxy protocol in the V2Ray ecosystem that authenticates users by ID and has its own data-protection mechanism. Check the user ID, protocol options and underlying transport settings separately; a server address alone is not enough. Compatibility settings from older guides may not apply to current implementations. If a connection fails, first check the core version and server requirements.
A proxy protocol with a streamlined authentication structure. It does not encrypt payloads on its own and is often paired with TLS or REALITY. VLESS, the transport and the security layer are separate settings; choosing one does not configure the others. If the connection uses a specific flow-control option, confirm that both cores support it.
A proxy protocol typically running over TLS that uses a password for authentication. A successful connection depends not only on the password, but also on the port, server name and correct certificate verification. For certificate errors, check the name, trust chain and device time rather than simply disabling verification.
A family of protocols that carry proxy traffic using specified encryption methods and credentials. Specifications and encryption methods may have different key-format and implementation-version requirements, so verify the method name after importing. This is a different protocol from VMess and VLESS; changing a display name does not convert it.
A security protocol that provides encryption, integrity protection and authentication for a connection; it is not itself a proxy protocol. Clients generally need the correct server name and must verify that the certificate is trusted. SNI indicates the target name during the handshake. It may differ from the connection address, but only when the server is configured for that arrangement.
A transport security method in the Xray ecosystem, commonly used with VLESS. Enter the public key, server name and other connection parameters provided by the server; do not assume that every standard TLS setting applies. A client recognizing a link does not guarantee that its core can run it. Check support in the core version you use.
02 / CORE & CLIENT
The interface organizes settings; the core handles connections. System proxy and TUN are ways traffic enters the client, not remote proxy protocols.
An ecosystem of projects built around network proxying and communication tools, with V2Ray as a key part. The name does not refer to a particular GUI client or mean that every implementation in the ecosystem has identical features. When reading documentation, check whether it refers to the project, a specific core or a client interface.
A community project maintaining core implementations related to V2Ray. The core handles protocols, inbound connections, outbound connections, routing and DNS. v2flyNG is an Android client option from this core family. When comparing configurations, check the exact versions; matching filenames do not guarantee that fields are fully compatible.
An independent core project with historical ties to V2Ray and its own direction for protocol support and configuration details. v2rayNG uses the Xray core; v2rayN capabilities depend on the selected core. A feature documented for Xray does not necessarily mean another core accepts the same configuration.
An app for managing subscriptions, choosing nodes and adjusting connection settings. It typically generates a configuration for the underlying core to use. v2rayN, v2rayNG and v2flyNG are client names, not protocol names. When troubleshooting, record the client and core versions separately: the interface and connection capabilities may be determined by different components.
Proxy settings provided by the operating system to apps, usually pointing to the client's local listening address and port. Only apps that follow these settings use that entry point; command-line tools and apps with their own network settings may take another route. Enabling the system proxy sets the entry point, but does not determine which outbound the core uses for a request.
A way to route IP packets through a virtual network interface, including traffic from some apps that ignore system proxy settings. Actual coverage depends on the client implementation, system permissions, routing and exclusion rules. Check DNS handling and local network access as well. If problems arise, first check for route conflicts with other networking tools.
03 / CONFIGURATION STRUCTURE
Configurations are easier to troubleshoot when read as “accept connections → match rules → choose an exit.” The terms below correspond to common JSON fields. For a complete example, see the JSON Configuration Guide.
A configuration format that uses objects, arrays and key-value pairs to define core behavior. Strings and field names use double quotes. Successful parsing only confirms valid syntax; it does not mean the current core supports every field. A client-generated runtime config may be overwritten the next time settings are saved, so find the persistent settings interface before editing it.
A configuration section that records runtime status and errors, often used to diagnose parsing failures, handshake failures or timeouts. Log level controls the amount of detail; temporarily increasing it can help with troubleshooting but produces more output. Check timestamps against when the problem occurred. Before sharing logs, remove subscription URLs, credentials and unnecessary browsing details.
An entry point where the core accepts connections, typically defined by a listen address, port, inbound protocol and tag. A local SOCKS or HTTP proxy port is a common inbound: apps connect there before the core handles their requests. Listening on the loopback address exposes the port differently from listening on all interfaces. Before allowing LAN access, check firewall and authentication settings.
An exit used by the core to handle requests, such as a remote proxy, a direct connection or a block action. Routing rules usually refer to outbounds by tag, so each tag must match its references. Check what happens to requests that match no rule. The order shown in a client list does not necessarily indicate the default outbound in the generated configuration.
A mechanism that identifies protocols or destination domains from initial connection data, often used to provide more information for routing. It cannot decrypt arbitrary encrypted payloads and may not recover the domain for every connection. Check the specific options to see whether sniffed data is used only for routing or also affects the connection target. Enabling sniffing is not a universal fix for domain-based rules.
A configuration section for connection timeouts, user-level behavior and some statistics options—not a domain-based routing table. The word “policy” may also appear in other client menus, so first identify the relevant field. Changing timeouts affects when connections are kept open or terminated; it does not directly increase line capacity or server response speed.
04 / ROUTING & DNS
Split tunneling depends on the information available for matching, while DNS determines how domains are resolved. Check both the rules and whether requests enter the core with a domain name or an IP address.
A set of rules that selects an outbound based on criteria such as domain, IP, port, protocol or inbound tag. Split tunneling is the process of making that selection. Rules are usually checked in configuration order, so specific exceptions should come before broader rules that might override them. Client modes such as “Bypass mainland China” are usually names for rule presets, not protocols like VMess.
A collection of IP addresses grouped by region or purpose, which routing can match in bulk using a dataset tag. It classifies addresses in a data set; it is not a live measurement of a server's physical location or service ownership. Results may change when a site uses multiple addresses or its addresses change. Check the actual connection target and the data's update date.
A collection of domains grouped by service, purpose or another category, reducing the need to maintain domain rules one by one. Names and contents depend on the data files in use, and not all core environments include the same categories. If the core only has the destination IP, a domain list may not match directly; check the inbound information and traffic-sniffing settings.
An option controlling how a particular configuration section handles domain resolution. Fields with the same name can have different meanings in different sections. In routing, IPIfNonMatch generally means to try matching with the available information first, then resolve the domain and try IP rules if nothing matches. It does not mean that every app's DNS requests are sent to one resolver.
Returns synthetic IPs to apps and maintains a mapping between those addresses and the original domains. Later connections must pass through a chain that can restore the mapping; a synthetic address is not the website's real address. If lookup and connection traffic take different paths, apps may fail to connect. Check DNS interception, the address pool and routing as a whole.
When domain lookups take a resolution path outside the intended policy. First clarify which resolver and route are expected. The system resolver, browser-specific DNS and app-integrated resolvers may all handle requests. A test page showing the region of a DNS service is only a clue; it cannot prove that every app follows the same policy.
05 / SUBSCRIPTION & NODE
A subscription distributes connection settings, a node is a record of those settings, and a test result describes performance under specific conditions. Assess each separately; a single speed test cannot replace checking the configuration.
An address the client uses to fetch and update a set of connection configurations. The provider and client determine the format and contents. Updating a subscription may not sync routing, DNS or local preferences, and manually edited nodes may be overwritten by the next update. Treat subscription URLs like credentials and store them securely.
A set of connection parameters saved by a client, usually including an address, port, protocol, authentication and transport settings. A node record does not necessarily correspond to a single physical server, and one address can serve multiple configurations. Region or route details in a node's name are descriptive; judge actual use by the connection result and configuration.
A text link that packages connection parameters for sharing; clients can read it from the clipboard or a QR code. Successful import means only that the content was parsed—not that every parameter is supported or that the server is available. Share links may contain credentials, so do not expose them in screenshots, logs or public support requests.
Converting one subscription or node format to another, often involving field mapping and handling unsupported settings. Conversion cannot add protocol support that the target client does not have, and some settings may lose their meaning in the process. A conversion service may receive the original content, so review how it handles data and who can access it.
Response time measured by a specific test method. Read it in context of the test target, network layer and timeout. ICMP probes, TCP handshakes and requests sent through a proxy measure different things; their values are not directly comparable. Lower latency does not mean faster downloads: throughput also depends on capacity, congestion and server load.
The time measured when a client connects to a test target through a specified proxy, usually a closer representation of the actual request path than simply checking a server port. Whether the test includes DNS, a TLS handshake or reading a response depends on the client's current implementation. Success confirms access to that target at that time; a timeout could also be caused by the test site or local settings, and does not prove the node is down.
If you're unsure whether requests reach the client, check the system proxy and inbounds. If requests arrive but use the wrong exit, check routing rules and outbound tags. If domains and IP addresses behave differently, review domain strategy and DNS. Change one related group of settings at a time, keeping the test conditions needed to reproduce the problem.