V2Ray / Quick Reference
Look up configuration terms and tell proxy protocols, cores, transports, and security layers apart.
A node usually combines a protocol, a transport, and security layer settings. These terms are not interchangeable. This page groups terminology into six categories, with each card explaining what a term does and where it is commonly confused with another. Actual support depends on the client, core version, and server configuration.
For help choosing a protocol, see the protocol reference. For step-by-step import instructions, see Getting Started.
A proxy protocol defines how a client and server authenticate and exchange proxy data. Matching protocol names alone do not mean the full connection configurations match.
VMess is a proxy protocol in the Project V ecosystem with authentication and data protection mechanisms. In addition to the server and port, the user ID, transport, and security layer settings must match. Authentication depends on system time, so a significant clock difference can also cause connection failures. Checking the address alone is not enough.
Compare protocol options →VLESS is a lightweight proxy protocol that handles proxy requests and user identification but does not encrypt payloads on its own. Deployments typically pair it with a security layer such as TLS or REALITY; selecting VLESS does not mean encryption is configured. Some flow-control options also require a specific core and parameter combination, so check each setting after importing.
VLESS and REALITY: what’s the difference? →Trojan typically uses TLS connections and password-based proxy authentication. A correct password is only one requirement: the server name, certificate validation, and transport must also match the server configuration. If a handshake fails after importing a link, troubleshoot TLS settings and protocol authentication separately rather than repeatedly changing the password.
What TLS does →Shadowsocks, commonly abbreviated as SS, is an encrypted proxy protocol configured with a pre-shared key. Encryption methods and protocol generations can differ in key format and implementation requirements, so the client must support the method specified by the server. Seeing Shadowsocks in both interfaces does not guarantee compatibility, and keys in different formats are not interchangeable.
Check protocol compatibility →Clients handle the interface and configuration management; cores handle connections and routing. Ecosystem names are not necessarily software package names.
Project V provides context for understanding V2Ray's origins and the design of modular proxy tools; it is not a proxy protocol. When discussing this ecosystem, clarify whether you mean a core program, a protocol implementation, or a graphical client. When you find a V2Ray-related name, first identify its role instead of choosing an installer based on the name alone.
How clients and cores differ →Xray is a proxy core developed from the V2Ray codebase, with its own implementations of protocols, transports, and security features. Features such as REALITY require support in the relevant implementation and version; other cores cannot be assumed to accept the same configuration. Before switching cores, check that the client can generate the fields the new core needs, and keep the original working configuration.
Compare proxy cores →V2Fly is a community project that continues to maintain V2Ray-related implementations. A V2Fly core option in a client usually refers to the core program maintained by the project. V2Fly and Xray share some history, but their feature development, fields, and configuration formats are not necessarily the same. v2flyNG is the name of a graphical client, not another name for the V2Fly core.
What the Xray core does →Graphical clients provide interfaces for importing subscriptions, choosing nodes, editing routes, and integrating with the system; the core handles network traffic. v2rayN is for desktop platforms, while v2rayNG and v2flyNG are for Android. Their specific capabilities also depend on the integrated core. A field appearing in the interface does not necessarily mean the selected core or server supports that combination.
Compare clients by platform →Proxy protocols, transport encapsulation, and security layers serve different purposes. Choosing just one does not define the full connection setup.
TLS provides encryption, integrity protection, and authentication. The server name in a proxy configuration often plays a role in the handshake and certificate validation. The connection address and the name used for validation can differ, but both must match the server deployment. Disabling certificate validation weakens authentication; if a certificate error occurs, first check the name, certificate chain, and device clock.
Understand security layer settings →REALITY is a transport security mechanism in the Xray ecosystem, not a standalone proxy protocol on the same level as VMess or VLESS. A common configuration uses VLESS and REALITY together: one specifies the proxy protocol, the other the security layer. Set the public key, server name, short ID, and other fields as required by the server; simply renaming a standard TLS configuration will not work.
Back to the VLESS glossary entry →Transport describes how proxy data is carried or encapsulated, such as directly over TCP or through WebSocket or gRPC. Required paths, service names, and request headers vary by transport, and not every proxy protocol and security layer can be combined freely. Even when options have the same name, check which combinations the client and server cores actually support.
Compare protocol and transport combinations →Multiplexing carries multiple logical data streams over fewer underlying connections, reducing some of the overhead from repeatedly establishing connections. It is not a universal speed boost; if an underlying connection is impaired, multiple requests may be affected at once. Implementations and compatibility requirements vary by core, so decide whether to enable it based on the protocol combination, network conditions, and real-world testing.
Understand the limits of connection tests →A single configuration and a collection of configurations have different entry points. Successful import, successful updates, and a working connection are separate checks.
A subscription URL is an entry point for retrieving a set of connection configurations. The client requests the URL and parses the response. Because the URL often contains an access token, treat it as sensitive information and avoid sharing it in public screenshots or support requests. Client support for subscription formats and extended fields varies; being able to access a URL does not guarantee that its contents can be imported correctly.
How to import a subscription →A node is a common client term for an available connection configuration, typically including server, port, authentication, transport, and security layer settings. It does not necessarily correspond to a dedicated physical server, and its display name is just a label. To tell whether configurations are duplicates or equivalent, compare their actual parameters rather than their names, region labels, or list positions.
How node share links work →A share link encodes a connection configuration as a specific URI, such as text beginning with vmess://, vless://, or trojan://. It usually represents a single configuration, unlike a subscription URL used to retrieve a set of configurations on a regular basis. A QR code is simply another way to present the text; importing it still requires a client that supports the protocol and fields.
A subscription update fetches remote contents again and uses them to refresh local connection configurations. It does not automatically upgrade the client or core. Updates may change node names, settings, or the available list, so check how your client handles local edits before modifying subscription nodes. If an update fails, first distinguish between a failed request, an unsupported response format, and an unsupported field.
Troubleshoot installation and configuration →Domain matching, IP matching, and DNS resolution affect one another. When checking rules, consider their order, match conditions, and the final route together.
A routing rule selects an outbound route for a connection based on its domain, destination IP, port, or other criteria. Many implementations check rules in order, so an earlier match can prevent later rules from taking effect; unmatched traffic follows the default policy. When troubleshooting, first confirm that the traffic reaches the core, then check the matching conditions. Rule names alone do not show what will happen.
How routing rules are selected and matched →GeoIP usually refers to a collection of IP addresses grouped by region or predefined category. geoip:cn is a common reference. Classification depends on the data source and its update schedule; it is not a live measurement of a server's physical location. For shared IPs or services with changing infrastructure, the IP category may not reflect how you expect a particular site to be treated.
GeoSite is a collection of domain rules grouped by service, purpose, or another category. geosite:cn is a common reference. Category labels are not discovered automatically by the core; they must be provided by a compatible data file, and their coverage depends on the source. GeoSite matches domains, while GeoIP matches IP addresses; a domain category does not represent every IP used by the corresponding services.
Traffic routing directs different traffic to routes such as direct, proxy, or block according to a policy. It is not a new proxy protocol. A rule mode in the interface usually enables a set of preset routes, but mode names and exact behavior vary between clients. A routing mode also does not mean all apps use the proxy; traffic entry is still determined by system proxy settings, TUN, or app-specific configuration.
How traffic reaches the client →DNS resolves domain names to IP addresses and other records. In a proxy setup, the app, operating system, and core may all take part in resolution. The chosen resolver, the route used for queries, and whether routing rules operate on domains or IPs all affect the result. Changing a single DNS address cannot guarantee that every app follows the same path; also check caches, browser settings, and the core's DNS policy.
Understand unexpected DNS routing →Understand what each mode captures before choosing one. Test results help diagnose issues but do not replace checks in real apps.
A system proxy is a proxy setting provided by the operating system for apps to read, usually pointing to a local address and port where the client is listening. Only apps that follow this setting send requests through it, so enabling the system proxy does not capture all network traffic. App-specific proxy settings, independent network stacks, and other proxy tools can all change the route traffic takes.
How to enable the system proxy →TUN mode uses a virtual network interface to receive IP packets and pass them to a proxy component, generally covering more traffic than system proxy settings alone. It may require additional permissions and coordinated routing and DNS settings, and does not guarantee that every device connection goes through the proxy. When using it alongside other virtual networking tools, check for routing conflicts and loops in the proxy's own traffic.
Capture modes vs. routing policies →FakeDNS assigns a synthetic IP from a reserved address pool to a domain and saves the mapping so the domain can be recovered when the traffic is processed later. The returned address is not the destination server's real IP; a compatible component must handle it when an app connects. FakeDNS requires compatible settings for its address pool and routing. If a synthetic address is sent through a path that cannot resolve the mapping, the connection may fail.
How DNS and routing interact →A DNS leak occurs when a query takes a different path from the one intended, such as a query planned for the core still being sent by the system resolver. Before judging whether a leak occurred, identify the expected resolver, transport, and query route; the resolver's displayed region alone is not enough. A browser's own encrypted DNS, app-specific resolution, and multiple network interfaces can all result in different paths.
Troubleshoot DNS resolution and connection issues →Latency is the time taken by a particular measurement, but TCP connection setup, ICMP probes, and HTTP requests measure different processes. A fast TCP connection does not mean proxy authentication, the TLS handshake, or access to a destination website will succeed. When comparing configurations, use the same test method and target, and consider reliability and real app performance rather than ranking by a single result.
What proxy connection tests measure →Proxy latency usually measures how long a client takes to send a request to a test address through the selected proxy configuration. The exact measurement scope depends on the implementation. It is closer to a real proxy request than simply probing a server port, but still reflects only that target and the network conditions at the time. If a test fails, use logs to distinguish DNS, handshake, and request-stage issues. A successful test does not mean every site will be reachable.
How to verify a connection →