Protocols define request formats, cores handle processing, and clients manage settings. Identify the layer first, then check subscription, routing, and DNS parameters.
25 terms across six categories. Use the category links to jump to a section, or search for a term with your browser. Every card has its own anchor.
Separate the proxy protocol, transport, and transport security in a connection configuration. They serve different purposes and are not interchangeable.
VMess protocol
VMess is a proxy protocol in the Project V ecosystem. It uses a user ID for authentication and defines how proxy requests are encapsulated. Client and server authentication settings must match; a significant system clock difference can also affect authentication. When you see VMess, check the transport and TLS settings too—the protocol name alone does not tell you whether the full connection configuration is correct.
VLESS protocol
VLESS is a lightweight proxy protocol that does not encrypt payloads on its own. It is commonly paired with transport security such as TLS or REALITY. Its authentication and configuration fields differ from VMess, so changing only the protocol name does not convert a configuration. After importing, check the user ID, transport, and security settings. If the configuration includes a flow field, confirm that the core supports that combination.
Trojan protocol
Trojan typically carries proxy requests over a TLS connection and uses password authentication. A correct password is only one requirement: the server name, port, and certificate verification settings matter too. If the connection fails, first check the parameters supplied by the server and keep certificate verification enabled. Disabling verification can hide certificate configuration problems and weaken server identity checks.
REALITY transport security
REALITY is a transport security scheme in the Xray ecosystem, not a standalone proxy protocol alongside VLESS. A common setup uses VLESS to carry proxy requests and REALITY to secure the transport. Set the server name, public key, short ID, and client fingerprint as specified by the server, and confirm that the client's core supports REALITY.
Compare core support →Transport
Transport defines how proxy protocol data is carried over a network connection. Common options include TCP, WebSocket, and gRPC. Transport is a separate configuration layer from proxy protocols such as VMess and VLESS, and is not the same as TLS encryption. WebSocket paths and headers, as well as gRPC service names, may be required to match the server. Use the values specified by the server rather than guessing based on similar names.
An option appearing in the interface does not mean the current core supports its configuration.
Project V ecosystem
Project V provides context for understanding the V2Ray open-source ecosystem, including proxy processing, configuration, and related tools. The graphical client you install, the core that handles connections, and Chinese-language guides each serve a different purpose. When settings differ, identify the client and core a guide refers to; ecosystem names are not interchangeable software names.
V2Fly / V2Ray core
V2Fly is the community-maintained V2Ray project ecosystem. Its core handles protocol parsing, routing decisions, and outbound connections. The Android client v2flyNG uses this core family and suits setups that rely on its configuration behavior. Match configuration guides to the version in use; do not assume protocol features or fields added in other cores are available in V2Fly.
Xray core
Xray is an open-source core project with technical roots in V2Ray, supporting features such as VLESS and REALITY. v2rayNG uses the Xray core, and the desktop client v2rayN can also use compatible cores to handle connections. The two core families share some configuration, but protocol support, transport combinations, and field details are not identical. Check compatibility before switching.
Graphical client
Graphical clients provide interfaces for importing subscriptions, choosing servers, configuring routing, and viewing logs; the core handles network processing. This site covers the desktop client v2rayN and the Android clients v2rayNG and v2flyNG. Updating the interface app is not the same as updating the core. When troubleshooting compatibility, check the client version, core type, and active configuration.
A subscription retrieves configurations; choosing a server and starting a connection are separate steps.
Subscription
A subscription is a way to retrieve a set of server configurations from a URL. When updated, the client fetches the latest content from that address. Subscription URLs may contain access credentials, so hide the full URL in screenshots and logs. A successful update means the configurations were retrieved and parsed, not that every one can connect. If an update fails, check the URL, retrieval path, and subscription format separately.
Subscription management guide →Server profile
A server is a client configuration for connecting to a proxy server, typically containing its address, port, protocol, authentication, and transport settings. Its display name is only a label; it does not guarantee the server's location or network quality. When troubleshooting, check the configuration fields and connection logs rather than relying on the label. Subscription entries may also be replaced or removed during an update.
Subscription group
A subscription group is a local way for a client to organize subscription sources and server entries, with notes to distinguish sources. The group name does not change server identity or automatically determine where requests go. How updates, server filtering, and sorting work depends on the client. After setting a filter, check whether entries are merely hidden or the subscription failed to load.
Real connection latency
Connection latency usually measures the time taken to reach a test target through the selected proxy configuration, making it a closer measure of the actual request path than a simple server port check. Whether it includes connection setup, handshakes, and response time depends on the client's test method. It is not download speed and does not guarantee every target will work. Compare results using the same test address and network conditions, and check logs when a test times out.
First check whether the request enters the client, then find which outbound rule it matches.
Routing rule
A routing rule selects an outbound route based on conditions such as domain, destination IP, port, or network type. Many cores check rules in order, and the first match determines the route, so put specific exceptions before broader rules. Whether a domain condition can match also depends on whether the core has domain information; a missed match is not necessarily a rule-order issue.
Rule syntax and priority →Traffic routing
Traffic routing assigns requests to a proxy, direct connection, or block based on conditions. System proxy or TUN determines how traffic enters the processing chain; routing determines where it goes next. These are separate functions. Even when an app uses the client, a rule may send a particular destination direct. Check the actual matched outbound route rather than just the proxy toggle.
IP address datasets
GeoIP is a collection of IP addresses grouped by country, region, or special address type. Common rule formats include geoip:cn and geoip:private. It matches destination IPs; it does not directly identify which service a website belongs to. Data versions, changes in address allocation, and DNS results can all affect matches. A domain resolving to different addresses may therefore match different rules.
Domain name datasets
GeoSite is a collection of domains grouped by region, service, or purpose, used in routing and DNS rules—for example, geosite:cn. It is a domain list, not an IP geolocation lookup. Available labels and their domain coverage depend on the data file loaded. If a rule errors or misses a match, check the data source and label, and whether the domain is included in the list.
DNS resolution and application traffic may take different paths, so check them separately.
Domain Name System
DNS resolves domain names to IP addresses and other records, allowing apps to connect to their destinations. The operating system, browser, and proxy core may each use a different resolution path, so changing one does not necessarily affect the others. When troubleshooting, distinguish a resolution failure from an unexpected address or a failed connection, and check whether the DNS cache still contains an old result.
Synthetic DNS mapping
FakeDNS assigns synthetic addresses to domains and stores a mapping between each address and its domain, allowing the original domain to be recovered for connections and routing. A synthetic address is not the website's real server address and should not be used as an ordinary public destination. DNS responses must work with the connection interception path. After disabling FakeDNS, apps that have cached synthetic addresses may need their cache cleared or connections restarted.
DNS leak
A DNS leak occurs when a query takes a different path from the one intended—for example, when application traffic goes through a proxy but DNS queries still use the local network. Whether this is a problem depends on the intended configuration; deliberately configured direct DNS should not automatically be treated as a leak. Check the system resolver, browser secure DNS, client DNS settings, and connection logs. A single test page cannot account for every app's behavior.
DNS over HTTPS
DoH sends DNS queries and responses over HTTPS, protecting their contents in transit. It changes how queries are transported, but does not automatically send them through a proxy or guarantee that the results suit the outbound network. A browser's own DoH setting may bypass system DNS settings, so check app-level DNS configuration when changing DNS in the client.
Traffic capture and outbound routing handle different stages. After enabling them, verify what happens to real requests.
System proxy
A system proxy points the system and apps that follow its settings to a local proxy endpoint. In v2rayN, “Set system proxy automatically” is this type of setting, but some apps use their own network configuration and may ignore the system setting. It is not a routing mode and does not capture all traffic. If apps cannot connect after closing the client, check whether the system proxy still points to a stopped local service.
Routing preset
A routing mode is a set of rule presets provided by the client, such as global or bypass mainland China, that determines how requests already received are routed. Global mode does not mean every app uses the client; traffic entry still depends on the system proxy, app settings, or TUN. Presets with the same name may use different rules in different clients, so check the actual rules and fallback route.
Compare proxy modes →Virtual network interface
TUN mode receives IP packets through a virtual network interface and passes them to the proxy processing chain. It is useful for apps that cannot use the system proxy directly. It does not change server settings or guarantee that every protocol will be forwarded successfully. Check permissions, the default route, DNS interception, and interactions with other network software. Capabilities depend on the client and implementation.
Android VPN interface
Android clients use VPN mode to receive app traffic through the system VPN interface, which usually requires user authorization the first time it is enabled. The system's connection indicator confirms that the interface is active; it does not prove the remote server is reachable. App scope, DNS, and routing rules still determine what happens to traffic. Also consider system limits when running another app that uses the same interface.