Find Terms by Configuration Area
If an import fails or the node list is empty, start with “Subscriptions and Nodes.” For protocol fields, see “Proxy Protocols.” When adjusting bypass, direct connections or domain matching, see “Routing.” For virtual interfaces or resolution paths, see “Transport and Encryption.”
Proxy Protocols
Protocol fields determine how the client establishes a session with the server. Matching names do not mean every parameter is interchangeable; check the transport and security layers when importing a configuration.
- VMess vmess
- VMess is a proxy protocol in the Project V ecosystem. Client configurations typically include a server address, port, user identifier, security options and transport parameters. Share links can carry common fields, but clients may interpret extension fields differently.
- VLESS vless
- VLESS has a streamlined protocol structure and often delegates encryption and peer verification to an external security layer such as TLS or REALITY. Confirm the user identifier, transport, flow-control option and server name together. Copying only the address and port is usually not enough to establish a complete connection.
- Trojan trojan
- Trojan is a proxy protocol that carries data over a TLS connection. Common fields include the server address, port, password, server name and certificate verification options. TLS parameters must match on both client and server; any key mismatch can cause the handshake to fail.
- REALITY security
- REALITY is a transport security solution in the Xray ecosystem, commonly paired with VLESS. It is not a standalone node list and cannot be enabled with a single switch. The client core must support it, and the public key, short ID, server name and related parameters must be configured correctly.
- TLS transport security
- TLS is a general-purpose security protocol for establishing encrypted connections and verifying the identity of the communicating peer. In client configurations, the server name usually participates in certificate verification and should not be treated as the connection address. Disabling certificate verification changes the security boundary and should not be kept as a routine troubleshooting measure.
Cores and Architecture
The graphical client imports, displays and generates configurations, while the proxy core actually handles protocols, DNS and routing. Understanding this relationship helps identify whether a feature comes from the interface or the core.
- V2Ray Project V
- V2Ray commonly refers to the configuration models, protocol implementations and tools in the Project V ecosystem, and may also specifically mean an earlier core program. Use the context to determine whether a guide refers to the broader ecosystem or a particular core. A client name containing V2Ray does not mean every client uses the same core branch.
- V2Fly v2fly core
- V2Fly is a community-maintained project and core family continuing the V2Ray technical direction, emphasizing general-purpose proxying and modular configuration. v2flyNG follows this core direction and suits Android scenarios that require compatible protocol implementations and configuration semantics. Choose a core based on the protocols you actually need.
- Xray xray core
- Xray is a core branch developed from the related technology ecosystem, supporting features such as VLESS and REALITY. Common v2rayN and v2rayNG configurations may rely on Xray capabilities. Whether a share link works depends on the client version, core support and completeness of its configuration fields.
- Proxy Core core
- The proxy core is the underlying program responsible for protocol parsing, connection establishment, DNS handling and routing. A graphical client typically converts user selections into a core configuration and then starts the corresponding process. When startup fails, distinguish between an interface setting error, a generated configuration error and a core runtime error.
- Inbound inbound
- Inbound is the entry point where the core receives traffic from local applications, commonly through local SOCKS, HTTP and TUN interfaces. Its configuration defines the listening address, port and reception method. The system proxy usually sends requests from compatible applications to a local HTTP or SOCKS inbound.
- Outbound outbound
- Outbound is the exit path for traffic after core processing and may point to a remote proxy, a direct connection or a blocking policy. The main result of a routing rule is selecting an outbound for matched traffic. When renaming an outbound tag, also check every routing rule that references it.
Subscriptions and Nodes
Subscriptions distribute and update configurations in batches, while nodes are individual connection entries available for selection. Speed tests, grouping and update operations all revolve around these two layers.
- Subscription subscription
- A subscription is a set of nodes or configuration data supplied by a URL and updated periodically. After adding a subscription URL, the client usually needs one update before the nodes appear in the local list. If an update fails, check the URL, network access, returned content and format compatibility in that order.
- Node profile
- A node is a single remote connection profile in the client, containing protocol, address, port, authentication parameters and transport settings. Its name is for identification only and does not determine connection quality. Assess usability through configuration completeness, connection tests and actual access results.
- Subscription Group group
- A subscription group is the management unit the client uses to organize nodes and collections from different subscription sources. Groups can distinguish update sources, filter nodes or apply separate update policies. Before deleting one, confirm that its nodes are not referenced by the active configuration or routing selections.
- Latency latency
- Latency is the time from sending a probe on the local device to receiving a response. It reflects the connection cost for a specific target, moment and test method, and cannot by itself represent throughput or long-term stability. A series of results is more informative than a single number.
- Real Connection Latency real connection
- Real connection latency measures the time required to establish an actual protocol connection or reach a test target, making it closer to the client's real operating path. It is not the same test as a simple network probe. If the results differ significantly, check the protocol handshake, DNS, routing and transport settings.
Routing
The routing system reads the destination domain, IP, port or other attributes and then chooses an outbound. Rule order and matching conditions matter equally; an overly broad rule may intercept traffic before later rules can match.
- Routing Rule routing rule
- A routing rule determines how traffic leaves the client based on conditions such as domain, IP, port, network type or process. Multiple rules are generally evaluated in configuration order, and the first match may determine the result immediately. Record the current mode before making changes so you can roll back if needed.
- Traffic Routing traffic routing
- Traffic routing sends different targets or applications through a proxy, a direct connection or another outbound according to rules. It does not rank nodes; it determines which path each traffic class takes. When domain and IP rules coexist, also consider DNS results and rule priority.
- GeoIP IP ruleset
- GeoIP organizes rule data by IP address region or network category so the routing system can match destination addresses. It relies on rule data files rather than real-time geolocation. The data version and classification method can affect the final match.
- GeoSite domain ruleset
- GeoSite is a collection of domain rules organized by purpose or category, reducing the need to maintain domains individually. Matching is generally based on the domain itself rather than the IP ultimately returned by the server. Confirm that the client core includes the required rule data before using it.
- System Proxy system proxy
- The system proxy is a proxy address setting stored by the operating system and provided to compatible applications, usually pointing to a client-local listening port. Only applications that read system proxy settings will actively use this path. For applications that ignore it, consider TUN mode or the application's own proxy configuration as appropriate.
Transport and Encryption
These terms describe how data enters the core, how it is carried and how domain resolution is completed. When troubleshooting connectivity, examine the protocol, security layer, transport layer and DNS path separately.
- TUN Mode virtual interface
- TUN mode receives system traffic through a virtual network interface and can cover applications that do not read system proxy settings. It usually requires the relevant system permissions and may modify the routing table and DNS. If the network becomes abnormal, exit TUN mode first, then check whether the virtual interface and routes have been restored.
- FakeDNS DNS mapping
- FakeDNS temporarily assigns mapped addresses to domains and keeps the domain-to-mapping relationship in the core. When an application connects to a mapped address, the core can recover the original domain and continue domain-based routing. It is often used with TUN mode, but the address pool and DNS flow must be planned correctly.
- DNS Leak DNS path
- A DNS leak occurs when an application's domain queries bypass the expected resolution path and are sent through another DNS channel. Common causes include application-level resolution, system caches, incomplete TUN configuration or inconsistent rule order. During troubleshooting, verify the resolution entry points used by the application, system and client core separately.
- WebSocket ws
- WebSocket is a bidirectional transport built on HTTP connection upgrades and can carry proxy protocol traffic. Configuration commonly includes a path, host field and TLS-related parameters. If the path or host field differs between client and server, the connection may be rejected at the transport layer.
- gRPC http/2
- gRPC is an HTTP/2-based remote procedure call framework used in some configurations to carry proxy data streams. Related settings commonly include a service name, security layer and server name. Its field structure differs from WebSocket, so replacing only the transport name while keeping the old parameters will not work.
- Transport Layer transport
- The transport layer describes the connection form used to carry proxy protocol data, with common options including TCP, WebSocket and gRPC. Even with the same protocol, changing the transport layer changes the fields and handshake process. If transport information is missing after import, return to the configuration source and verify it instead of switching options at random.
Map Terms to Client Settings
Use this glossary to confirm concepts, then continue to the configuration tutorial for complete procedures. To understand how the core, subscriptions, routing and TUN fit together, read the from-beginner-to-advanced handbook.