V2Ray Glossary

A GUI client provides the controls for importing subscriptions, selecting nodes, changing proxy modes, and viewing runtime notices. It usually generates configuration and starts the proxy core, but is not the underlying connection implementation. During troubleshooting, verify the client settings and core operation separately.

The proxy core reads configuration and performs protocol handshakes, domain resolution, route evaluation, and connection forwarding. A GUI client may let you choose between cores, so available features depend on core capabilities. When the core reports an error, check protocol parameters and configuration syntax rather than only toggling the system proxy.

v2rayN is a GUI client for Windows, macOS, and Linux that manages subscriptions, nodes, routing, and local proxy settings. It can invoke a compatible proxy core to handle connections. “System proxy” and “TUN” in the client are application access methods, not node protocol names.

Xray is one family of proxy cores that compatible clients such as v2rayN and v2rayNG can invoke. It handles protocol, transport, security-layer, and routing configuration, while the client provides the user interface. Check whether the current core supports the required protocols and features instead of judging by the client name alone.

V2Fly is a community project and core implementation in the Project V ecosystem. V2Fly in client names such as v2flyNG usually indicates the core direction, while the client itself remains a configuration management tool. Before importing a configuration, confirm that the server parameters fit the selected core's supported features.

VMess is a proxy protocol containing authentication and connection parameters. A configuration generally requires the user identifier, address, port, and transport fields to match. Changing only the protocol name cannot turn incompatible parameters into another protocol configuration.

VLESS separates authentication from transport-layer responsibilities and is commonly combined with TLS, REALITY, or different transports. VLESS itself does not specify encrypted transport or how an application connects to the local proxy. Check the user identifier, flow control, security layer, and transport parameters together.

Trojan is commonly used with TLS and password authentication. The domain, port, password, SNI, and certificate settings must match the server configuration. Enabling the system proxy only determines whether some applications use the local entry point; it cannot fix mismatched protocol parameters.

REALITY is a connection security mechanism in the Xray ecosystem, commonly configured with a public key, short ID, server name, and client fingerprint. It is neither a standalone GUI client nor a system proxy mode. Missing or inconsistent fields usually cause failure during connection establishment.

A transport is the connection format that carries proxy protocol data, such as TCP, WebSocket, HTTP/2, or gRPC. Different transports may require extra fields such as a path, service name, or request headers. The client and server must use compatible settings; matching ports alone is not enough.

A subscription is an updateable URL provided by a server that contains one or more node configurations. After requesting it, the client parses the content and writes it to the local configuration list. A subscription is not a proxy core and does not decide automatically whether a browser or terminal uses the proxy.

A node is a server connection profile in the client, usually containing the address, port, protocol, authentication, security layer, and transport parameters. Selecting a node only tells the core which profile to try. The application still needs access through the system proxy, a manual proxy, TUN, or another method.

A subscription update requests the subscription again and refreshes the local node list. If it fails, first distinguish an unreachable URL, expired authorization, invalid response format, and local network problems. A successful update only means the list was retrieved; it does not mean every node can connect.

Latency is the response time measured by a particular probe and is affected by the target, resolution process, network path, and current load. Results from different clients or test methods should not be compared directly. A low probe value cannot replace an actual connection test.

Real connection latency usually means the time measured by establishing an actual proxy connection and reaching a specified target. It includes more protocol and handshake steps than a basic connectivity probe, so it better reflects the current proxy path. When testing fails, use core errors to determine whether the issue is at the node, DNS, or TLS stage.

The system proxy is the method by which the operating system publishes a proxy address and port to applications that support the setting. Common browsers read it, but some terminal programs, independent network stacks, or applications with their own proxy controls may ignore it. If the browser works but the terminal does not, check each application's proxy source separately.

A local listener is the entry point where the proxy core waits for application connections on a local address and port. Common types include HTTP, SOCKS, and mixed listeners. System and application proxy settings usually point here. After changing the listener port, update every application that still uses the old port.

Application proxy settings are proxy addresses and ports entered separately inside a browser, download tool, developer tool, or other program. They may override the system proxy or apply only to that application. Check that the proxy type matches the local listener and that the application is not still using an old port.

TUN mode receives system traffic through a virtual network interface and can cover applications that ignore the system proxy. It still requires correct routing, DNS, and permission settings and may conflict with other virtual interfaces. Enable TUN based on application access needs, not as a universal fix for connection problems.

Environment variables such as HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY are common proxy entry settings for terminal programs. They affect only processes that read them, and new values usually require a new terminal session. Distinguish HTTP from SOCKS listeners and use the port currently exposed by the client.

Routing rules select an outbound path based on domains, addresses, ports, protocols, processes, or other conditions. They handle traffic that has already entered the proxy core and cannot automatically connect applications that ignore the system proxy. With multiple rules, also check match order and the default outbound.

Traffic splitting sends different targets or applications through different outbound paths. It can classify traffic by domain, address, process, or other conditions, but the traffic must first reach the client or core. If splitting behaves unexpectedly, confirm the access scope before checking rule matches.

GeoIP is a resource that helps match routes using address ranges and their geographic classifications. It relies on data files rather than real-time geolocation of the current connection. Changes in address ownership or data versions can affect results, so domain rules often need to be considered alongside address rules.

GeoSite is a rule resource that groups domains by purpose or category for batch matching. It describes domain classifications and is not the same as GeoIP address-range classification. If a rule does not match, check that the core retains the domain name and that the data includes the target domain.

DNS resolves domain names to reachable addresses. A proxy configuration can determine whether queries are handled by the system, the client, or a specified resolver, and can choose different resolution paths for different domains. A DNS result does not guarantee that the proxy protocol can connect; check the two stages separately.

FakeDNS returns an address from a reserved range to the application, then lets the proxy component recover the original domain. It is often used in transparent access to preserve domain information for subsequent routing decisions. When enabled, the address pool, routing, and DNS processing chain must work together.

A DNS leak occurs when domain queries bypass the configured resolution path and are sent by another network interface or resolver. Check whether the application uses its own DNS, whether TUN captures queries, and whether other network components are active. Reconstruct the actual query path instead of simply changing nodes.

TLS encrypts the connection and authenticates the server. A successful handshake requires compatible client and server parameters, along with valid certificate, domain, and expiration checks. When TLS fails, enabling the system proxy or changing routing rules cannot replace checking the handshake parameters.

SNI is the target server name supplied during a TLS handshake. It usually must match the server's expectation and a domain covered by the certificate. When the address is reachable but the handshake fails, SNI is one field to check separately.

A certificate chain describes the validation path from the site certificate to a trusted certificate authority. An incomplete chain, expired certificate, or domain mismatch can cause the TLS handshake to fail. Fix the certificate or domain configuration instead of permanently bypassing certificate validation.

System time is important for determining whether a certificate is within its validity period and affects some connection security mechanisms. A significant time or time-zone discrepancy can make a valid certificate appear not yet valid or expired. If several nodes show certificate errors at once, check automatic time synchronization first.