Protocols and transports
These terms relate to the protocol, transport, and security settings in a node editor. When troubleshooting a connection, check each layer separately rather than only verifying the address and port.
VMess
Proxy protocolVMess is a proxy protocol in the Project V ecosystem that identifies connections using parameters such as a user ID. The protocol, transport, and TLS belong to separate configuration layers, so entering a UUID is only one step. An inaccurate system clock can affect authentication, so check the device time if a connection fails. Fields from older guides may not apply to every current version.
VLESS
Lightweight proxy protocolVLESS does not encrypt traffic on its own and is commonly paired with security mechanisms such as TLS or REALITY. The user ID, transport, and, where applicable, flow must match the server. Changing a node's protocol dropdown to VLESS does not convert a configuration for another protocol into a working VLESS node.
Trojan
Password authentication / TLSTrojan is a protocol that typically carries proxy requests over a TLS connection and uses password authentication. Check the server address, port, server name, and certificate verification settings as well as the password. If the password is correct but the handshake fails, check the TLS and transport settings instead of repeatedly importing the same configuration.
REALITY
Xray transport security mechanismREALITY is a transport security mechanism in the Xray ecosystem, not a standalone proxy protocol, and is commonly used with VLESS. The client must use the server's matching public key, server name, shortId, and other settings. Don't guess values from their names or substitute a client private-key field for the server's public key. Confirm that the core supports REALITY before importing the configuration.
TLS
Transport Layer SecurityTLS protects data in transit and verifies the identity of the other party through mechanisms such as certificates. The node address and server name may serve different purposes; the server name is typically used during the handshake and certificate verification. For certificate errors, check the domain, certificate validity period, and device clock rather than routinely disabling certificate verification.
WebSocket
WS / bidirectional transportWebSocket is a bidirectional communication method that proxy cores can use as a transport layer; it does not define node authentication. The path and Host setting must match the server's reverse proxy configuration, and path capitalization may matter. WebSocket can be used with TLS, so check transport connectivity and the security handshake separately.
Cores and ecosystem
Client and core names often appear in the same guide, but they refer to different things. To determine whether a feature is available, check both whether the client interface exposes the setting and whether the active core supports it.
Project V
V2Ray open-source ecosystemProject V is an open-source proxy technology ecosystem built around V2Ray, covering protocols, transports, routing, and configuration. The term “V2Ray client” often refers to a graphical app for managing these features, not just the core itself. Identify what a guide is discussing to distinguish interface steps from the underlying configuration syntax.
Xray
Xray Core / proxy coreXray shares technical roots with the V2Ray ecosystem and continues to develop its own features, including REALITY as a transport security mechanism. v2rayNG uses the Xray core, but feature availability still depends on the integrated version and configuration. If you see an “unsupported field” error, check which core is actually running rather than relying on the client name alone.
V2Fly
V2Ray community / V2Fly CoreV2Fly is a community maintaining V2Ray-related open-source projects, and V2Fly Core is its proxy core. v2flyNG belongs to this core family and is a different client from v2rayNG, which uses Xray. The cores share technical history, but that does not mean every new feature, field, or configuration file is interchangeable.
Clients and cores
Interface management / connection handlingThe client manages subscriptions, server lists, and settings; the core handles connections, routing, DNS, and other processing. A client importing a configuration does not mean the core can use every field in it. Check the client version, core type, and startup logs when troubleshooting. Before switching cores, back up the configuration and check protocol and parameter compatibility.
Subscriptions and nodes
A subscription is a source of configurations, a node is an individual connection configuration, and a test result reports the outcome of a specific test. Keeping these concepts separate makes it easier to diagnose update failures, incorrect settings, and connection timeouts.
Subscription
Configuration source and update linkA subscription is typically a link used to fetch and update server configurations. The returned format varies by provider and client. A successful update only means the configurations were fetched or parsed; it does not mean every node can connect. Subscription links may contain credentials, so remove the full URL from screenshots, logs, and support requests.
Node
Server connection configurationA node is a server configuration in the client, typically containing the protocol, address, port, authentication, and transport settings. The displayed name is only a label and does not confirm the server's location, speed, or connection capabilities. Installing a client does not provide a node; to add one manually, you need the complete settings from your service provider.
Subscription group
Organize by source or purposeSubscription groups organize subscriptions and servers by source or purpose, making them easier to update, filter, and review separately. A group is not a routing rule, and placing nodes in the same group does not automatically assign them the same traffic. Check the scope before bulk updates. Manual changes to subscribed nodes may be overwritten on the next update, so keep a separate copy.
Latency and real connection latency
Test method / request durationLatency measures how long a particular test takes; a TCP connectivity test and a webpage request through a proxy are not directly comparable. Real connection latency typically sends a request to a specified address through the proxy, so the result also depends on the target, DNS, and handshake. A lower figure does not mean faster downloads, and timeouts should be assessed alongside the target address and logs.
Routing and DNS
Routing selects an outbound, while DNS resolves domain names; the two can affect each other. Changing one without checking the other can lead to unmatched rules or unexpected DNS resolution paths.
Routing rules
Match conditions / outbound selectionRouting rules direct traffic to a specified outbound based on conditions such as domain, IP, or port. Rules are usually evaluated in order, so an earlier broad rule can prevent later, more specific rules from taking effect. Check both the conditions and outbound tags, as well as the default behavior. Requests that match no rule are still handled according to the core configuration.
Split tunneling
Direct / proxy / blockSplit tunneling directs different requests through direct, proxy, or blocked outbounds according to policy. It is the result of a set of rules, not something guaranteed by a mode name. To verify routing, test destinations expected to use direct and proxy routes, check the actual outbound, and see whether the core receives a domain name or an already-resolved IP address.
GeoIP
IP address listGeoIP is a collection of IP addresses organized by region or purpose for use in routing rules. The data needs regular updates, and its classifications may not exactly match where a service is deployed. When using GeoIP rules, check that the request has resolved to an IP address that can be matched; adding a list name alone does not resolve every domain.
GeoSite
Categorized domain listGeoSite organizes domains into categories and is commonly used in routing and DNS rules. Unlike GeoIP, it matches domain names rather than IP addresses. Category names, coverage, and update frequency depend on the data source. Before referencing a category, confirm it exists in the data and that the current core can read the data format.
DNS
Domain Name SystemDNS resolves domain names to IP addresses and other records, but there may be more than one resolution path: the operating system, browser, and proxy core can each make their own requests. After changing client DNS settings, check whether the target app uses that path. Check both the resolution result and the outbound used for DNS traffic; successful resolution does not guarantee a connection.
FakeDNS
Synthetic addresses / domain mappingFakeDNS maps domain names to synthetic addresses from a reserved address pool. When the core receives the associated traffic, it restores the domain name. These addresses are not the server's real address and cannot be used to determine its location. DNS interception, routing, and mapping restoration must work together; a broken route or stale cache can prevent requests from reaching their destination.
DNS leak
Unexpected DNS resolution pathA DNS leak occurs when resolution requests are handled by a resolver or route other than the one intended by the configured policy. Whether an issue is a leak depends on the policy; a local resolver appearing in results is not enough to draw that conclusion. Check app-specific encrypted DNS, system resolver settings, and the scope of TUN interception. Test pages only show the resolution path used for that test.
Client features
These terms explain how traffic enters the client. System proxy, app-level proxy settings, and TUN differ in the traffic they capture. Before enabling any of them, check how the target app handles network traffic.
System proxy
Operating system proxy settingsThe system proxy registers the local proxy address and port in the operating system's proxy settings for apps that follow them. Some apps use their own network settings, so enabling the system proxy does not guarantee that their traffic will go through the client. It also does not capture all UDP traffic. If webpages stop working after you close the client, check whether the system proxy still points to a local port that is no longer active.
TUN mode
Virtual network interface / traffic captureTUN mode uses a virtual network interface to send matching traffic through the proxy. It typically requires additional permissions and involves routing and DNS settings. It can capture traffic from some apps that ignore system proxy settings, but coverage depends on the implementation, exclusion rules, and configuration. If connections fail after enabling it, first check permissions, other virtual network adapters, and DNS interception rather than layering on more proxy modes.
HTTP and SOCKS proxies
Local proxy inboundHTTP and SOCKS are common ways for apps to connect to a local proxy inbound; they are separate from the remote node protocol, such as VMess or VLESS. Configure the correct proxy type, address, and port in the app—not just the port number. HTTPS destinations can be accessed through an HTTP proxy that supports CONNECT. SOCKS UDP support depends on both the app and the proxy route.
Traffic sniffing
Sniffing / domain detectionTraffic sniffing identifies metadata such as domain names from the handshake information in some connections to help the core match routing rules. It does not decrypt HTTPS content or guarantee that every app's destination domain can be detected. Whether the detected domain is used to rewrite the destination address depends on the core settings. For compatibility issues, check the logs instead of enabling every sniffing option at once.
Allow LAN connections
Proxy sharing / listening scopeAllow LAN connections lets other devices on the same network access the local proxy inbound, but does not configure those devices to use the proxy automatically. Check the listening address, proxy port, and firewall, then enter the computer's local network address on the other device. Limit access to trusted networks to avoid exposing the port publicly, and restore the relevant settings when you stop sharing.
From terminology to configuration
If a node imports but will not connect, check the protocol, transport, and security settings first, then review the core logs. If only some apps have problems, check the traffic captured by the system proxy or TUN. If domain rules do not match, check how DNS and routing work together.
For your first setup, follow the Getting Started guide to import and test a configuration. For step-by-step troubleshooting, see the Help Center. Change one setting at a time so you can identify what fixes the issue.