Glossary & Setup Reference
Look up terms by configuration layer: distinguish protocols, transport and security first, then understand core engines, subscriptions and traffic routing.
01 / Protocols
A protocol defines how a proxy request is expressed; transport determines how its data is carried.
VMess is a proxy protocol in the Project V ecosystem, with user authentication and data encryption. Configuration typically includes a user ID, server address, port and transport settings, which must be compatible at both ends. Some authentication steps are time-sensitive, so a significant system clock mismatch can prevent a connection. Don't check only whether the address is reachable.
VLESS is a lightweight proxy protocol that does not encrypt data on its own; deployments typically pair it with TLS or REALITY. Selecting the right protocol fields does not configure the whole connection: the security layer, transport and flow-control settings must also match the server. The name VLESS alone says nothing about speed or availability.
Trojan typically runs over TLS and uses a password for user authentication. After importing a configuration, check the server name, port and certificate validation settings. A correct password alone does not guarantee a connection. Trojan and VLESS are different proxy protocols; switching the protocol in a dropdown does not make all other settings interchangeable.
Transport describes how proxy data is carried; common options include TCP, WebSocket and gRPC. It is a different configuration layer from proxy protocols such as VMess and VLESS. Paths, hostnames and service names may also vary by transport. If you change the transport manually after importing a configuration, check the related fields and core support as well.
02 / Engines
The graphical interface manages settings; actual connection support depends on the running core and its version.
The core engine handles tasks such as inbound and outbound connections, routing and DNS. A client typically converts interface settings into a core configuration and starts the engine. An option in the interface does not mean every core can use it. When troubleshooting, note the client name, core type and relevant logs—not just the status shown on the main screen.
Xray-core is a proxy core developed from the same roots as V2Ray, with support for VLESS, REALITY and XTLS Vision. Supported features and configuration requirements change between versions, and older cores may not handle newer configurations. Before switching a configuration to another core, check the security layer, flow control and transport options rather than assuming full compatibility.
V2Fly is the community-maintained continuation of the V2Ray project; V2Fly-core usually refers to the core maintained by this community. It shares technical roots with Xray-core, but their later features and configuration formats differ. If a subscription includes features such as REALITY, use a core that supports them instead of relying on similar names.
Graphical clients provide interfaces for importing subscriptions, selecting nodes, choosing routing presets and setting proxy modes. v2rayN, v2rayNG and v2flyNG are all clients at this layer. A client name is not a proxy protocol, and core configurations are not necessarily interchangeable. If menus move between versions, look for the setting by its function and check the logs to confirm what happened.
03 / Security layers
Distinguish security protocols, handshake names and flow-control fields to avoid mixing settings from different layers.
TLS provides encryption, integrity protection and authentication for a connection. Certificate validation is an essential part of that protection. When using TLS, set the correct server name and keep the system clock accurate. If a certificate error occurs, check the name, clock and server certificate configuration first; disabling validation is not a routine fix.
REALITY is a security layer in the Xray ecosystem, not a standalone proxy protocol, and is often combined with VLESS. The client needs a core that supports REALITY, along with correctly configured parameters such as the public key, server name and short ID. Its configuration differs from ordinary TLS, so changing only the security layer name while leaving the other fields untouched will not work.
SNI is a TLS handshake extension that indicates the server name. Client interfaces often label the related field “Server Name.” The connection address can be an IP address while this field contains a domain name; they serve different purposes. Use the name specified by the server configuration. Replacing it with an arbitrary domain can cause certificate validation or security-layer handshake failures.
XTLS Vision is a flow-control scheme in Xray, commonly set in the flow field of a VLESS configuration; it is not a transport. Availability depends on the protocol, security layer, transport combination and server support. Don't select it just because it appears in a menu. If the subscription doesn't specify it, check the complete settings provided by the server first.
04 / Subscriptions
Subscriptions distribute configurations, nodes describe connections, and test results reflect only specific test conditions.
A subscription lets a client retrieve and update multiple connection configurations from a single URL. The URL itself is not the remote server address. A successful update means the client retrieved and parsed the content—not that every configuration can connect. Subscription URLs may contain access credentials, so don't share them publicly. Repeated updates won't fix an incompatible format.
A node usually means a set of remote connection settings saved in a client, including the address, port, protocol, authentication and transport options. Its display name does not prove the server's location, network route or performance, and one server can have multiple configurations. Choose based on availability tests and real-world use, not the name alone.
Latency is the time a test request takes to receive a response, but tests may measure an ICMP round trip, TCP connection setup or a complete proxy request. These results are not directly comparable, and lower latency does not mean higher throughput. For a useful comparison, use the same test method at similar times and consider connection stability.
In client interfaces, real connection latency usually means the time taken for a test request sent through the proxy connection, making it closer to an actual request. The test target, protocol handshake, DNS and connection reuse can all affect the result; the exact method depends on the client. A failed test may simply mean the target is unreachable, so check logs and try other addresses.
05 / Routing
Once traffic reaches the core engine, matching conditions and rule order determine its outbound.
Routing rules select an outbound for a connection based on conditions such as domain, IP address, port or protocol. Rules are commonly checked from top to bottom, with the first match taking effect, so a broad rule near the top can mask more specific rules below it. DNS resolution strategy can also affect IP-based matches. After changing rules, verify the results in connection logs.
In routing, GeoIP usually means a collection of IP addresses organized by region or category, such as geoip:cn in a rule. The actual coverage depends on the loaded data file; it is not a real-time geolocation service. If a rule depends on the destination IP, check when the domain is resolved and whether the resulting IP is used in that rule match.
GeoSite is a collection of domains organized by site or category, such as geosite:cn. Labels and coverage are defined by the data file. It matches domains; it does not determine the geographic location of a server's IP, nor does it guarantee that every domain associated with a service is included. If a rule reports a missing label, first check the data source and whether the label exists.
Routing sends each connection direct, through a proxy or to a blocked outbound based on matching conditions; routing presets are a common way to configure it. The system proxy determines whether an app hands traffic to the client, while routing determines what happens after traffic arrives. They are not the same switch. Even global routing cannot control app connections that never reach the client.
06 / Local networking
The traffic entry point, virtual network interface and DNS resolution path affect different stages and need to be checked together.
The system proxy is a set of proxy settings provided by the operating system to apps, usually pointing to the client's local listening address and port. Only apps that follow these settings use this entry point; some programs need their own proxy configuration. If you quit the client but leave a defunct local proxy address configured, apps may lose network access. Check for and clear any leftover settings.
TUN mode receives IP traffic through a virtual network interface and can capture connections from some apps that do not follow the system proxy. It requires client support and typically involves system permissions, routing and DNS settings; it is not a protocol option. Multiple network tools managing routes at the same time can conflict. After enabling TUN, check that local network access and DNS resolution still work.
FakeDNS returns synthetic IP addresses and keeps a mapping to the original domains so the domain can be restored when handling a later connection. It is not a regular public DNS server or a switch for speeding up DNS. DNS queries and subsequent traffic need a compatible path; otherwise, a synthetic address may be passed to a network program that cannot recognize it.
A DNS leak occurs when queries bypass the expected resolution path and are handled by another resolver, for example when an app uses its own DNS service. A successful proxy connection does not prove that DNS is following the expected path, and using a remote resolver is not necessarily a problem. Before troubleshooting, define the intended path, then check app settings, system resolution and client DNS logs.