Protocols define how systems communicate, cores implement them, and routing determines where connections go. Understand these layers before changing settings.
Browse 25 common terms across five categories. Use the link beside any heading to jump directly to it. Menu names may vary by client version.
{
"routing": {
"rules": [
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
}
]
}
}Proxy protocols, transports, and security mechanisms are different things. Seeing VLESS, WebSocket, and TLS together does not mean the configuration uses three separate clients.
Proxy protocol / authentication and data protection
VMess is a proxy protocol in the V2Ray ecosystem. It authenticates connections using parameters such as a user ID and has its own data protection mechanism. The node’s address, port, user ID, and transport settings must match the server; the protocol name alone does not determine compatibility. If authentication fails, check the device clock too, since a significant time difference can prevent a connection.
Proxy protocol / lightweight protocol layer
VLESS handles proxy requests and authentication but does not encrypt traffic on its own. Deployments typically pair it with a security mechanism such as TLS or REALITY, so “supports VLESS” does not mean a client supports every combination used by a particular node. After importing, keep the original security settings and parameters such as flow; do not reuse settings from another node.
Proxy protocol / password authentication
Trojan typically uses TLS to protect connections and a password for authentication. A correct password is only one requirement: the server address, port, server name, and certificate verification must also match. If certificate verification fails, check the configuration and device clock; disabling verification is not a general fix.
Transport security / encryption and authentication
TLS protects communications and verifies the identity of the other party using mechanisms such as certificates. It is not another name for a specific proxy protocol. The server name in the client usually plays a role in the TLS handshake and certificate verification, and may differ from the connection IP. If the port is reachable but the TLS handshake fails, the issue may be in the security negotiation rather than basic network connectivity.
Transport security / Xray ecosystem
REALITY is a transport security mechanism in the Xray ecosystem, not a proxy protocol that can replace VLESS on its own. It requires a compatible client core, and parameters such as the public key, server name, and short ID must match the server. Renaming a standard TLS configuration does not turn it into a REALITY configuration; a field being available in the interface does not guarantee that the core can use it.
Transport / commonly abbreviated WS
WebSocket is a bidirectional communication method that can carry protocol data in a proxy configuration. Fields such as the path and Host often need to match the server or reverse proxy; even an extra slash can change where a request goes. WebSocket and TLS operate at different layers and can be combined. When troubleshooting, check the transport and security settings separately.
A client’s name is not the name of its core. To check whether a configuration will work, look at the core actually in use, its version, and its support for the required features.
Project ecosystem / modular network tools
Project V is a project and technology ecosystem built around modular network proxy tools, with V2Ray as one of its core projects. It uses different modules to organize inbounds, outbounds, and routing; it is not the name of a graphical client. When reading documentation, check whether it refers to the ecosystem, a specific core, or a client menu.
Proxy core / independently evolving implementation
Xray grew out of V2Ray-related code and has since evolved independently. Features such as REALITY are closely associated with its ecosystem. v2rayNG uses the Xray core, but its feature support still depends on the bundled core version. Similar-looking configurations are not necessarily interchangeable, so do not swap complete configs containing core-specific fields.
Maintainer community / V2Ray implementation
V2Fly is a community that maintains V2Ray-related implementations and documentation. The “V2Fly core” usually refers to its maintained V2Ray implementation. v2flyNG is an alternative Android client that uses this core. Compare cores by protocol, security mechanism, and configuration fields; they are not simply different names for old and new versions of the same program.
User interface / connection handling
The client manages subscriptions, displays settings, and generates configuration; the core handles incoming and outgoing connections. v2rayN is a graphical client, not another spelling of the V2Ray core. Core options depend on the version in use. If startup fails, first determine whether the client interface will not open or it opens but cannot start the core—the two problems have different troubleshooting steps.
A subscription is a way to fetch configurations; a node is a set of connection parameters; a test result reflects just one test run.
Subscription / fetch multiple configurations
A subscription lets a client fetch a set of connection configurations from one URL, instead of entering nodes one by one. The URL may contain an access token, so protect it like account credentials and hide the full URL in screenshots. Saving the URL does not fetch configurations—you still need to update the subscription. A subscription also does not automatically configure the system proxy.
Connection configuration / more than a server name
A node is usually a configuration containing a server address, port, authentication details, transport, and security settings. Its display name is mainly for identification; it does not tell you the server’s location, performance, or availability. A single server may offer multiple configurations, so troubleshoot using the actual parameters and logs rather than comparing node names.
Fetch and parse / not a software update
A subscription update requests the subscription URL again and parses the response into configurations the client can use. It does not upgrade the client or its installer, and it does not guarantee that the server is currently reachable. If an update fails, check in order that the URL is complete, the request succeeds, and the response format is supported. Updating through a proxy also depends on that proxy already working.
Latency / start with the test method
Latency is the time from starting a specified test to receiving a response. Interpret the milliseconds shown in the interface in light of the test method: a port connection test, a proxy request, and a full webpage load measure different things. A lower value does not necessarily mean faster downloads, and one timeout does not prove a node is consistently unavailable. Retest under the same conditions.
Proxy path test / varies by client
Proxy latency usually means the time taken to request a test URL through the selected proxy configuration, making it a closer measure of real proxy access than a simple server port check. Whether the test includes DNS resolution, handshakes, or other steps depends on the client and test settings. A failure could be caused by the node, resolver, or test destination; compare logs and test other destinations before drawing conclusions.
Rules select an outbound only after a connection reaches the client. Domains, IP addresses, and DNS results can all affect which rules match.
Routing rules / conditions and outbounds
Routing rules select an outbound for a connection based on conditions such as domain, destination IP, or port. Rules are usually checked in order, so an earlier broad rule may prevent a more specific rule later on from matching. Before editing rules, identify what should match and which outbound it should use, then check that the outbound tag exists. The fallback behavior depends on the full configuration and the core in use.
Route by condition / direct, proxy, or block
Traffic routing applies rules to send different connections direct, through a proxy, or to a block action; it does not mean splitting traffic evenly across multiple nodes. Client options such as “Bypass mainland China” usually refer to a set of preset rules, and their actual scope depends on those rules and data files. After changing a preset, check where specific destinations go instead of relying on the selected button alone.
IP address groups / geoip.dat
GeoIP uses address groups to help routing rules match destination IPs. A common reference is geoip:cn, with related data often stored in geoip.dat. It matches IP address classifications; it does not directly identify a website’s owner or content language. Data sources, update schedules, and changes to IP allocations can all affect results, so GeoIP is not a real-time or definitive way to determine a location.
Domain groups / geosite.dat
GeoSite organizes domains into categorized groups. Rules can reference them using forms such as geosite:cn; the common data file is geosite.dat. It handles domain classifications, unlike GeoIP, which matches IP addresses. Available tags depend on the data file in use. Copying a tag that does not exist may cause the configuration to fail to load, so check the data source when updating rules.
Domain Name System / names to addresses
DNS resolves domain names to IP addresses and other records so apps know where to connect. The operating system, browser, and proxy core may each have their own resolution settings, so changing DNS in the client may not affect every app. If a domain will not open but its IP address is reachable, distinguish a resolution failure from different DNS results or a connection failure before changing all your node settings.
Synthetic addresses / domain mapping
FakeDNS assigns a synthetic IP to a domain and keeps a mapping between them, allowing the client to recover the domain later when it intercepts traffic. The synthetic IP is not the website’s actual server address; DNS resolution and traffic interception must work together. If an app gets a synthetic address but bypasses the client that can resolve the mapping, the connection may fail. FakeDNS is not a general-purpose fix for every DNS problem.
First check whether the app sends its connections to the client, then check how the client handles them. Traffic capture and routing rules solve different problems.
App entry point / only applies to apps that honor it
The system proxy is a set of proxy settings provided by the operating system. Apps that honor these settings send requests to a specified local proxy endpoint. v2rayN’s “Set system proxy automatically” option configures this entry point; it does not capture traffic from every app or every network protocol. “Clear system proxy” usually removes the related settings—it does not delete subscriptions or nodes. If you lose connectivity after exiting, check for leftover proxy settings pointing to a closed client.
Virtual network interface / route-based traffic capture
TUN mode captures traffic through a virtual network interface and system routes, and can often cover apps that ignore the system proxy. It typically requires extra permissions and coordinated routing and DNS settings, and may conflict with other networking software. It is not the same as a “global proxy”: captured connections can still be routed direct or through a proxy. Android clients often use the system VPN interface to capture traffic, even if the menu does not call it TUN.
Unexpected resolution path / assess against your policy
A DNS leak usually means domain queries were sent to a resolver outside the intended path. Browser secure DNS, the system resolver, and client DNS settings can all affect the outcome, so one toggle does not tell the whole story. First decide which path queries should take, then check where they actually went. If direct DNS queries are part of your intended policy, not routing them through a proxy does not by itself make them a leak.
Multiplexing logical connections / not a universal speed boost
Mux attempts to carry multiple logical connections over fewer underlying connections, potentially reducing repeated connection setup. Results depend on the protocol, network conditions, and implementations at both ends. Some combinations are unsuitable, and packet loss can affect multiple connections at once. Unless you have a specific reason to change it, keep the client’s recommended setting. To compare results, test one change at a time using the same node and conditions.