A focused reference for technical terms that recur in client interfaces, subscription data, and advanced configuration. Each entry defines the concept, where it appears in configuration, and what it does in practice, making tutorials and connection troubleshooting easier to follow.
The client handles the graphical interface, subscriptions, and system settings; the core parses configuration, establishes connections, and applies routing. Keeping the two separate makes version selection and troubleshooting clearer.
v2rayN is a graphical client for Windows, macOS, and Linux. It supports subscription imports, node selection, system proxy, TUN, routing, and log viewing. The client mainly manages configuration and the user interface; the selected core handles the actual protocol connection. When troubleshooting, check the interface settings, generated configuration, and core process separately.
v2rayNG is a graphical Android client that typically uses the Xray core for connections. It can import a subscription or individual share link and configure routing, DNS, and app coverage for the current connection. Android battery optimization, background restrictions, and VPN permissions can also affect continuous operation.
v2flyNG is also for Android but primarily uses the V2Fly core. It suits setups that depend on this core implementation or already use V2Fly configurations. Choose v2rayNG or v2flyNG based on node protocols, configuration fields, and core compatibility—not simply the interface name.
Xray is one of the core families in the Project V ecosystem, handling protocol handshakes, transport and security layers, DNS, and routing rules. The client converts interface settings into a configuration the core can read, then starts the relevant process. Whether a protocol field works usually depends on support in both the client and core versions.
V2Fly is a community-maintained Project V core implementation that reads configuration, creates inbound and outbound connections, and applies routing. It shares some concepts and configuration structures with Xray, but features, fields, and defaults may differ. Before importing a configuration, confirm which core family the client uses to avoid applying parameters intended for the other core.
The protocol defines how the client and server exchange connection information, while the transport and security layers define how data is carried and protected. These are separate configuration layers and should not be treated as one name.
VMess is a proxy protocol with identity information and time-based validation. Common settings include the server address, port, user ID, and transport. Core client and server parameters must match, and excessive local clock drift can cause authentication failures. VMess covers only the protocol layer; the connection still depends on transport settings such as TCP or WebSocket.
VLESS is a lightweight proxy protocol that typically delegates transport security to an independent mechanism such as TLS or REALITY. Along with the address, port, and user ID, check the flow control, transport type, and security-layer settings. Seeing VLESS alone does not establish compatibility; the complete combination must match field by field.
Trojan is a proxy protocol designed around TLS usage. Common settings include the server address, port, authentication details, and the domain associated with the certificate. When a connection fails, distinguish protocol authentication errors from TLS handshake and domain-resolution failures. The symptoms may look similar, but the error stage in the logs is usually different.
REALITY is a transport-security mechanism used in the Xray ecosystem and is often paired with VLESS. Client configuration typically requires the server name, public key, short ID, and fingerprint, all of which must correspond to the server settings. REALITY is neither a node name nor a standalone graphical client; it operates at the connection security layer.
The transport layer defines how proxy protocol data is carried, with common types including TCP, WebSocket, gRPC, and HTTP-based transports. Each uses different fields, such as a path, host name, or service name. If the transport type is identified incorrectly after importing a node, the connection will fail even when the address and authentication details are correct.
Subscriptions provide bulk updates, nodes represent individual connection profiles, and latency results describe only a particular test condition. Understanding where each value comes from makes it easier to tell whether updates, filtering, and switching actions worked.
A subscription is an entry point to a server-provided collection of nodes that the client fetches periodically. An update usually retrieves the content again, then adds, replaces, or organizes nodes according to the client’s rules. The subscription URL itself is not a connectable node; the client must parse it into specific profiles first.
A node is a single server connection profile in a client, typically containing the server address, port, protocol, authentication parameters, transport, and security settings. The node name is for identification and does not determine connection quality. Check logs, real connection tests, and actual access results to determine whether a node works.
A share link encodes a node’s key parameters in a specific link format, commonly for quickly importing one configuration. Link structures differ by protocol, and complex routing or DNS settings are often not included in a single link. After importing, check that the address, port, transport, and security fields were recognized correctly.
Latency is the round-trip time for a probe request, but clients may use different methods, including TCP probes, protocol handshakes, or target access. A lower probe value does not guarantee higher download speed and cannot independently show line stability. Keep the test method and target consistent when comparing results.
Real connection latency records the time needed to establish an actual protocol connection or access a test target, so it better reflects real client use than a simple port check. DNS, handshakes, the transport layer, and the target response all affect it. If a port probe succeeds but the real connection fails, check authentication and transport settings next.
Routing rules perform matching, while outbounds perform the action. Rule order, domain-resolution behavior, and data-file status can all change the final match.
A routing rule selects an outbound based on conditions such as the domain, IP, port, network type, protocol, or process. When multiple rules apply, they are usually evaluated in configuration order, with the first match taking effect. After changing rules, save the configuration and restart the relevant core to avoid continuing to use an old runtime configuration.
Traffic routing assigns traffic from different targets or applications to direct, proxied, blocked, or custom outbounds. It is not a standalone protocol but a policy formed by routing rules. Define the default outbound first, then add clearly scoped exceptions to reduce rule overlap.
GeoIP is matching data organized by the region or purpose associated with IP addresses, and routing rules can reference a category. It matches the destination IP rather than directly matching the domain entered by the user. If a rule must resolve a domain before checking its IP, DNS results and domain policies also affect the final match.
GeoSite is a categorized collection of domains that a client or core can reference in routing rules. It reduces the need to maintain domains individually, but category contents may change with the data version. If a domain matches unexpectedly, check the category name, data files, and rule order together.
An outbound is the processing path used when traffic leaves the core. Common types include proxy connections, direct connections, and blocking. Routing rules only choose the outbound; the selected outbound configuration establishes the server connection. Advanced setups can define multiple proxy outbounds and invoke them under different rules.
DNS determines the domain-resolution path, while the system proxy and TUN determine how traffic enters the client. When connections work but routing is wrong, this layer usually needs a separate review.
DNS is the basic network service that resolves domain names to IP addresses. A V2Ray client can use the system resolver or send queries to a remote or local resolver configured in the core. The result affects not only the connection address but also GeoIP, domain rules, and FakeDNS matching.
A DNS leak occurs when domain queries bypass the intended path and are sent to a resolver outside the configuration. Common causes include an application issuing encrypted DNS requests, the system proxy not handling DNS, insufficient TUN rule coverage, or conflicting DNS priorities. Troubleshoot the resolution paths used by the application, operating system, and client core separately.
TUN mode uses a virtual network interface to capture a broader range of system traffic and passes it to the client core for routing. It suits applications that do not actively read system proxy settings, but requires operating-system permission and correctly configured routing and DNS. If LAN access or resolution breaks after enabling it, check bypass ranges and DNS capture settings first.
FakeDNS returns a mapped address to the application while storing the relationship between that address and the original domain in the core. When the application later connects to the mapped address, the core can still route it using the original domain. It is often used with TUN mode, but an incorrect address pool or exclusion rule can affect LAN access or specific applications.
A system proxy writes the proxy server address into the operating system settings, allowing applications that follow those settings to send requests to the client. It is simple to configure and works well for browsers and most software using the system network interface, but it cannot automatically cover every application. If a program ignores the system proxy, check its own settings or evaluate TUN mode for the use case.