Protocols, cores, subscriptions, and routing settings
First identify which layer a setting belongs to, then check what it needs to match. This glossary explains 30 common terms across five topic areas. Each card has its own anchor, so you can save a link or jump to a related concept.
The proxy protocol defines requests and authentication; the transport carries the messages. Similar names do not make these settings interchangeable.
VMess is a proxy protocol in the Project V ecosystem. It authenticates users by ID and has its own encryption mechanism. In common configurations, the additional ID is 0, corresponding to modern AEAD usage; this is separate from the transport choice. After importing a configuration, check the user ID, encryption method, transport, and security layer individually. A significantly incorrect system clock can also affect authentication.
VLESS is a lightweight proxy protocol that does not encrypt content on its own, so the common encryption value is none. This does not mean the entire connection is necessarily unencrypted; its security also depends on settings such as TLS or REALITY. flow is a separate setting and must match the server requirements and core capabilities. Do not apply one value to every VLESS node.
Trojan is a proxy protocol typically carried over TLS and authenticated with a password. A correct password is only one requirement; the server name, certificate trust, and transport settings must also match. If you encounter a certificate error, check the SNI, system clock, and certificate configuration. Do not treat skipping certificate verification as a routine fix.
Shadowsocks establishes an encrypted proxy connection with a pre-shared key and is often abbreviated to SS. Traditional AEAD methods and Shadowsocks 2022 use different key conventions. For example, 2022-blake3-aes-128-gcm has specific key format requirements. The client's and server's encryption methods, keys, and related extensions must match; identical password text alone does not guarantee compatibility.
Transport determines how proxy protocol messages travel over the underlying connection. Common options include TCP, WebSocket, and gRPC. With WebSocket, fields such as the path and Host often need to match the server; gRPC may require a service name. Transport is not encryption, and extra encapsulation does not guarantee a faster connection. Choose settings that match the actual configuration.
The graphical client stores settings; the core handles protocols and routing. When troubleshooting compatibility, check their versions and supported features separately.
Xray-core evolved from the V2Ray project and handles low-level tasks such as proxy connections, routing, and DNS. REALITY and XTLS Vision are common Xray features to consider, but check the specific version and combination requirements. An option shown in the client does not guarantee support in the core currently running; the core information in the logs is a better way to confirm.
V2Fly is a community project continuing the V2Ray ecosystem. Its core provides proxy protocol, transport, routing, and DNS features. It shares a history with Xray, but the projects have not evolved identically. Existing configurations can be a useful starting point for comparison, but do not assume every setting is compatible between the two. Pay particular attention to security layers and newer transport features.
v2rayN is a graphical client for Windows, macOS, and Linux that manages nodes, updates subscriptions, and configures connection modes. It translates interface options into core settings; the selected core handles the actual connection. The desktop edition and classic WPF edition differ in interface and supported platforms. When following a tutorial, use the instructions for the features in your current version.
v2rayNG is an Android client with a graphical interface that uses the Xray core, manages nodes, and routes selected traffic through Android's VpnService. The system authorization prompt sets up a local VPN interface; it does not mean every app uses the same outbound. Per-app settings, battery optimization, and background permissions can all affect which traffic is routed and how reliably the connection stays active.
v2flyNG is an Android client with a graphical interface that uses the V2Fly core and can serve as an alternative for configurations supported by that core. Its name is similar to v2rayNG, but their underlying feature support is not interchangeable. When moving nodes, recheck the protocol, transport, and security settings. Configurations that rely on Xray-specific features will not work just by changing the client name.
A subscription is a way to retrieve a set of configurations; a node is one connection configuration. A successful update, import, and connection are three different outcomes.
A subscription is usually a URL the client uses to retrieve a set of node configurations. Updating it fetches the remote list again. An update can fail because the URL has expired, the request path is incorrect, or the format is unsupported; this does not necessarily mean every existing node is unusable. Subscription URLs may contain credentials, so remove the full URL and any sensitive parameters before sharing screenshots or logs.
A node is a set of connection parameters in a client, usually including an address, port, proxy protocol, authentication details, and transport and security settings. It is not necessarily a physical server; one server may offer several configurations. A node name is just a label for identification and does not prove its location, availability, or performance.
A share link represents a single node configuration with a prefix such as vmess:// or vless://. Clients can import links from the clipboard or a QR code. Supported link formats vary across protocols, clients, and versions. Check the key settings after import, and do not share links publicly: passwords and user IDs in them are connection credentials.
Some subscriptions wrap text in Base64 encoding; decoding them may reveal a set of share links. Base64 is encoding, not encryption, so it does not protect node credentials. The appearance of the encoded text alone does not reveal its contents. Native JSON configurations and these subscriptions have different structures, so use the appropriate import option in the client.
Connection latency usually refers to the time measured when a request is sent through a selected node to a test target. Whether the measurement includes a handshake or the full response depends on the client. It is different from TCP latency measured only to a target port, and it is not download bandwidth. For a useful comparison, use the same test address and method, and consider how the connection performs for your actual apps.
First confirm that traffic reaches the core, then check which rule matched. DNS queries and application connections may also take different paths.
Routing rules select an outbound for a connection based on conditions such as domain, IP, or port, for example direct, proxy, or blocked. Rules are usually checked in order, so a broad rule near the top can override more specific rules below it. Domain strategy also affects whether an IP is resolved for matching; check it alongside rule order.
GeoIP is a collection of IP addresses grouped by region or category that routing rules can reference. A match depends on the destination IP and the data file in use; it does not precisely identify where a service is physically located. Server address changes or database updates can alter the result, so record the resolved IP when troubleshooting.
GeoSite is a collection of domain rules grouped by category, making it easier to configure routing for many domains at once. Category names and coverage depend on the data file, and may vary between sources or versions. Domain collections are not IP collections. If a request does not match, check rule order, how domains are obtained, and which data file is in use.
Routing sends different connections to different outbounds according to rules, so selected requests can use a direct connection, proxy, or another handling method. It does not automatically split one download across multiple nodes or increase bandwidth. Successful routing depends on traffic capture, rule matching, and the default outbound. Check each separately rather than relying on the mode name.
TUN mode captures IP packets through a virtual network interface and can cover apps that do not follow system proxy settings. It requires appropriate system permissions, routing table, and DNS settings; capabilities vary by client. If local network access stops working after enabling it, check private IP rules and other virtual network interfaces instead of automatically switching everything to proxy mode.
A system proxy registers a proxy address with the operating system, allowing apps that follow the setting to send requests to a local proxy. Some apps have their own proxy settings, while others may ignore the system proxy. It does not capture all traffic and is not the same as a routing rule. When closing the client, check that the system proxy has been restored if needed.
DNS resolves domain names to IP addresses and other records, usually before an app connects. The operating system, browser, and proxy core may use different resolvers, so changing DNS in the client may not affect every query. To troubleshoot, check which component performs the lookup, which outbound carries the query, and how the returned address is used for routing.
FakeDNS returns a synthetic IP address to an app and stores its mapping to the original domain, allowing the core to restore the destination for a later connection. It is not a regular public DNS server; the corresponding connection must be captured by a compatible core. Mismatched DNS, routing, or cache settings can break the mapping. Watch for stale resolution caches after changing modes.
A DNS leak occurs when a query does not follow the intended path—for example, when an app connection uses a proxy but DNS is sent over another network interface. Assess it against the intended policy; not every local lookup is a problem. Check browser-level encrypted DNS, system resolution settings, and interface priority. Encrypted DNS does not necessarily mean the query passes through the proxy.
Use the server-provided configuration as the source of truth for security settings. Certificate names, protocol negotiation, and fingerprint settings serve different purposes and cannot replace one another.
TLS is a security protocol that provides transport encryption and authentication. During the handshake, the parties negotiate parameters and verify the server's identity. For connections using certificates, check the trust chain, validity period, and name match. Certificate verification and proxy protocol authentication are separate steps. Disabling certificate verification weakens identity checks; it does not fix an incorrect name or certificate configuration.
REALITY is a transport security scheme in the Xray ecosystem, not a standalone proxy protocol. A common setup pairs VLESS with REALITY. Match the public key, shortId, server name, fingerprint, and other parameters to the server configuration. Its authentication does not work like ordinary TLS certificate setups. Check core version and field support before using it.
Vision is a flow-control scheme in Xray for specific VLESS connection combinations. Clients commonly use xtls-rprx-vision as the flow value. It has requirements for the transport and security layer, so it cannot be enabled with every combination. Use it only when explicitly configured on the server and supported by the selected core; it is not a general-purpose speed boost.
SNI is an extension in TLS ClientHello that indicates the server name, allowing the server to select the appropriate configuration and certificate. The connection address can be an IP while the name is used in the handshake; they do not have to be identical, but both must meet the server's requirements. SNI and HTTP Host are separate fields, so changing one does not automatically fix the other.
A client fingerprint describes the combination of parameters in TLS handshake messages, including extensions and cipher suites. A core that supports fingerprinting can construct a handshake in a specified style, such as chrome; this does not mean the device is actually running that browser. Fingerprint settings do not replace certificate verification or node authentication, and different core versions may not produce identical handshakes.
ALPN is an extension that negotiates the application-layer protocol during the TLS handshake. Common values include h2 and http/1.1. It tells both parties which application protocol to use next and is separate from proxy protocols such as VMess and VLESS. An unsupported value can cause the handshake or subsequent requests to fail, so follow the actual configuration.