REFERENCE / TERMINOLOGY
Browse protocols, cores, traffic entry points and JSON fields by configuration layer.
The same setting name can appear in different cores or configuration layers. This page explains each concept and its scope; check the values against your core and client UI. Each glossary card has its own anchor, so you can copy its URL to link directly to it.
PROTOCOL / TRANSPORT
The proxy protocol defines how communication works, the transport carries data, and the security layer protects the connection. They serve different purposes and are not interchangeable.
VMess is a proxy protocol in the Project V ecosystem, with user authentication and data transport mechanisms. Configurations commonly include a user ID and encryption options. It can use different transports, so the protocol name alone is not enough to determine the full connection settings. The client and server need compatible protocol implementations and matching authentication details. An incorrect system clock can also affect authentication.
VLESS is a lightweight proxy protocol that does not encrypt traffic itself and is typically paired with a security layer such as TLS or REALITY. Check the node's user ID, transport, security settings and any flow-control options together. VLESS and VMess are not interchangeable by simply changing the protocol name; the server must support the chosen combination.
Trojan typically carries proxy traffic over a TLS connection and uses a password for authentication. Along with the server address and port, check the server name and certificate verification settings. The address establishes the connection, while the server name is used in the TLS handshake; they serve different purposes. A certificate error does not necessarily mean the password is wrong.
REALITY is a transport security mechanism in the Xray ecosystem, not a standalone proxy protocol alongside VLESS. Check the server-provided public key, short ID and server name, and make sure the client core supports the configuration. Its parameters differ from standard TLS, so do not reuse certificate settings or infer the connection method from the protocol name alone.
Transport describes how a proxy protocol carries data. Common options include raw TCP, WebSocket and gRPC. WebSocket may require a path and request hostname; gRPC may require a service name. These parameters must match the server. More transport options are not inherently better, and switching transports will not make any node compatible. Support depends on the protocol, core and server deployment.
KERNEL / ECOSYSTEM
The client provides the interface; the core handles connections. Similar names do not guarantee the same feature set.
Project V is a project and technology ecosystem built around modular network proxy tools, with V2Ray as a core component. In everyday use, “V2Ray” can refer broadly to related tools or specifically to the core, so identify the context when following a guide. For protocol support or field compatibility, check the specific core rather than relying on the ecosystem name.
V2Fly is a community project continuing V2Ray development. Its core handles proxy protocols, routing and DNS. v2flyNG is one GUI client option for Android; a client and a core are different layers. When using configuration examples, check the format and core generation instead of assuming every legacy field applies to your setup.
Xray is a core project developed from the V2Ray technology stack, with its own protocols, security layers and configuration changes. v2rayNG uses the Xray core; for desktop clients, check which core is selected in the settings. Even when two cores accept similar JSON structures, individual fields, defaults and supported combinations may differ. Review them section by section when migrating.
v2rayN, v2rayNG and v2flyNG provide graphical interfaces for managing subscriptions, connection parameters and runtime settings; the core reads the configuration and handles network traffic. Clients usually generate runtime configurations from UI options, so manual edits to generated files may be overwritten on the next launch. When troubleshooting, record both client settings and core logs to distinguish a settings save issue from a core execution failure.
CLIENT / SUBSCRIPTION
Subscriptions provide connection parameters, proxy entry settings determine how app traffic reaches the core, and latency tests reflect only specific test conditions.
A subscription is content or a URL used to retrieve connection configurations in bulk. When a client refreshes it, the client reloads the node information. A subscription is different from a single-node share link and is not necessarily a complete JSON configuration that any core can run directly. Subscription URLs may contain access credentials, so avoid sharing them publicly. After refreshing, check that the selected node is still available.
A node is a common client term for a set of remote connection parameters, typically including an address, port, protocol, authentication details and transport security settings. Its display name is just a label; it does not prove the actual exit location or network quality. One server can also offer several sets of parameters. To determine whether two entries use the same connection, compare their settings rather than their names.
System proxy settings register a local proxy address with the operating system and primarily affect apps that read that setting. They do not mean all traffic is proxied, nor are they the same as global routing in the core; some apps use their own network settings. After changing the local listening port, confirm that the system proxy setting was updated too. A stale address left behind after closing the client may prevent affected apps from connecting.
TUN mode captures IP traffic through a virtual network interface and is often used for apps that ignore system proxy settings. Its coverage still depends on routing, permissions, DNS settings and the client implementation; it does not guarantee that all traffic goes through a remote proxy. Before enabling it, check whether other virtual adapters or network tools are also managing routes. If problems occur, disable TUN first to narrow down the cause.
TCP latency usually measures how long it takes to establish a TCP connection to the server port; it does not prove that proxy authentication succeeded. Proxy latency usually tests access to a target through the selected proxy and can be affected by the handshake, DNS resolution, target site and test implementation. Do not compare the two results as if they were equivalent. When choosing a node, also consider performance in your apps, stability and traffic charges.
ROUTING / DNS
DNS resolution returns an address; routing rules choose the egress. To check traffic-splitting results, consider the domain, IP and actual request path together.
Routing rules select an outbound based on conditions such as domain, IP, port or inbound tag. Traffic splitting sends traffic to different exits according to those conditions. Rules commonly match in order, and the first match determines the route, so a broad rule placed first can prevent more specific rules from taking effect. System proxy settings determine whether some traffic enters the core; routing rules decide where it goes once inside.
In this type of configuration, GeoIP usually refers to IP address classification data used for routing matches. You can reference a collection with an expression such as geoip:private. This classification data is not a live location result and does not resolve domain names to IPs. A collection can take effect only when the rule obtains the destination IP and evaluates it for a match; data updates can also change its coverage.
GeoSite is a collection of domain rules organized by category, letting you reference a group of related domains without maintaining each one individually. A category name does not tell you which entries it contains; login, media and static asset domains for the same service may appear in different collections. If traffic splitting misses a request, check the actual domain first, then confirm whether the data includes it and whether an earlier rule takes precedence.
FakeDNS assigns synthetic IPs to domain names and stores the mappings so the core can recover the domain when traffic reaches it. It requires DNS interception, a traffic entry point and mapping recovery to work together; simply switching DNS servers is not enough. Connections can fail if an app has cached an old mapping or traffic bypasses the expected processing path. Check both the cache and the scope of DNS interception when troubleshooting.
A DNS leak typically means queries leave the intended resolution path—for example, when a designated resolver is expected to handle them but the operating system or browser uses another resolver. First establish the intended path, then check how encrypted DNS in the browser, the system resolver and core DNS work together. A resolver name shown by a test page is only a clue; by itself, it does not prove where all traffic exits.
JSON / CONFIGURATION
Interpret field names in the context of their parent objects. Before copying a snippet, check whether it belongs to an inbound, outbound or top-level configuration.
inbounds is an array that defines traffic entry points. Each item can specify a listening address, port, protocol and tag. It describes how the core receives app requests, not a list of remote servers. For local use, check the scope of the listening address: binding to the loopback address and binding to all network interfaces have different exposure boundaries. Do not broaden access just to troubleshoot a connection.
outbounds is an array that defines traffic exits, which can include a remote proxy, a direct connection or a block action. Routing rules reference entries by their outbound tags, so tag names must match exactly. In common configurations, traffic that matches no rule uses the first outbound. Changing the array order can therefore change the default route; confirm the behavior for your core.
sniffing usually appears in an inbound object. It extracts domain clues from supported protocol handshakes or request information to assist routing or destination handling. It is not a general-purpose decryption feature and cannot recover the domain for every connection. Its effects also depend on options such as destination overrides and route-only mode. Enabling sniffing does not guarantee that every domain rule will match.
Interpret domainStrategy in the context of its parent object. In routing, it controls whether the core attempts to resolve domain names to IPs for routing matches. Common values include AsIs, IPIfNonMatch and IPOnDemand, but this setting is not a master switch for system DNS. The same field name may take different values in other objects, so do not copy it across configuration layers without checking.
allowInsecure appears in some TLS configurations. Setting it to true relaxes certificate verification; it does not fix an underlying trust chain or server name issue. For certificate errors, first check the system clock, certificate chain and configured server name. Keeping verification enabled is the normal configuration; disabling it is not a general-purpose connection fix.
policy is a policy configuration object for connection timeouts, user-level policies and some statistics settings. It serves a different purpose from routing and does not select an outbound based on domain or IP. Before changing handshake timeouts or idle connection settings, identify which stage is failing. Extending a timeout alone usually will not fix authentication errors, unreachable ports or incorrect rule references.