Client menu and configuration field guide

V2Ray Terminology Guide

First, distinguish protocols, cores, and transports. Then look at subscriptions, routing, and DNS.

Not sure what a setting does? Find it in one of the six categories below. These definitions explain configuration concepts; exact menu locations and field support depend on your client and core.

v2rayN GUI client Xray connection core VLESS + TLS protocol and security layer

Quick start guide Installation and configuration

Protocols and transports

A protocol defines how proxy data is exchanged; a transport defines how that data is carried. Both ends need a compatible combination.

VMess: VMess is a proxy protocol in the Project V ecosystem. It handles user identity, authentication, and data encryption, but is not a transport method. After importing a configuration, check the user ID, server port, and transport settings such as TCP or WebSocket separately. If using TLS, check the related security settings too. A protocol name alone won't explain a connection failure; a system clock that's out of sync can also affect authentication.; Protocols & Transports · Common field: protocol

VLESS: VLESS is a lightweight proxy protocol that does not provide encryption on its own. It is typically used with transport security such as TLS or REALITY. The client’s user ID, encryption setting, and flow are separate parameters; don't copy values from another protocol into these fields. Support for a particular flow or security combination depends on the core in use. A client accepting a link does not guarantee compatibility.; Protocols & Transports · Related terms: TLS, REALITY

Trojan: Trojan is a proxy protocol typically run over a TLS connection and authenticated with a password. Its settings should not be mixed up with configurations that use a UUID as the user identifier. When troubleshooting, check the password, address, port, transport, and TLS settings together. Even with the correct password, a certificate name mismatch can prevent the secure connection from being established.; Protocols & Transports · Authentication field: password

Transport: A transport describes how proxy protocol data is carried over a connection, for example over TCP, WebSocket, or gRPC. It is a different layer from protocols such as VMess and VLESS. WebSocket paths and Host values, as well as gRPC service names, must match the server settings. Changing the transport is not a standalone performance tweak: it won't work unless the server has a matching transport endpoint.; Protocols & Transports · Common field: streamSettings

Cores & Ecosystem

The client generates the configuration; the core handles connections. Updating one does not mean the other has been updated.

Project V: Project V is an open-source network proxy ecosystem built around V2Ray. It is neither a subscription nor a provider of remote servers. GUI clients handle user interaction, cores manage inbounds, outbounds, and routing, and rule data supplies matching lists. When troubleshooting, identify the layer involved first to avoid mistaking a subscription response error for a core defect.; Cores & Ecosystem · Project background

V2Fly: V2Fly is the community behind V2Ray-related projects. A v2fly core in a client usually refers to the V2Ray core maintained by this community. v2flyNG is the name of a GUI client, not a core. Before choosing this core branch, check which protocols and transport fields it supports; don't assume features added to another branch are available here.; Cores & Ecosystem · V2Ray core

Xray: Xray is an independently developed core project with shared technical roots with V2Ray and its own protocol and transport implementations. For configurations using REALITY or a specific flow, first confirm support in the Xray core version you're running. After switching cores, check the generated configuration and startup logs. Similar field names do not guarantee full compatibility.; Cores & Ecosystem · Core type

GUI client: GUI clients provide interfaces for managing subscriptions, choosing servers, setting the system proxy, and viewing logs. A bundled core typically handles the actual connections. v2rayN targets desktop platforms, while v2rayNG and v2flyNG target Android; their menus don't have to match. To determine whether a feature works, check both that the client can generate the relevant configuration and that the core can run it.; Cores & Ecosystem · Client and core roles

Compare the three clients

Subscriptions and servers

Identify what you're importing before choosing an import option. Subscription URLs, share links, and complete configurations are not interchangeable.

Subscription: A subscription lets a client retrieve a set of server configurations from a URL. When you update it, the client requests and parses the response again. Base64-encoded link lists, structured subscriptions, and complete configurations may each require different handling; a URL opening in a browser does not mean its contents can be imported. Subscription URLs may contain access credentials, so redact the full URL before sharing screenshots or logs.; Subscriptions & Servers · Common entry: subscription group settings

Server: A server usually means a set of parameters needed to connect to a remote service, including its address, port, authentication, transport, and security settings. A name in the list is just a label; it does not confirm the server's location, supported protocols, or connection quality. If something goes wrong, open the configuration details and check each field rather than renaming the entry or changing groups to see whether anything changed.; Subscriptions & Servers · Also called a server in clients

Real connection latency: Real connection latency usually refers to the time a client measures when accessing a specified test destination through a proxy outbound. The test path may include authentication, a security handshake, and the destination's response. This differs from a TCP test that only checks whether a port is reachable, and it cannot be converted directly into sustained download speed. For meaningful comparisons, use the same test destination and network conditions. A timeout at one destination doesn't mean all connections will fail.; Subscriptions & Servers · What test results tell you

Routing and traffic splitting

Match conditions, rule order, and outbound tags determine the result. Correct rules still need usable data files.

Routing rules and traffic splitting: Traffic splitting selects different outbounds based on conditions such as domain, IP, or port; routing rules define those conditions. Rules are typically evaluated in order, so a broad rule near the top can prevent more specific rules below it from matching. Clients often use direct, proxy, and block as tags or action names. References in the generated configuration must match the outbounds actually defined.; Routing & Traffic Splitting · Common field: routing.rules

GeoIP: GeoIP is a categorized collection of IP addresses. Routing expressions such as geoip:private can use it to match destination addresses. It relies on the relevant rule data; the client does not measure each address's location in real time. For domain-based connections, whether IP rules can match also depends on the domain resolution strategy, so check domainStrategy as part of the full path.; Routing & Traffic Splitting · IP address lists

GeoSite: GeoSite is a categorized collection of domains. Entries such as geosite:cn and geosite:category-ads-all can be used in domain-based routing rules. Available categories and their contents depend on the installed rule data, not just what a category name seems to mean. GeoSite does not directly indicate a server's geographic location. If a rule file is missing or a category is misspelled, check the core startup logs first.; Routing & Traffic Splitting · Domain lists

domainStrategy: This refers to the domain handling strategy in routing, which controls whether the target domain is resolved during routing matches. AsIs primarily keeps the domain for matching; IPIfNonMatch attempts resolution if no domain rule matches, then checks IP rules. This is not a global switch for all DNS behavior. After changing it, also check core DNS, outbound settings, and how the application resolves domains.; Routing & Traffic Splitting · Domain handling during routing

Client features

Traffic capture and domain resolution are separate concerns. They differ in the traffic they cover, the permissions they need, and where to troubleshoot.

System proxy: A system proxy registers a local proxy address and port with the operating system. It mainly affects applications that follow that setting and does not automatically capture all network requests. In v2rayN, automatic system proxy configuration requires a local inbound to be listening correctly; clearing the system proxy removes the related operating system settings. Some apps use their own proxy settings or connect directly, so check those individually rather than relying only on the system proxy toggle.; Client Features · System-wide proxy settings

TUN mode: TUN mode receives traffic through a virtual network interface and forwards it according to rules using components bundled with the client. It is not a proxy protocol such as VMess or VLESS. Availability depends on system permissions, routing, and the implementation; desktop clients may need elevated privileges, while Android typically requires VPN connection permission. After enabling it, check LAN access and DNS. Running multiple programs that capture network traffic at once can cause conflicts.; Client Features · Virtual network interface

DNS: DNS resolves domain names to IP addresses and other records. The system, browser, and proxy core may each use a separate resolution path. Setting DNS servers in the core does not automatically route encrypted DNS in the browser, or every app's DNS requests, through the same path. When troubleshooting, check separately whether the domain resolves, whether the returned address is reachable, and which outbound carries the DNS request.; Client Features · Domain name resolution

FakeDNS: FakeDNS returns a synthetic IP address for a domain and stores the mapping so the original domain can be recovered when the connection is handled. It depends on DNS interception working together with traffic capture. Don't treat a synthetic address as a regular public IP for programs that cannot use the mapping. After switching or disabling this mode, apps may still have the old address cached; check the cache and resolution path too.; Client Features · Synthetic IP mapping

Security and obfuscation

Check the connection address, authentication settings, and certificate name separately. Establishing a secure connection does not guarantee the routing result is what you expect.

TLS: TLS is a security protocol that provides transport encryption and authentication. It can protect many different proxy protocols. Check the certificate's validity period, trust chain, server name, and system clock—not just whether the TLS option is on. Disabling certificate verification weakens authentication and should not be a long-term fix. If the name doesn't match, correct the configuration or the server certificate.; Security & Obfuscation · Transport security

REALITY: REALITY is a transport security mechanism in the Xray ecosystem. The client and server need matching parameters, and the core in use must support it. Common settings include serverName, public key-related parameters, shortId, and fingerprint; field names may differ between versions. REALITY is not a universal toggle you can freely swap in for TLS. Replacing a standard TLS configuration and expecting the connection to work is not enough.; Security & Obfuscation · Requires the Xray core

SNI and serverName: SNI is an extension that carries the server name in the TLS handshake. The serverName setting usually affects the name sent and certificate name verification. The server address determines where to connect; serverName is used for name handling in the security layer, and the two values do not have to match. Use the name supplied by the server; don't enter a subscription label or an arbitrary domain here.; Security & Obfuscation · Server name

DNS leak: A DNS leak occurs when queries take an unexpected resolution path—for example, web requests go through a proxy while domain lookups still use a separate system path. Define the expected path before judging a test result; seeing a resolver's name on a test page alone does not prove there is a problem. Check browser encrypted DNS, the system resolver, core DNS outbounds, and the scope of TUN traffic capture, one layer at a time.; Security & Obfuscation · Check the resolution path

Where to go next

Once you've identified the relevant concepts, move on to the practical guides. For import issues, check the content format first; for connection problems, start with the core logs; for routing issues, check rule order and the DNS path. Avoid changing several settings at once so you can tell which change made a difference.

Import subscriptions and connect Installation and setup for all platforms Xray vs. V2Fly