From protocol names to client toggles, understand terms by where they fit in the configuration. Start with the protocol and core, then distinguish subscription management, traffic capture and routing to avoid conflating different types of issues.
Protocols define how communication works; transport and security settings describe how a connection is carried. The same protocol name does not mean settings are interchangeable, so review the full configuration after importing it.
VMess is a proxy protocol in the Project V ecosystem. A connection profile typically includes a server address, port and user ID. It can use different transport methods, but the transport settings must match the server. When troubleshooting, check protocol authentication, transport settings and system time separately; an address and port alone do not confirm that a profile is correct.
VLESS is a lightweight proxy protocol with distinct settings for user IDs, flow control and transport. VLESS authentication does not itself provide transport encryption; connections often also require TLS or REALITY, as specified by the server. If you encounter an unknown field or handshake error, first confirm that the selected core and version support the complete set of parameters.
Trojan is commonly used with TLS and authenticates with a password. The server name, certificate validation and transport method all affect the connection, so a correct password alone does not guarantee a successful handshake. For certificate errors, check the domain, device time and server settings rather than masking the cause by disabling certificate validation.
REALITY is a transport security mechanism in the Xray ecosystem, not a standalone client feature that replaces a subscription or node. It requires core support and matching parameters from the configuration provider, such as the server name, public key and short ID. REALITY is often paired with VLESS, but that does not mean every core that supports VLESS supports the same REALITY configuration.
The client provides the interface; the core handles connections. When comparing features, check both the client’s settings and the capabilities of the core it actually runs.
Project V is an ecosystem of projects focused on network proxying and communication tools, with V2Ray as one of its key components. What people call a V2Ray client is often a GUI application that manages configurations and runs a proxy core. Knowing the distinction helps separate ecosystem names, core names and specific apps such as v2rayN.
V2Fly is a community project that maintains V2Ray-related implementations and commonly refers to this core branch and its ecosystem. On Android, v2flyNG is a client that uses the V2Fly core. Before switching cores, check protocol, transport and configuration format support; extension fields accepted by another core may not work as-is.
Xray is a proxy core developed from a fork of the V2Ray codebase, with its own path for evolving protocol and transport support. v2rayNG uses the Xray core, but available features still depend on the version bundled with the app. Choose a core based on your configuration requirements—not on assumptions that a different name means faster speeds.
The core reads connection profiles, handles protocols, establishes connections and applies routing. The GUI client imports, edits and displays these settings. Being able to save a profile in the client does not guarantee that the core can run it. If startup fails, check the logs for field, protocol or file errors before changing cores.
A subscription fetches configurations, a node is a selectable profile, and a test result is an observation under specific conditions. These are not the same as connection status.
A subscription link is an address a client uses to fetch a set of configurations. Updating it retrieves the content published by the provider. Importing the link, updating successfully and connecting to a node are three separate steps, and each can fail independently. The link may contain access credentials, so remove the full URL and sensitive parameters before sharing screenshots, logs or troubleshooting notes.
A node is a common term for a selectable connection profile in a client, typically containing server, port, authentication and transport details. Its display name is just a label; it does not verify the server’s location, route quality or current availability. After selecting a node, start the service and confirm that app traffic is actually reaching the client.
Subscription conversion reformats a subscription or configuration for a target client. It cannot add protocol features the core does not support, and format differences may cause some parameters to be lost. If you use a remote conversion service, its operator may access the full subscription. Check that you trust the service, and see whether the client can import the subscription directly first.
Latency is the time taken by a particular test, which might measure a network probe, port connection or actual request. Each method covers different stages, so values cannot be compared without accounting for how they were measured. Lower latency does not mean higher download throughput, and a failed test should be considered alongside its target, routing and logs.
Routing determines where traffic entering the core goes. When checking rules, consider the match conditions, evaluation order, data files and default outbound.
Routing rules select an outbound action—such as direct, proxy or block—based on domains, IPs, ports or other conditions. Rules are commonly checked in order, so a broad condition near the top can override a more specific one below it. If a site uses the wrong route, check rule order, destination details and the default outbound for unmatched traffic.
GeoSite is a collection of domains grouped by tags. Routing rules can reference a tag to match multiple domains without maintaining them individually. A tag’s meaning and coverage depend on the data file in use, and different sources may not match exactly. If matching changes after a rule update, check that the file loaded successfully and the tag still exists.
GeoIP is a collection of IP address ranges grouped by region or other tags, used to match destination addresses. Unlike GeoSite, it matches IPs; some rules need a resolved address before they can be evaluated. Data classification does not indicate a server’s real-time physical location. If a rule matches unexpectedly, check the DNS result and data file too.
Traffic routing sends different traffic through different outbound routes—for example, connecting to some destinations directly and sending others through a proxy. It has a different role from the system proxy or TUN, which mainly determine how traffic enters the client. Routing rules can still apply in TUN mode, and the behavior of “global proxy” depends on how the client defines it.
Domain resolution and connection establishment are separate stages. If a page will not load, identify whether the error occurs during resolution, the handshake or the request itself instead of changing every setting at once.
DNS provides domain name resolution, commonly translating domain names into IP addresses needed for connections. Browsers, operating systems and proxy cores may each use their own resolver, so changing one does not necessarily affect every query. To troubleshoot resolution, identify what initiated the query, which resolver it used and how the query traffic was routed.
FakeDNS returns a virtual IP for a domain and maintains a mapping between the virtual address and the domain, allowing the domain to be recovered for a later connection. It does not reveal the destination server’s real address; related traffic must pass through a handler that recognizes the mapping. When using it with TUN, consider the address range, cache and routing. Disabling FakeDNS may require clearing stale DNS cache entries.
A DNS leak occurs when queries bypass the intended resolution path and are sent through another resolver or network interface. A system proxy mainly affects connections from apps that use the setting; it does not automatically control all DNS traffic on the device. Check the browser’s encrypted DNS, system resolver and client settings together—not just whether the proxy is enabled.
Real connection latency usually measures the time taken to send an actual request to a test address through the selected configuration, covering more connection stages than a simple server port check. The exact timing depends on the client implementation, and results are affected by the test target, DNS resolution and handshake. A failed test means only that this request did not complete; it does not prove that every site or outbound route is unavailable.
Choose how traffic enters the client, then check routing and connectivity. Setting names can vary across platforms, so follow the current client interface and permission prompts.
A system proxy is a setting provided by the operating system for apps to use. Common desktop browsers follow it, but apps can use their own settings instead. In v2rayN, automatic system proxy configuration mainly points the system setting to the client’s local listening address. This does not capture traffic from every app. If your browser cannot connect after you exit the client, check that the system proxy setting has been restored.
TUN mode routes IP traffic through a virtual network interface, which can help with apps that do not use the system proxy. It usually requires additional permissions and coordinated system routing and DNS settings; it is not just another proxy toggle. Before enabling it, confirm that a regular connection works. Avoid running other tools that modify the same routes so you can identify the source of any changes.
An Android client can capture device traffic through the system VPN interface; the first time you start it, you will usually need to approve the system prompt. VPN here describes how traffic enters the client. The node configuration and routing still determine the proxy protocol and outbound policy. Typically, only one app can use this interface at a time, so other VPN apps may conflict with the current connection.
Runtime logs record client or core startup, parsing and connection details, making them a key resource for identifying where a failure occurs. Reproduce the issue once, then check the first relevant error around that time rather than looking only at the final timeout line. Before sharing logs, remove subscription links, authentication fields and other sensitive data. If useful, note which core and traffic capture mode were in use.