Key concepts to understand before configuring
Protocols define how connections communicate, the core handles them, and routing determines where requests go. Look up terms by configuration area, then compare them with the options in your client.
Protocols, transports and security mechanisms are separate dimensions. When importing a configuration, keep its original combination instead of swapping settings based on similar names.
VMess is a proxy protocol in the Project V ecosystem. It handles authentication and data exchange between client and server. A node configuration typically also includes a user ID, transport and security options, which must match on both ends. If the handshake fails after import, check all parameters and the system clock rather than simply changing the port.
VLESS is a lightweight proxy protocol that does not encrypt traffic on its own. In practice, it is often used with TLS or REALITY. The user ID, flow control, security mechanism and transport must all match the server. VLESS and VMess are different protocols; changing the protocol in a dropdown alone does not convert a configuration.
Trojan is a proxy protocol that typically uses TLS to establish a secure connection and a password for authentication. A correct password is only one requirement: the server name, certificate verification and transport settings also affect connectivity. If you see a certificate error, check the name and system time first instead of disabling verification to hide a configuration problem.
REALITY is a transport security mechanism in the Xray ecosystem, not a standalone proxy protocol or node management feature. Clients typically require a public key, short ID and server name from the corresponding server configuration. Support depends on the current core and protocol combination; a successful import does not mean every parameter is supported.
Transport describes how proxy data is carried. Common options include TCP, WebSocket and gRPC. It is a different layer from proxy protocols such as VMess and VLESS, so the two cannot replace each other. WebSocket may require a path and host name; gRPC may require settings such as a service name. Comparing server addresses alone is not enough.
The interface manages settings, the core handles connections, and system settings determine how some apps connect. When troubleshooting, first identify which layer the problem is in.
A client provides the user interface for managing subscriptions, nodes, routing and connection status, and calls the core to handle network traffic. v2rayN is for desktop systems; v2rayNG and v2flyNG are for Android. Menu names vary between clients, and an option in the interface does not guarantee support from the current core or node.
The core handles protocols, matches routing rules and forwards connections. The client translates interface settings into a configuration the core can read. Updating the interface is not the same as changing the core, and compatibility should be checked separately. When reporting a problem, include the client, selected core and error details instead of simply saying that the software does not work.
Xray is a proxy core project related to the Project V ecosystem, supporting a range of protocol and transport combinations. REALITY is one of its related technologies. v2rayNG uses the Xray core, but available features depend on the integrated core version and interface support. Before using an Xray configuration, check that the client can represent all of its fields.
V2Fly is a community project developed around V2Ray. Its core handles proxy connections, DNS, routing and other tasks within the Project V ecosystem. v2flyNG uses this core family as another Android client option. V2Fly and Xray configurations are not always interchangeable, so do not assume that parameters for one core apply to the other.
The system proxy points the operating system's proxy settings to the client's local listening address. Whether an app uses this route depends on how it is built. Browsers may follow system settings, while some apps have their own proxy options or connect directly. If only one app is not working after you enable the system proxy, check that app's settings before switching nodes.
Subscriptions retrieve configurations, nodes define connection settings, and speed tests check a specific route. Success in one does not guarantee success in the others.
A subscription is typically a URL used to retrieve a set of node configurations. When updated, the client parses the returned data into server entries. A successful update means the data was fetched and processed, not that every node can connect; the client does not provide nodes by itself. URLs may contain access credentials, so hide the full link before sharing screenshots, logs or support requests.
A node is a connection profile in the client, with settings such as server address, port, protocol, authentication and transport. Its list name is just a label; it does not confirm the actual exit location, bandwidth or availability. Keep a copy of the original configuration before editing, and avoid mixing authentication or transport settings from different nodes in the same subscription.
Subscription groups organize nodes by source or purpose and help limit the scope of updates, filtering and bulk actions. A group name usually does not determine where traffic goes; the active node and routing rules do. Before deleting, deduplicating or updating entries, check whether the action applies to the whole list or just one group to avoid changing configurations from other sources.
Latency is the time taken by a specific test and must be understood in context; results from different test methods are not directly comparable. A TCP connection test mainly shows whether a connection to the target port can be established. It does not verify the proxy protocol. Lower latency does not guarantee faster downloads: throughput, packet loss and the route to the destination service matter too.
Proxy latency usually measures the time taken to send a request through a node to a specified address, making it a closer measure of real proxy access than a port check alone. Results still depend on the test address, DNS, network route and timeout settings. If a test fails, check the logs for clues. Compare nodes under the same test conditions, then verify performance in the apps you actually use.
Check the match conditions first, then rule order, and finally the target outbound. Domain-based and IP-based data each have their own use cases.
Traffic routing sends requests to different outbounds based on domains, IP addresses or other connection criteria. Common actions include direct, proxy and block. It does not automatically combine the bandwidth of multiple nodes or send every request along the same route. When reviewing a routing preset, inspect the actual rules and default outbound instead of relying on its name.
A routing rule combines match conditions with a target outbound. Common V2Ray configurations check rules in order and select the corresponding route when one matches. A broad rule placed too early can prevent later, more specific rules from taking effect. When making changes, check both domain and IP match conditions and confirm the default outbound for traffic that matches no rule.
GeoSite is a collection of domain rules organized by category. The core can reference a category of domains instead of listing them individually. The contents of each category depend on the data file and source in use; categories with the same name may differ. GeoSite is not a live DNS result, so if a rule does not match, check whether the target domain is included.
GeoIP is a database of IP ranges organized by region or purpose, which routing rules can use for address matching. It reflects database classifications, not a live measurement of a connection's physical location, and does not directly indicate the quality of an exit. For shared infrastructure or dynamic IP addresses, regional classification alone may not describe everything needed to access a service.
An outbound defines how the core forwards a connection to its destination, for example by connecting directly, using a proxy server or blocking it. Routing rules typically refer to outbounds by tag, which must match the name defined in the configuration. When adding a custom outbound, check its authentication, protocol support and references. Defining an outbound alone does not make traffic use it automatically.
Check DNS resolution and connection routing separately. TUN can capture more traffic, but it does not replace DNS or routing configuration.
DNS looks up records such as the IP addresses associated with domain names. It is part of the setup for many network connections. The operating system, browser and core may each use their own resolver, so changing one setting may not cover every request. If a website will not load, distinguish a DNS failure from a connection failure or an application response issue instead of assuming the node is at fault.
Remote DNS usually refers to a resolver configured for proxy traffic, but the term “remote” does not guarantee that queries go through the proxy. Check the query's outbound route, how the resolver address is resolved and whether routing rules create a dependency loop. Direct and proxied requests can use different DNS routes; test each one instead of just checking whether a server address is filled in.
TUN mode uses a virtual network interface to receive IP packets routed to it by the operating system, then passes them to the client for processing. It usually requires appropriate permissions, and the traffic it captures depends on routing, exclusions and the client implementation. If other virtual networking tools are running, watch for interface or route conflicts. Enabling TUN does not automatically configure DNS correctly.
FakeDNS assigns virtual addresses to domain names so the core can recover the original domain during subsequent connections and process traffic accordingly. It is not a regular public DNS resolver and must work with traffic capture, mapping recovery and bypass rules. If an app receives a mapped address but connects directly without passing through the core, the connection may fail. After disabling FakeDNS, you may also need to clear cached DNS records that are still in use.
A DNS leak occurs when DNS queries take a different network path than intended. Assess it against your routing policy; a direct DNS query is not automatically a problem. Resolver details shown by a test page are only clues. Also check browser Secure DNS, system DNS and core logs. After fixing the issue, retest both the DNS route and actual access to confirm the change has not disrupted normal connections.
For your first setup, follow the v2rayN setup guide to import a configuration, select a node and verify the connection. If you are already connected but need to adjust subscription groups, traffic routing or DNS, read the Advanced Setup guide. Change one type of setting at a time and record the results.
Check the client interface and core capabilities you are actually using when looking up parameters. Similar option names can refer to different implementations, so confirm compatibility before migrating a configuration.