A guide to 24 common terms, organized by configuration layer. First distinguish the connection protocol, the core that runs it and the traffic path, then use client settings to narrow down an issue.
New to setup? Start with the setup guide. Already seeing a specific error? Go straight to troubleshooting. Each term on this page can also be linked to directly.
protocol / transport
Protocols define authentication and forwarding; transport settings determine how the data is carried.
VMess is a proxy protocol in the Project V ecosystem, with user authentication and data protection. Servers commonly identify users by UUID. A connection requires a matching user ID as well as matching transport settings and related parameters. Clock skew can affect authentication, so check device time synchronization if handshakes keep failing.
VLESS focuses on lightweight authentication and forwarding and does not provide general-purpose encryption on its own. It is commonly used with TLS or REALITY. In a configuration, protocol, flow and transport security are separate fields; seeing VLESS alone does not mean the server settings are complete. Capabilities depend on the core implementation, and client and server parameters must match.
Trojan typically runs over TLS and authenticates users with a password; TLS provides transport protection. Correct address, port and password do not guarantee certificate validation will succeed—the server name must also match the deployment. When troubleshooting, distinguish password authentication errors from TLS handshake failures and destination connection failures.
This refers to how a proxy protocol is carried, such as over TCP or WebSocket. In Xray configuration, it usually involves streamSettings. When using WebSocket, the path and related request parameters must also match the server; changing only the transport name is not enough. TLS and REALITY are transport security settings, not transport methods. Switching protocols will not fix mismatched settings.
ecosystem / core
The ecosystem, core and graphical interface each have a different role. When troubleshooting compatibility, check which core is actually running.
Project V refers to the ecosystem built around modular network proxy tools, with V2Ray as one of its key project names. It is not the name of a specific desktop app or a guarantee that all related clients have the same capabilities. When discussing configuration, identify the client, the core it runs and the feature involved instead of using “V2Ray” as a catch-all.
Xray-core is a proxy core that handles protocols, inbounds and outbounds, routing and DNS. Graphical clients can use it to run connections. Check the actual core version and settings for features such as VLESS, REALITY and Vision; the presence of an option in the interface is not enough. For background on the two core development lines, see Xray-core vs. V2Fly: Key Differences.
V2Fly continues the V2Ray project's community and core development line. It has historical ties to Xray-core, but features and configuration details have diverged over time. A configuration accepted by one core may include fields the other does not support. On Android, v2flyNG is a graphical client option for this ecosystem; check that it supports the protocols required by your subscription before choosing it.
Graphical clients provide controls for server lists, subscription groups, proxy toggles and logs—for example, v2rayN on desktop and v2rayNG on Android. They typically generate core configuration from user settings, so menu labels may not match JSON fields exactly. Updating the client app, the core or the rule files are separate actions; check each one when troubleshooting compatibility issues.
interface / traffic entry
First check whether the app sends traffic to the client, then check which outbound the core uses.
The system proxy adds a local proxy address to the operating system's settings and affects only apps that read them. Some command-line tools, standalone network components and apps with their own proxy settings will not follow it automatically. If a browser connects directly after the system proxy is enabled, check the app's proxy settings and local listening port before assuming the remote server is down.
TUN mode receives IP packets through a virtual network interface and passes traffic to the proxy, usually covering a different set of apps than the system proxy. It depends on system permissions, routing and DNS working together; turning it on does not confirm the entire traffic path is in place. When using other virtual networking software, check for route conflicts, interface selection and local network access.
An inbound is an entry point where the core accepts connections, such as a local HTTP or SOCKS listening port used by a browser. It corresponds to inbounds in the configuration. The listening address determines which devices can reach it, and the port must match the app's settings. For local use only, listen on the local interface; before allowing LAN access, define access controls and authentication requirements.
An outbound determines how the core sends traffic along the next leg of its route: through a proxy, directly or by blocking it. It corresponds to outbounds. Routing rules refer to an outbound using outboundTag; a tag is only a name, so naming it direct does not make it connect directly. Rule references must match outbound definitions to avoid configuration errors or unexpected routes.
subscription / measurement
Getting configurations, connecting to a server and checking test results are three separate steps.
A subscription is a URL or data source for retrieving server configurations in bulk. Updating it typically refreshes the server list in the associated group. A successful update means the request and content were processed; it does not mean a server has connected or that every server works. Subscription URLs may contain access credentials, so don't share them publicly. If an update fails, use the subscription update troubleshooting guide to check the URL, network and format.
A server is a set of connection parameters in the client, usually including an address, port, protocol, authentication, transport and security settings. Its display name is for identification; a region in the name does not determine the server's actual location or route. If required settings such as the server name or public key are missing after import, a reachable address and port may still not be enough to complete the handshake.
Latency is the time a particular test takes to complete a round trip. Before interpreting the result, check what the test actually measures. A successful TCP connection to a port shows only that the port was reachable at that moment; it does not verify a full proxy request. Lower latency also does not mean higher throughput: download speeds depend on bandwidth, packet loss, the destination service and network congestion.
Real connection latency usually measures how long a request takes when sent through the selected proxy configuration; the exact method depends on the client. It covers more of the actual connection path, but results still depend on the test target, timeout and current network conditions. Don't mark a server unusable based on one failed test; check the logs and try other targets. For a first-time setup, see the first connection checklist.
routing / name resolution
Rules choose the route; DNS resolves names. They can affect each other, but they are not the same function.
Traffic routing selects an outbound for a connection based on conditions such as domain, IP, port or inbound. Rules are generally checked in order. A broad rule placed too early can prevent later, more specific rules from matching; check the default outbound as well. domainStrategy affects when domains are resolved to IPs for matching. For example, IPIfNonMatch tries resolving the domain to an IP and matching it after no domain rule matches.
GeoIP is a collection of IP addresses grouped by tag and can be used in matching expressions such as geoip:private. A tag represents address ranges included in the database, not a live measurement of a connection's physical location. Whether a domain-based connection matches an IP rule also depends on the resolution strategy. After updating the data, confirm that the rules reference tags that are available.
GeoSite is a collection of domains grouped by tags such as purpose, service or region, often referenced in forms like geosite:cn. It helps match domains; it does not resolve them to IP addresses or guarantee coverage of every domain used by a service. Available tags depend on the rule database in use. For file updates, see the GeoIP and GeoSite update guide.
FakeDNS returns synthetic IP addresses to apps and keeps an internal mapping to the original domains, allowing later connections to be handled by domain. These are not the destination websites' real IP addresses; connections must pass through a processing chain that can restore the mapping. Enabling DNS handling without traffic interception can break access. After switching modes, also watch for stale DNS caches in the system and apps.
security / verification
Check authentication, transport encryption and the DNS path separately; one toggle cannot verify them all.
TLS establishes an encrypted transport channel and uses certificates and other mechanisms to verify the peer's identity. The server name, certificate chain and system time all affect verification. Do not set serverName to an unrelated domain. For certificate errors, check the name, time and server configuration instead of treating certificate verification bypass as a long-term fix.
REALITY is a transport security mechanism in the Xray ecosystem, commonly used with VLESS; it is not a standalone server protocol. Client parameters such as the server name, public key and short ID must match the server requirements. Changing only the security type to REALITY does not complete a migration. For details on the handshake and requirements, see How REALITY and XTLS Vision Work.
Vision is a VLESS flow-control mode commonly represented by xtls-rprx-vision, used mainly to optimize handling of eligible TLS traffic. It requires a supported transport and TLS or REALITY, and must be supported by both client and server. It is neither a standalone protocol nor a universal speed boost; mismatched settings typically cause connection or handshake failures.
A DNS leak occurs when domain lookups do not follow the intended resolution path—for example, when a query that should be resolved by a specified remote server instead goes over the local network. Check system DNS, browser secure DNS, built-in client DNS and routing rules together; a resolver name shown by a test page is not enough. If the configuration intentionally allows some domains to resolve locally, that may be expected. The key is whether actual behavior stays within the intended boundaries.
Identify the layer involved, then check its settings. Successful import, reachable ports and successful proxy requests are separate states that must be verified independently.
If you haven't made your first connection yet, start with the subscription import and proxy mode guide. Follow the steps to check the configuration, choose a server and verify app requests. If the connection works but some apps are not using it, check system proxy, TUN, inbounds and routing first instead of repeatedly changing unrelated fields.
For timeouts, DNS failures or client errors, use the troubleshooting guide to diagnose the symptoms. Before sharing logs, remove subscription URLs, user IDs, passwords and other authentication details. Keep the error type, the stage where it occurred and relevant setting names.