Quick reference / 26 terms

V2Ray Glossary

Look up terms by setup scenario. Start by distinguishing protocols, cores, and clients, then explore subscriptions, routing, and traffic capture.

Each card has an anchor you can link to directly from the address bar. For hands-on steps, start with the quick-start guide; for a structured learning path, see the beginner-to-advanced guide. Menu names may vary between client versions; follow the current interface and the features supported by your core.

01 / Connection settings

Protocols and transports

The protocol defines how two sides communicate, the transport carries the data, and the security layer handles encryption and authentication. These are three separate settings.

VMess: Protocols and transportsVMess is a proxy protocol in the Project V ecosystem and typically identifies users with a UUID. After importing a node, make sure its transport, port, and security settings match the server—not just the address. A system clock that is out of sync can also cause authentication failures. When troubleshooting, enable automatic time setting in Windows and sync the clock.

VLESS: Protocols and transportsVLESS is a lightweight proxy protocol that does not encrypt data on its own and is often paired with TLS or REALITY. The UUID, transport, and parameters such as flow must match the server; two VLESS configurations are not automatically interchangeable. If a node imports successfully but will not connect, check the complete set of parameters rather than changing only the protocol name.

Trojan: Protocols and transportsTrojan typically relies on TLS to protect traffic and uses a password to authenticate with the proxy server. The server address is used to connect, while the TLS server name is used for the handshake and certificate validation; they may differ. If the connection fails, check the password, server name, and certificate trust separately. Disabling certificate validation should not be a routine workaround.

REALITY: Protocols and transportsREALITY is a transport security mechanism in the Xray ecosystem, not a standalone proxy protocol on the same level as VLESS. Common configurations require a public key, short ID, and server name; use the fields shown in the client and required by the server. If parameters are missing, get the complete configuration rather than reusing values from another node. Also confirm that the core in use supports it.

TLS: Protocols and transportsTLS provides transport encryption and peer authentication, and is also used when browsers connect to HTTPS sites. In proxy configurations, the server name is typically used for the handshake and certificate name validation, and may differ from the connection address. An expired certificate, incorrect system time, or name mismatch can cause a handshake failure. Check the specific error before changing settings.

WebSocket: Protocols and transportsWebSocket is a transport that can carry a proxy protocol, but it does not replace user authentication. A reverse proxy may handle parameters such as the node's path and Host, which must match the server configuration. Switching from WebSocket to another transport does not automatically improve speed and may instead prevent the connection from being established.

02 / Execution layer

Cores and ecosystem

The client provides the interface and manages settings; the core handles the actual connection. An option appearing in the interface does not mean every core can use it.

Project V and V2Ray: Cores and ecosystemProject V is an open-source ecosystem of network proxy tools, with V2Ray as one of its core projects. In everyday searches, “V2Ray client” often means a graphical app for managing compatible cores, not one specific interface. Before following a guide, check the client name, core type, and platform—not just whether it mentions V2Ray.

Xray: Cores and ecosystemXray is a proxy core that handles protocols, connections, and routing. v2rayN and v2rayNG can both use it in relevant setups. Support for features such as REALITY depends on the core and the client's support for its parameters. After updating the GUI, check which core is actually in use; the GUI version and core version are not the same thing.

V2Fly: Cores and ecosystemV2Fly is a community project that maintains core software related to V2Ray. It shares technical roots with Xray, but the two are not identical implementations. Similar protocol names do not guarantee that every extension field is interchangeable, so check configuration compatibility field by field. With v2flyNG, choose nodes based on the capabilities of the V2Fly core rather than copying settings specific to another core.

Core type: Cores and ecosystem“Core type” is the client setting that selects the core responsible for handling connections—not a UI theme or speed tier. Switching cores can change supported protocols, DNS behavior, and routing syntax, so check node compatibility first. After changing it, look for configuration errors in the startup log and verify the traffic path again. Change one setting at a time to keep troubleshooting clear.

03 / Configuration management

Clients and subscriptions

Installing a client does not provide connection settings. Node parameters and subscription content come from the configuration provider; the client reads, organizes, and uses them.

v2rayN: Clients and subscriptionsv2rayN is a desktop GUI client for managing nodes, subscriptions, routing, and proxy settings. The cross-platform desktop edition and the classic WPF edition for Windows may differ; features depend on the build in use. Before choosing an installer, check your operating system and processor architecture, then follow the relevant guide. Menu locations shown in screenshots are not universal paths across interfaces.

v2rayNG: Clients and subscriptionsv2rayNG is an Android GUI client that uses the Xray core and can import a subscription or individual node. Connecting usually requires permission to use the system VPN interface; traffic is then handled according to app selection and routing rules. Background restrictions can interrupt the connection. See the v2rayNG setup guide for import and startup steps.

v2flyNG: Clients and subscriptionsv2flyNG is an alternative Android client that uses the V2Fly core for proxy connections. Its name is similar to v2rayNG, but their core capabilities and supported parameters are not interchangeable. To check whether a subscription will work, review the protocols and transport settings of its nodes. See the Android client list to choose a download.

Subscriptions and subscription groups: Clients and subscriptionsA subscription is a URL for retrieving node configurations; a subscription group organizes them. In v2rayN, save the URL under “Subscription Group Settings,” then select “Update current subscription (without proxy)” or another update method suited to your network. Subscription URLs may contain private access credentials, so don't include them in public screenshots. Updating a subscription does not automatically switch the selected node.

Node: Clients and subscriptionsA node is a set of settings for connecting to a remote service, typically including an address, port, protocol, authentication, transport, and security parameters. The name shown in a list is only a label; it does not prove the node's region, bandwidth, or availability. Check the configuration and actual connection results when troubleshooting. Never post a complete share link containing a password, UUID, or subscription credentials in a public forum.

04 / Traffic routing

Routing and traffic routing

First confirm that traffic is reaching the core, then check which outbound the rules select. Capturing traffic and choosing its outbound are separate questions.

Routing rules and traffic routing: Routing and traffic routingRouting rules select an outbound based on domains, IPs, ports, and other criteria. Traffic routing is the result of sending different requests along different paths. Rules are commonly evaluated in order, so an earlier match may prevent later rules from taking effect. Before making changes, check rule order, the default outbound, and core type, then verify the results using the routing guide.

GeoIP: Routing and traffic routingGeoIP is a collection of IP addresses organized by region or purpose, used to match addresses in routing rules. It relies on data files, and outdated data or changes in address allocation can produce unexpected matches. When domain and IP rules are both present, DNS resolution timing also matters. A domain suffix alone cannot tell you which GeoIP category will ultimately match.

GeoSite: Routing and traffic routingGeoSite is a collection of domains organized by category. For example, geosite:cn is a common reference to a domain category. It does not determine the destination IP's region in real time, nor does it simply identify sites in a particular language. Matching depends on the data file, whether the category exists, and whether the core has access to the domain name. After importing rules, check the startup log for errors.

Outbounds and outbound tags: Routing and traffic routingAn outbound defines how traffic leaves the core: it can connect directly, pass traffic to a proxy, or block it. Routing rules refer to outbounds by tag; for example, the value of outboundTag must match a tag that actually exists in the configuration. direct is a common label in tutorials, but don't copy it without checking your existing configuration.

Global proxy: Routing and traffic routingGlobal proxy usually means a routing policy that sends requests already handled by the core through a proxy outbound. It does not ensure every app uses the proxy, and it cannot replace traffic capture through the system proxy or TUN. If a browser connects but other programs still go direct, first check how those apps send traffic. Then consult the proxy modes guide to see whether you need to capture more traffic.

05 / Local networking

System proxy and networking

Check traffic capture, DNS resolution, and test methods separately. A single toggle or latency test cannot tell you whether the entire connection path is working.

System proxy: System proxy and networkingA system proxy registers a local proxy address with the operating system. Only apps that read this setting will use it. In v2rayN, “Automatically configure system proxy” updates the relevant settings based on the current local listener; it does not change network behavior for every app. If your browser cannot connect after you exit the client, check whether the system still points to a proxy port that is no longer listening.

TUN mode: System proxy and networkingTUN mode captures traffic through a virtual network interface and system routes, including traffic from some apps that ignore the system proxy setting. Enabling “Enable Tun mode” usually requires the appropriate permissions. The traffic captured also depends on routing exclusions and other networking software. Traffic reaching the core can still be routed differently; TUN does not force everything through the proxy. Read the TUN configuration guide before getting started.

DNS and DNS leaks: System proxy and networkingDNS translates domain names into network addresses. A DNS leak occurs when lookup requests do not follow the intended path. Check the system resolver, browser secure DNS, core DNS, and routing settings together; a website's displayed exit IP is not enough. The locations of DNS servers shown on a test page are not conclusive on their own—consider the resolver you expect to use and the path requests take.

FakeDNS: System proxy and networkingFakeDNS assigns synthetic IP addresses to domains and keeps a mapping between them so the core can recover the original domain when handling later traffic. It is not a regular public DNS service, and a single toggle will not configure all DNS settings automatically. Whether it works depends on the core and traffic-capture setup. Mismatched address ranges, routes, or mappings can cause domains to resolve but connections to fail.

Latency and real connection latency: System proxy and networkingLatency results depend on the test method: a TCP connection test and a test that accesses a destination through the proxy measure different parts of the process. In v2rayN, real connection latency is usually closer to an actual proxy request, but results also depend on the test destination, DNS, and current load. A lower number does not guarantee faster sustained downloads, and a failed test does not necessarily mean the node is unusable. Verify with the destination you actually need to reach.

Local listening port: System proxy and networkingThe local listening port is where the client receives app requests on your device; it is not the remote node's server port. If another program is already using the same listening address and port, the core may fail to start or provide proxy service. After changing the local port, update dependent system proxy, browser, and app settings. Avoid exposing the listener to your local network unless you specifically need to share it.