Browse terms by configuration layer, from protocols and cores to routing fields. First distinguish between accepting connections, choosing an outbound, and making a connection; then use client menus and logs to find the relevant setting.
Menus with the same name can differ across client versions. Protocol and field support depends on the core and version actually in use; these definitions do not mean configurations can be copied between cores unchanged.
Proxy protocols define how a connection works; transports and security layers carry and protect it. Check each separately.
A proxy protocol in the Project V ecosystem, with authentication and data protection mechanisms. UUID is a common authentication parameter. VMess does not prescribe a single underlying transport; the same protocol can use different transport settings. When troubleshooting, check the protocol parameters, transport, and security layer separately rather than comparing node names alone.
A lightweight proxy protocol that does not encrypt traffic on its own and is typically paired with a suitable security layer. UUID identifies the user, while settings such as TLS and REALITY affect connection security. A node using VLESS does not mean every core version supports the same flow or transport combinations.
A password-authenticated proxy protocol commonly used with TLS. The authentication password and TLS server name are separate parameters and cannot substitute for each other. If the handshake fails, check certificate verification, the server name, and transport settings; a correct password alone does not guarantee a successful connection.
A security protocol that provides encryption, integrity protection, and peer authentication for data in transit. The serverName setting is generally used to verify the certificate name and may be sent to the server as SNI. The server address and server name can differ, but there should be a clear reason for doing so. Disabling certificate verification should not be a routine troubleshooting step.
A transport security mechanism in the Xray ecosystem, not a proxy protocol alongside VMess and VLESS. It requires a compatible core and matching parameters such as the public key, server name, and short ID. It is related to TLS, but its configuration fields are not interchangeable with TLS fields. A client recognizing a share link does not guarantee that the active core can run that configuration.
Clients provide the interface and management tools; cores run the network configuration. Check both when choosing a setup.
An open-source ecosystem of network proxy and communication tools, with V2Ray as one of its key projects. In everyday use, “V2Ray” can also refer broadly to the wider ecosystem. When following a guide, check whether it applies to V2Fly or Xray rather than treating the ecosystem name as a specific running program.
A community that continues development and maintenance of the V2Ray project. Its core program is commonly called v2fly-core. The core parses configuration, accepts inbound connections, applies routing, and makes outbound connections. Sharing technical roots with Xray does not mean that new protocols, configuration formats, and fields will always remain compatible.
An independent core fork developed from V2Ray, with its own protocol and transport features. The core selected in the client affects which fields are accepted and which connection methods are available. If you see an unknown-field or unsupported-protocol error, first check which core is actually running, not just the app name.
A desktop GUI client for Windows, macOS, and Linux that manages nodes, subscriptions, routing settings, and core execution. Settings saved in the interface may be converted before being passed to the core, so the interface's configuration file may differ from the one the core actually runs. The desktop and classic WPF editions have different layouts; follow the menus in the version you use.
An Android GUI client that uses the Xray core for proxy connections and the system VPN interface to capture traffic from selected apps. The app version and core version are separate details, and both may matter when troubleshooting compatibility. Whether an app uses the proxy path also depends on per-app settings and system permissions.
An Android GUI client that uses the V2Fly core, an alternative when you need the behavior of that core. Its name is similar to v2rayNG, but that does not mean their protocol support and configuration compatibility are the same. Before importing a node, check that the core supports its protocol, security layer, and required fields.
The terms below refer to common JSON configuration concepts. Arrays, objects, and tag references serve different purposes; avoid assembling snippets based on field names alone.
A text format that represents data as objects, arrays, and key-value pairs, commonly used for core configuration. Standard JSON requires double quotes around keys and strings and does not allow trailing commas or comments. Valid syntax is only the first step: port types, protocol names, and field hierarchy must also match the core in use.
inbounds defines how the core accepts connections. Common fields include the listen address, port, protocol, and tag. Listening on a loopback address usually limits access to programs on the same device, so understand the exposure before changing it. If the client starts but an app has no traffic, check that the app's proxy port matches the relevant inbound.
outbounds defines how the core makes outgoing connections, including options such as proxying, direct access, or blocking. An outbound tag is an identifier used by routing rules, not the remote server address. If you change a tag, check references such as outboundTag too, or rules may no longer point to the intended outbound.
A configuration object containing routing rules and strategies that determines which outbound handles traffic entering the core. domainStrategy affects when domains are resolved to IP addresses for matching and should be considered alongside DNS settings. It does not replace the operating system proxy or handle app traffic that has not entered the core.
Core settings for connection timeouts, user-level behavior, statistics, and more. These have a different role from routing rules that select an outbound by domain or address. Before changing a timeout, identify whether the issue occurs during DNS resolution, the handshake, or data transfer; simply waiting longer will not fix mismatched connection parameters.
Domain resolution, the destination information available to rules, and outbound selection are separate steps in the same connection path.
Matches traffic based on conditions such as domain, IP, port, or inbound tag, then selects an outbound or balancer. Rules are usually evaluated in order, so a broad rule near the top can override a more specific one below it. When troubleshooting, check the conditions, order, and tag references—not just whether the domain appears in the list.
Directing traffic to different outbounds based on rules, such as sending private addresses directly and specified domains through a proxy. The result depends on rule order, available domain information, DNS results, and the default outbound. “Global” and “rule-based” modes in a client may refer to different layers; the menu label alone does not reveal the path every app will take.
A collection of IP addresses used for routing matches, usually referenced by category. It matches IP address ranges only; a match does not establish a site's operator or the region associated with its domain. Changes in DNS results, content delivery networks, or the data file can affect which rules match.
A collection of categorized domains used for routing matches, useful for applying one rule to related domains. Categories and their contents depend on the data file loaded; do not assume every tag is always available. GeoSite covers domains and GeoIP covers IP addresses. They can be used together, but they mean different things.
A system that resolves domain names to addresses and other records. The core's built-in resolver and the operating system resolver may use different paths. dns.servers lists the DNS servers available to the core, but whether they are used also depends on routing and outbound policies. Changing the DNS address does not mean every app query will automatically go through that resolver.
A mechanism that assigns synthetic IP addresses to domains and restores the domain information when a connection follows. These addresses are not the target server's real public IPs; subsequent traffic must pass through a path that understands the mapping. Changing only the DNS response without handling the connection accordingly can make the address unreachable or break the mapping.
A DNS leak occurs when queries take a different path from the one intended—for example, when a query goes through another resolver instead of the specified outbound. To assess it, check who actually sent the request and where it went, not just the resolver location shown on a website. App-level resolution, encrypted DNS, system caches, and per-app settings can all affect the results.
Importing settings, testing a connection, and routing app traffic are three separate steps. Interpret test results in light of the test method and current mode.
A way to distribute node configurations for bulk import via a link. Clients usually organize sources into subscription groups. Updates may add, remove, or replace nodes in a group, so manual changes to node settings may not be kept. Subscription URLs may contain access credentials; avoid sharing the full link in screenshots, logs, or support requests.
A set of client parameters for establishing a proxy connection, typically including the address, port, authentication details, protocol, and transport settings. The display name is just a label; it does not confirm the server's location or connection quality. Successful import only means the client recognized the format. You still need to start the connection and check the logs.
The time taken by a particular test; comparisons are meaningful only when the test method is known. A TCP connection test measures only part of port reachability, and an ICMP response does not prove the proxy protocol can authenticate. Results vary with the target, network conditions, and timeout settings. Low latency alone does not imply high download speeds.
Clients usually use this label for the time taken to make an actual request to a test address through a node. Whether the measurement includes DNS resolution, connection reuse, or the handshake depends on the client and test settings. A successful test confirms that a request to that target completed at that moment, not that other sites, apps, or later connections will behave the same way.
Proxy settings provided by the operating system to applications, usually directing requests that honor them to a local client port. Some apps use their own proxy settings or connect directly, so enabling the system proxy does not capture all traffic. It determines whether traffic enters the client; the core's routing and other settings determine where it goes next.
A mode that handles IP packets through a virtual network interface and can capture some traffic from apps that ignore system proxy settings. What it actually captures depends on system routing, permissions, DNS handling, and the client implementation; it does not mean every connection will use the proxy outbound. If problems arise, check other virtual interfaces, routing conflicts, and per-app settings.