Understand common terms by configuration task. Confirm the protocol and core first, then check subscriptions, routing, DNS, and proxy modes so similarly named settings are not confused.
Protocols define how the client and server exchange information; transports and security layers determine how the connection is carried. Verify these settings together when importing a node.
vmess
VMess is a client–server communication protocol in the Project V ecosystem. A node typically includes a user ID, server address, port, and encryption-related settings. Clients also combine VMess with transports such as TCP and WebSocket, so confirming the protocol alone is not enough. If importing fails, check the transport type, path, server name, and port as well.
vless
VLESS is a streamlined communication protocol in which identity, encrypted channels, and underlying transports are usually described by separate settings. It is often combined with TLS, REALITY, TCP, WebSocket, or gRPC. Flow control, server name, public key, and short ID are not universally required; use the combination defined by the node.
trojan
Trojan authenticates the client with a password and typically establishes the connection with TLS. Check the password, server name, port, and certificate verification options together. Matching protocol names do not make configurations interchangeable; transport parameters must still match the server.
security: reality
REALITY is a transport security solution supported by the Xray core and commonly paired with VLESS. Client settings typically include a public key, short ID, server name, and fingerprint, which work together during connection setup. If the current core or client does not recognize these fields, check the core type and configuration format before removing parameters.
network: ws
WebSocket creates a bidirectional connection through HTTP upgrade and is commonly abbreviated as WS in clients. A node may require a path and Host in addition to the WS transport. Slashes, letter case, and extra path parameters can all affect the result, so copy them exactly when entering settings manually.
network: grpc
gRPC is an HTTP/2-based remote procedure call framework that can also serve as the underlying transport for protocols such as VLESS. Common client fields include the service name and multiplexing options. Its connection model differs from WebSocket, so replacing only the transport name while keeping all old parameters will not work.
security: tls
TLS encrypts connections and authenticates the server; the server name in the client usually participates in certificate verification. When the node address is an IP, a separate domain matching the certificate may still be required. For certificate-name mismatches or handshake failures, first check the system time, server name, and the node's security-layer settings.
The graphical client handles the interface and configuration management, while the core handles protocols, DNS, routing, and actual connections. Understanding this division helps determine whether a capability depends on the client version or the core.
ecosystem
Project V is an open-source technology ecosystem built around proxy protocols, cores, and supporting tools. In everyday use, V2Ray may refer to the earlier project or more broadly to related cores and clients, depending on context. When reading configuration guides, distinguish the ecosystem, the specific core, and the graphical client.
v2fly-core
V2Fly is a community-maintained family of Project V cores that parses configuration and executes protocol, DNS, and routing logic. It has its own feature scope and configuration evolution. When choosing clients such as v2flyNG, confirm that the subscription protocols match the capabilities of the current V2Fly core.
xray-core
Xray is a core branch that grew from the Project V ecosystem and supports protocols and transports such as VLESS and REALITY. v2rayN and v2rayNG commonly use Xray for actual connections. Configuration fields are not always equivalent across cores, so check protocol support and routing syntax before switching cores.
desktop client
v2rayN is a desktop graphical client for Windows, macOS, and Linux that manages subscriptions, servers, system proxy settings, routing, and multiple cores. The interface turns user settings into configurations readable by the core. When troubleshooting, check the v2rayN status and the selected core's runtime log separately.
Android client
v2rayNG is a graphical Android client that typically uses the Xray core for node connections and routing. When enabled, it uses the system-provided VPN service to capture the traffic it needs to handle. The interface manages subscription imports, node selection, and per-app rules, while specific protocol capabilities still depend on the core.
Android client
v2flyNG is a graphical Android client built on the V2Fly core family. It suits configurations that specifically require V2Fly compatibility. When switching between it and v2rayNG, compare more than the interface: verify the subscription protocols, routing fields, and core support range.
Subscriptions deliver configurations in batches, while nodes are individual connection records you can select. Updating, filtering, and testing are separate operations; a populated list does not guarantee that a node is connectable.
subscription
A subscription is a collection of node configurations provided by a server and periodically updated by the client, usually through a subscription URL. Adding the URL only registers the source; the client must still run an update to retrieve the server list. If an update fails, check that the URL is complete, the network is reachable, and filtering is not enabled for the subscription group.
server profile
A node is a single server connection profile in the client, including its address, port, protocol, identity details, and transport parameters. The node name is mainly for identification and does not determine connection capabilities. Nodes with the same name may come from different subscriptions, so confirm the group and complete parameters before editing one.
subscription group
A subscription group keeps nodes from different sources or for different purposes separate. Each group can be updated, enabled, and filtered independently. When using multiple subscriptions, groups reduce confusion caused by duplicate names. Deleting a group usually removes the nodes generated from that source, so confirm whether manual configurations should be retained first.
filter
Server filtering organizes the list by keywords in node names, regular expressions, or other conditions. Include conditions retain matching items, while exclude conditions hide unwanted ones. If the list is empty after an update, temporarily disable filtering first to confirm that the original subscription returned nodes.
latency
Latency is the time from when data leaves the client until a response arrives, but the target and method change what the value represents. A TCP handshake, ICMP response, and full proxy request measure different stages. When choosing a node, also consider connection success rate, target-service response, and performance over sustained use.
real delay
True connection latency checks availability and response time by establishing an actual proxy connection and requesting a test target. Unlike probing only the server port, it covers more stages, including the protocol handshake, transport security layer, and proxy request. A failed test does not necessarily mean the server is offline; also check DNS, routing, and the core log.
The routing module does not create subscriptions; after a request enters the core, it decides which exit to use. Rules are usually matched from top to bottom, so order, scope, and the default exit all affect the result.
routing.rules
Routing rules select an outbound based on the domain, IP, port, network type, protocol, or inbound tag. When several rules exist, the core usually processes them in configuration order and uses the first match. Before adding a rule, make sure it will not be overridden by an earlier, broader rule.
traffic routing
Traffic routing sends different targets or request types through proxy, direct, or blocked outbounds. Common conditions include domain categories, destination IPs, ports, and inbound tags generated by applications. The result depends on whether the request enters the core and whether the resolved domain or IP is available for rule matching.
geoip:cn
GeoIP is rule data organized by IP region or network category, allowing the routing module to match destination IPs in batches. It depends on the contents and update time of local rule files, so its categories should not be treated as real-time geolocation. A domain request can participate in IP-based rules only after its destination IP has been resolved.
geosite:cn
GeoSite is a collection of domain rules organized by site category, allowing a routing configuration to reference a group of domains at once. It matches domains rather than server IPs, making it useful for classification before resolution. Category names are defined by the data file; an unknown name may cause the core to fail while loading the configuration.
outbounds
An outbound is the traffic exit used after the core processes a request; common types include proxy, direct, and block. Routing rules usually reference an outbound by tag, so the tag must match the outbound definition in the configuration. The default outbound handles requests that match no other rule.
freedom / direct
Direct means the device accesses the target through its current network without using the selected proxy node. Different clients or cores may display it as direct, freedom, or a localized equivalent. Direct requests are still affected by system DNS, network routing, and the local firewall.
These terms determine how traffic enters the client, how domains are resolved, and where to find clues when errors occur. Confirm the capture method first, then check DNS and routing, and finally read the log by connection stage.
system proxy
The system proxy is set by the client modifying the operating system proxy settings, causing apps that follow them to send requests to the local proxy port. It does not automatically capture every process; some apps use independent network settings or connect directly. Restore the system proxy before quitting the client to prevent apps from pointing to a stopped local port.
tun
TUN mode captures system network traffic through a virtual network interface, including traffic from apps that ignore system proxy settings. It involves the routing table, DNS, and virtual network adapter, so it requires more system-level configuration than a system proxy. If it fails to start, check permissions, adapter status, and programs that may already be capturing the same traffic.
fakedns
FakeDNS returns mapped addresses to applications while the core preserves the relationship between each address and its original domain. After the request enters the core, the domain can be restored and domain-based routing rules can continue to apply. It is commonly used with TUN mode; plan the address pool and DNS flow together to avoid conflicts with existing LAN subnets.
dns.servers
DNS is the basic network service that resolves domain names to IP addresses. Clients can assign DNS servers and query policies by domain. The layer where resolution occurs—system, application, or proxy core—affects whether domain routing works. When changing DNS, record the original settings and test name resolution and node connectivity separately.
DNS path
A DNS leak occurs when DNS queries bypass the expected path or rules and are sent through another resolution channel. Common causes include an app's built-in resolver, DNS not being captured by the system proxy, incomplete TUN rules, or a fallback resolver responding first. During troubleshooting, define who should resolve each domain type, then inspect the system, client, and core settings layer by layer.
allow LAN
LAN sharing lets other devices on the same LAN connect to the local proxy port exposed by the client. After enabling it, check the listen address, port, firewall, and network reachability between devices. Expose it only on a trusted network, and give each device the correct host address and proxy type.
log
The runtime log records core startup, configuration loading, DNS queries, routing matches, connection establishment, and errors. Start with the first error, then use the timeline to determine whether it occurred during resolution, the handshake, or the target connection. Higher verbosity adds detail; restore the usual level after troubleshooting to reduce noise.
Once the node protocol and core are confirmed, open the usage guide to import subscriptions, choose nodes, configure the system proxy, and verify connections. For GeoSite, TUN, FakeDNS, or multiple subscription groups, consult the advanced configuration manual.