V2Ray / Configuration Reference
Browse terms by configuration topic. First distinguish protocols, transports, and cores; then identify what subscriptions, routing, and DNS each control in a connection.
26 terms. Each entry has its own anchor, so you can copy a link into troubleshooting notes. Exact setting names and available features depend on your client and core version.
Protocols & Transports
A server configuration usually includes settings from all three categories. The same protocol name does not mean paths, flow control, or security settings are interchangeable.
VMess protocol
VMess is a proxy protocol in the Project V ecosystem. It uses parameters such as a user ID for authentication and commonly appears in V2Ray configurations and subscription entries. Check the address, port, user ID, transport, and security settings together; the protocol name alone is not enough. Legacy compatibility options in older guides may not apply to current versions. If authentication fails, also check that the device clock is accurate.
VLESS protocol
VLESS is a lightweight proxy protocol without its own content-encryption layer, typically paired with security mechanisms such as TLS or REALITY. The user ID, flow control, and transport settings in an entry must match the server; don't copy them blindly from another configuration. To check whether a client can use a VLESS configuration, verify that its core supports the specific combination of features.
Trojan protocol
Trojan typically protects connections with TLS and uses a password for proxy authentication. Here, the term refers to a network protocol, not the nature of a file based on its name. The password handles authentication, while the server name and certificate verification serve a separate connection-checking role. If an imported entry fails during the handshake, check the security and authentication settings separately rather than disabling certificate verification.
REALITY transport security
REALITY is a transport security mechanism in the Xray ecosystem, not a complete proxy protocol on the same level as VLESS. Clients typically need the server name, public key, short ID, and other parameters supplied by the server, along with a compatible transport and core. Don't put the REALITY public key in the user ID or password field. A value in the wrong field will not make a valid configuration, even if it is complete.
Transport · TCP / WebSocket / gRPC
Transport defines how a proxy connection carries data. Common options include TCP, WebSocket, and gRPC; transport is a different layer from proxy protocols such as VMess and VLESS. A transport may require additional settings such as a path, Host, or service name, which must match the server. Transport names are not performance rankings. When troubleshooting, check that the parameters match before investigating network conditions or implementation differences.
Cores & Clients
The graphical client manages and generates configurations; the core handles connections. Updating the interface and updating the core are not necessarily the same operation.
Project V ecosystem
Project V is an open-source ecosystem built around network proxying, with V2Ray as its core software. Its tools can handle connections by combining inbounds, outbounds, and routing. Project V, V2Ray, V2Fly, and Xray refer to different things, not interchangeable names. Before using a configuration example, check which project and version it targets, then confirm that your client can generate or load the relevant fields.
V2Fly / V2Ray core
V2Fly is a community project that continues V2Ray development; the name is also commonly used in everyday discussion for its corresponding core branch. The core parses configurations, establishes connections, and applies routing; it is not the graphical interface with subscription controls. Even if two configurations are both labeled V2Ray, check their format and feature support. Don't assume that fields added by another core can be used as is.
Xray core
Xray-core is an independent core project originating from V2Ray. It handles proxy protocols, transports, inbounds, outbounds, and routing. It shares roots with V2Fly, but their later features, fields, and compatibility are not identical. If your client lets you switch cores, check the entry's protocol extensions and custom settings first. Changing cores is not a universal connection fix.
Windows / macOS / Linux
v2rayN is a desktop graphical client for managing servers, updating subscriptions, and configuring system proxy and routing settings. It uses companion components to handle connections. The desktop edition has a different interface from the classic WPF edition; check the documentation for the version you're using to find its menus and features. When troubleshooting, record the client name, core type, and proxy mode separately. That's more useful than simply saying “V2Ray won't connect.”
Android · Xray
v2rayNG is an Android graphical client covered here in the context of its Xray core. It often uses the system VPN interface to route app connections. System permissions, per-app proxy settings, and manufacturer background restrictions can all affect how it runs, so don't check only the server entry. A VPN icon in the status bar means the capture interface is active; it doesn't confirm that the remote server, DNS, or destination site is reachable.
Android · V2Fly
v2flyNG is an Android graphical client that uses the V2Fly core and can be an alternative when choosing a client based on core requirements. Its name and some import and connection workflows resemble v2rayNG, but that doesn't mean it supports the same protocol extensions. Before migrating a configuration, check core compatibility, then verify subscription parsing and proxy settings. A similar interface does not guarantee configuration compatibility.
Subscriptions & Nodes
A successful subscription update, an available server entry, and access to a test address are different results; none guarantees the others.
Subscription
A subscription distributes a set of server configurations from a remote URL. The client fetches, parses, and saves the entries when you update it. Subscription URLs may contain access credentials, so hide the full link in screenshots, logs, and support requests. A successful update only means the fetch and parsing completed; it doesn't mean every entry will connect. If no entries appear, check the group's filters and the format of the returned content.
Server profile
A node usually means a server configuration in the client, with parameters such as address, port, protocol, authentication, and transport. It doesn't necessarily correspond to a separate physical server. The display name is only a label for identification; it does not prove the actual egress location or network path. When troubleshooting an individual node, check its configuration fields and connection logs rather than relying on its name, icon, or a single test result.
Subscription group
A subscription group organizes subscription sources and their server entries. A client may save update URLs, filters, and automatic update policies per group. The group name is not a routing rule and does not automatically enable failover or load balancing. If the number of entries changes significantly after an update, check the group's filters and update results before re-importing, so you don't overwrite manual changes.
Latency
Latency is the time taken by a specific test and must be interpreted in the context of its method, target, and start and end points. Measuring a TCP connection is not the same as measuring a completed webpage request. A lower connection time doesn't necessarily mean faster sustained downloads and is no substitute for a throughput test. For useful comparisons, keep the target and test method consistent, account for network fluctuations, and don't treat a single reading as a long-term conclusion.
Real connection latency
Real connection latency usually measures how long the client takes to reach a test address through the selected proxy, making it closer to an actual proxy request than a simple server-port check. Results still depend on DNS, the handshake, the test target, and the implementation; values from different clients may not be directly comparable. If a test fails, distinguish a proxy-path issue from an unreachable destination. A passing test doesn't mean every app is using the proxy.
Routing & Traffic Routing
System proxy settings control how some apps connect; once a connection reaches the core, routing conditions determine its outbound. Check each layer in order before changing rules.
routing.rules / outboundTag
Routing rules select an outbound based on conditions such as domain, IP, port, or inbound. The outboundTag in a rule points to a defined outbound tag. Cores usually check rules in order, and the first match determines the connection's route. Check the core documentation to see how multiple conditions within a rule are combined. If no rule matches, the configuration's default behavior applies. When troubleshooting, check the rule order, whether the tag exists, and the fallback outbound.
Traffic routing
Traffic routing directs different connections to outbounds such as proxy, direct, or block according to conditions like destination domain, address, or other identifiable information. A client's “global” mode is usually a routing preset; it doesn't automatically mean all app traffic has entered the client. To verify routing, first confirm how traffic enters, then check which rule matches the destination. This helps avoid mistaking uncaptured traffic for a routing failure.
geoip:cn
GeoIP is a collection of IP addresses that routing rules can reference, often grouped by region or purpose. For example, geoip:cn references a set of addresses in the relevant data. It matches IPs, not domain names; whether a domain must be resolved first depends on the routing domain strategy. Data versions, DNS results, and changes in IP allocation can all affect matches. A category label is not real-time geolocation.
geosite:category-ads-all
GeoSite is a collection of domains that routing rules can reference, grouped by service, site, or purpose. For example, geosite:category-ads-all references a set of domains in a category. Available categories and their contents depend on the data file loaded; don't infer coverage from the label alone. If a rule doesn't work, check that the data loaded correctly, the category is available, and no earlier rule matched first.
System proxy
A system proxy is a proxy address setting provided by the operating system. A client can point it to a local listening port so apps that honor the setting pass their connections to the proxy. Some programs use their own proxy settings or connect directly, so enabling the system proxy does not capture the entire device. It is separate from “global” mode in core routing. If the internet still doesn't work after you exit the client, check whether the system proxy setting was left enabled.
DNS & TUN
DNS determines how an address is resolved; TUN determines how some connections enter the client. FakeDNS and sniffing provide domain information for subsequent processing.
Domain Name System
DNS translates domain names into IP addresses and other records. Browsers, operating systems, and proxy cores may each issue queries and maintain their own caches. The configured resolver, query outbound, and domain strategy all affect connections; changing one DNS address may not change every app's resolution path. When troubleshooting, identify who sends the query and which outbound it uses, then distinguish a resolution failure from an unsuitable address or a connection failure.
TUN virtual network interface
TUN mode receives IP packets through a virtual network interface and passes them to a proxy component, which can cover apps that don't follow system proxy settings. The actual capture scope still depends on system routes, exclusions, permissions, and the component's implementation. Enabling TUN does not mean every connection uses a proxy outbound. When setting it up, check DNS and loopback handling too, and avoid having multiple VPNs or virtual network components compete for the default route.
Fake DNS
FakeDNS returns virtual addresses to apps and keeps a mapping between each virtual address and its original domain. The proxy component later recovers the domain and handles the connection. It relies on traffic capture and mapping recovery working together; it is not a regular public DNS address that can simply be entered and expected to work for every app. If an app retains an old cache or the related traffic bypasses the proxy, the virtual address may not be handled correctly. After changing settings, verify the resolution and connection paths again.
DNS leak
A DNS leak occurs when a query uses a different path or resolver than intended—for example, when a query meant to use a specified outbound is sent directly by an app to another resolver. Whether this counts as a leak depends on your intended policy; local resolution for domains meant to connect directly is not automatically a configuration error. Check system DNS, encrypted DNS in the browser, app-level resolution, and proxy DNS. A single test page cannot show how every app behaves.
sniffing
Traffic sniffing identifies protocols or visible destination-domain information in the initial connection data, providing clues for routing. It's often used when a connection reaches the core with only a destination IP. It does not decrypt traffic and cannot recover domains from every encrypted connection; results depend on traffic characteristics and the implementation. Different options may control whether sniffed data is used for routing or to rewrite the connection destination, so follow the documentation for your core version.