Settings reference · 25 common terms
V2Ray Glossary
Protocols, cores, and proxy settings
Understand the concepts before changing settings. Look up the options you see in your client; if a connection fails, use the Troubleshooting guide to identify where the problem occurs.
VMess / VLESS
Xray / V2Fly
TUN / DNS
Protocols and Transports
A protocol defines authentication and data exchange; a transport carries the data, and a security layer protects the connection. Check each type of setting separately when importing a profile.
- VMess
- A proxy protocol in the V2Ray ecosystem that authenticates connections using parameters such as a user ID and provides protocol-level data protection. Profiles typically also include the remote address, port, transport, and security layer. A correct user ID alone is not enough to connect. When importing a VMess share link, retain its original settings; if authentication fails, also check that the device clock is accurate.
- VLESS
- A lightweight proxy protocol that does not encrypt traffic on its own; deployments typically pair it with a security mechanism such as TLS or REALITY. The user ID, transport type, and flow settings must match the server and should not be copied from another profile. When you see VLESS, check the security layer and transport settings too—protocol name alone does not determine compatibility.
- Trojan
- A proxy protocol that typically runs over TLS and uses password authentication. A successful connection depends on the correct password, server name, certificate verification, and transport settings. For certificate errors, first check the server name and device clock. Disabling certificate verification changes the connection's trust requirements and should not be a routine fix.
- REALITY
- A transport security mechanism supported by Xray, not a standalone proxy protocol on the same level as VMess or VLESS. The client may need a public key, server name, shortId, fingerprint, and other settings; the server determines the required combination. If the handshake fails after import, check these fields and core support. Changing the local listening port alone will not fix it.
- Transport
- The channel used to carry proxy protocol data, such as raw TCP, WebSocket, or gRPC. Labels may vary across cores and versions. The path, Host, or service name are connection parameters for the relevant transport, not free-form notes. Transport types are not speed tiers: match the server configuration first, then evaluate performance with real requests.
Cores and Ecosystem
The graphical interface handles user interaction; the proxy core does the actual work. To determine whether a feature is available, check support in both the client and the core.
- Project V
- A project ecosystem built around network communication tools, with V2Ray as a core project. The term “V2Ray client” often refers to a graphical tool for related protocols and cores; it does not mean those tools belong to the same software package. Understanding this distinction helps clarify what is affected by an interface update, a core update, or a change to the remote server configuration.
- V2Fly
- A community project that maintains the V2Ray core and develops its functionality and configuration support. v2flyNG is an Android graphical client that uses the V2Fly core. Similar protocol names do not mean every extension field is interchangeable. If a profile is incompatible, check support for the core version in use rather than comparing client names.
- Xray
- A proxy core project derived from the V2Ray technology ecosystem, supporting multiple protocols, transports, and security mechanisms. v2rayNG uses this core. Xray and V2Fly share some concepts, but differ in extensions and configuration details. A setting that works with one core may not work after switching, especially security layer and flow settings.
- Client and Core
- Clients such as v2rayN provide subscription management, server selection, and settings. The core handles listening, connections, routing, and traffic forwarding. An open interface only shows that the graphical app is running; it does not confirm that the core started successfully. If all connections fail, check the core startup logs and listening port before investigating the remote server or local settings.
- Inbound and Outbound
- Inbound receives traffic from local apps or a virtual network interface; outbound describes how that traffic is sent onward. A profile can contain multiple inbounds and outbounds, with routing rules choosing where each flow goes. The
outboundTagin a rule points to an outbound tag, which must match a tag defined in the profile. It is not a server alias or a free-form description.
Client Features
The proxy entry point determines which traffic reaches the client; routing determines what happens next. Enabling a mode does not mean every app will use the same outbound.
- System Proxy
- The proxy address settings the operating system provides to apps, usually pointing to an address and port the client listens on locally. Only apps that honor these settings will use the proxy; apps with their own network settings may take a different route. After enabling the system proxy in v2rayN, confirm that the core is running. “Automatically configure system proxy” refers to changing the system settings, not automatically selecting a server.
- TUN Mode
- A mode that receives IP-layer traffic through a virtual network interface, useful for apps that cannot be configured to use a proxy or ignore the system proxy. It usually requires appropriate permissions and correct routing, DNS, and loopback exclusion settings. TUN expands the scope of captured traffic; it does not automatically send all traffic through the proxy. If other virtual networking software is running, check for routing conflicts too.
- Local Listening Port
- The port where the client accepts connections from apps on the same device. Apps must use the matching proxy type and port number. The
10808value often shown in tutorials is only a setting to verify; use the port configured in your client. If the port is already in use, the core may fail to start. Allowing devices on the local network to connect also involves the listening address and firewall—not just changing the port.
- Per-App Proxy
- A feature that controls whether traffic from each app enters the proxy service. In v2rayNG, it is usually used with VPN mode. First check whether the list means “these apps use the proxy” or “these apps bypass the proxy”; the two settings are not interchangeable. The list controls which apps are captured, while routing rules may still direct their traffic after it enters the service. After making changes, restart the connection as prompted and test again.
- Mux Multiplexing
- A mechanism that lets multiple logical connections share fewer underlying connections, potentially reducing repeated connection setup overhead. If an underlying connection is congested or dropping packets, requests sharing it may affect one another. Mux is not a universal speed boost. Decide whether to enable it based on the protocol, core, and use case. To compare results, keep the server and test target the same and change one setting at a time.
Subscriptions and Servers
First identify where a profile came from, then distinguish reachability, request latency, and actual throughput. They measure different things.
- Subscription
- A way to fetch and update a list of connection profiles from one URL. The subscription URL and the server addresses in the list are usually different things. v2rayN manages sources in subscription groups, while v2rayNG provides subscription settings; after an update, the client parses the returned content. URLs may contain access credentials, so do not share them publicly. A failed update does not necessarily mean existing servers are no longer usable.
- Server
- A set of settings in the client for connecting to a remote service, usually including an address, port, protocol, authentication, and transport. A server alias is just a label; it cannot prove the actual location, route, or service quality. After selecting a server, confirm it is the active one. Subscription updates may replace or remove entries, so check your selection again if needed.
- TCPing
- A test that measures how long it takes to establish a connection to a target TCP port; it is not the same as ICMP Ping. It can help check whether an address and port are reachable, but usually does not verify proxy authentication, a complete security handshake, or access to a target website. If TCPing succeeds but the browser still fails, check the protocol settings and test an actual proxy request. TCPing does not directly measure download bandwidth.
- Real Connection Latency
- The time measured after sending a request to a test address through the selected proxy profile, making it a closer reflection of the real access path than a simple port check. Results still depend on the test target, DNS, handshake, and current network conditions, so avoid comparing tests run under different conditions. A successful test only confirms that request path works; it does not prove every app is being routed through the proxy or replace a sustained throughput test.
Routing and DNS
Traffic routing depends on matching criteria, while DNS resolution provides addresses. When troubleshooting access, check both the traffic route and the DNS resolution path.
- Routing Rules and Traffic Routing
- A mechanism that selects an outbound based on a domain, IP address, port, or other criteria; common actions include direct, proxy, and block. Rules are usually checked in order. A broad rule near the top may prevent a more specific rule from matching. When editing rules, check the match criteria, rule order, and outbound tag. Changing the system proxy status does not automatically change these rules.
- GeoIP and GeoSite
- GeoIP matches IP address sets, while GeoSite matches domain sets. The core uses the relevant data files to identify categories referenced by rules. Whether a category is available depends on the loaded data file; do not infer availability from its name, and remember that a GeoIP result does not prove a service's physical location. If a rule stops working, check that the data file loaded and the category exists—not just whether the subscription was refreshed.
- DNS Resolution
- The process of resolving a domain name to records such as IP addresses, usually before an app connects. The operating system, browser, and proxy core may each make their own DNS queries, so changing system DNS may not affect every app. To troubleshoot, identify which component is resolving the name and which outbound carries the query, then check the cache and response. A successful lookup does not guarantee the connection will succeed.
- FakeDNS
- A mechanism that assigns a synthetic IP address to a domain and stores the mapping in the core, so later connections can be associated with the domain. It is not a replacement DNS address for a regular public DNS server: DNS queries and the corresponding traffic must both go through the matching processing path. If an app caches a synthetic address after the related traffic interception is disabled, access may fail. Restore the matching settings and clear the cache if needed.
- DNS Leak
- A DNS query that does not follow the expected path—for example, a query that should use a designated DNS route is instead sent through another system path. First define the expected behavior; seeing multiple DNS services does not by itself mean there is a leak. Check browser encrypted DNS, system resolution settings, and core DNS routing, then use logs to narrow down the cause. Switching servers may not change the querying app's settings.