Quick reference · 27 terms
Protocols, cores, subscriptions, and traffic routing
Identify which layer a concept belongs to, then match it to the relevant client setting. Protocols define how peers communicate; cores handle connections; clients manage configuration. Subscriptions provide server settings, while routing and DNS determine how traffic and domain lookups are handled.
Jump to a category below, or link directly to any term heading. For hands-on setup, start with the Getting Started Guide; to adjust rules, see the Advanced Configuration Manual.
How connections work
Keep proxy protocols, transport methods, and security mechanisms distinct. A protocol can work with different transports, but the settings on both ends must be compatible.
VMess is a proxy protocol in the Project V ecosystem with authentication and data protection. Server configurations typically include settings such as a UUID. The client and server need compatible authentication and transport settings, and a significant clock difference can cause connection failures. A successful import only means the client recognized the configuration; it does not confirm that the server is reachable.
VLESS is a lightweight proxy protocol that uses UUIDs for authentication. It does not encrypt payloads on its own, so configurations typically pair it with a security mechanism such as TLS or REALITY. Check the protocol, transport, and security settings separately. A client that recognizes a VLESS link may not support every extension in it through its core.
Trojan typically runs over TLS and uses a password for authentication at the proxy protocol level. The password and TLS certificate validation serve different purposes; a correct password does not verify the server's identity. When troubleshooting, check the password, server address, port, and server name separately rather than repeatedly changing the password.
REALITY is a transport security mechanism in the Xray ecosystem, often used with VLESS; it is not a subscription format. The client's public key, server name, shortId, and other settings must match the server configuration, and support depends on the core version. If an imported configuration reports unsupported settings, check core compatibility instead of removing security fields to force a connection.
In client configuration, the transport layer usually describes how proxy data is carried, for example over TCP, WebSocket, or gRPC, rather than a specific layer in the network model. Proxy protocols such as VMess and VLESS can use different transports, depending on the core. Fields such as path, Host, and service name belong to particular transport settings and cannot be copied blindly between transports.
TLS provides authentication, encryption, and integrity protection for network connections. Clients typically verify the peer using a certificate and server name. The connection address may differ from the name used for verification, so follow the server configuration. Certificate errors can result from a name mismatch, an expired certificate, or an incorrect system clock. Disabling verification changes the security boundary and should not be a routine fix.
Interface and runtime
Graphical clients manage subscriptions and settings; the core handles the actual connections. Whether a feature works depends on the client exposing it, the core supporting it, and the configuration being correct.
V2Ray usually refers to a network proxy core in the Project V ecosystem and is also used as a general term for related technologies. The core reads its configuration and handles inbounds, routing, and outbounds; the client provides the graphical interface. When someone says “V2Ray configuration,” first clarify whether they mean core JSON, a single share link, or a subscription URL—each is imported in a different place.
V2Fly is a community project that maintains and develops the V2Ray core, also called the v2fly core in some documentation. It is not a graphical client, and client and core updates may not happen in sync. Check the specific core version and client compatibility before relying on a protocol or configuration field.
Xray is a core project that grew out of the V2Ray ecosystem, with its own protocols, transports, and security features. It shares foundations with V2Fly, but that does not mean their configurations are fully interchangeable. For features such as REALITY, check support in the specific core rather than relying on whether the client name includes V2Ray.
v2rayN is a graphical client for Windows, macOS, and Linux that manages subscription groups, servers, routing, and core processes. The cross-platform desktop version uses a modern interface, while Windows also has a WPF version that retains the classic interface; layouts may differ. Check your operating system and processor architecture when choosing a download, and verify feature support against the core you use.
v2rayNG is an Android graphical client that uses the Xray core and provides subscription import, server selection, and routing settings. Starting the service typically requires system VPN permission. This lets the client receive relevant traffic through the system interface, but does not confirm a successful server connection. Also check the active server, connection logs, and whether the destination is actually reachable.
v2flyNG is an Android graphical client that uses the V2Fly core and can be an alternative when core compatibility matters. Its workflow is similar to v2rayNG, but their underlying feature support is not identical. Before moving a subscription, check that its protocols and transport settings are supported. For help choosing, see the comparison of three clients.
Where configuration comes from
A subscription is a source of configuration, a server is a set of connection settings, and a test result records a particular probe. They answer different questions: how to update, where to connect, and whether access worked this time.
A subscription is a URL or data source that lets a client retrieve and update a set of server configurations, often as encoded text or another supported format. After adding a subscription, you usually need to update it before servers appear in the list. A successful update does not mean every server can connect. Subscription URLs may contain credentials, so redact the full URL and any sensitive parameters in screenshots and logs.
A server is a set of settings in a client for establishing a proxy connection, typically including an address, port, authentication details, protocol, and transport. A server's display name is just a label; it does not reliably indicate its location or quality. After selecting a server, start the relevant service and confirm that application traffic actually enters the client.
A share link encodes a single server configuration as text for easy copying and import. Common prefixes include vmess://, vless://, and trojan://. It is typically used to import one configuration, while a subscription URL retrieves and updates a set of configurations. Links may contain passwords or UUIDs, so treat them as credentials and never post them in public logs.
Latency is the response time measured by a specific test method; its meaning depends on which connection stages the tool covers. A TCP port probe is not equivalent to testing a web page through a proxy. The test URL, timeout, and local network also affect results. For a fair comparison, use the same method and target. Lower latency does not automatically mean higher throughput or a more stable long-lived connection.
Real connection latency usually means the time a client takes to reach a test URL through the selected server, covering more stages than a basic port probe. The exact stages depend on the client and test target, and results may be affected by DNS, the handshake, and the destination site's response. A timeout does not necessarily mean the server is offline; the test URL may be unreachable. Likewise, a successful test does not replace checking the target application.
Where a connection goes
First make sure traffic enters the client; then check rule order and outbound selection. Rule labels are configuration references, not commands that work just because of their names.
Routing rules select an outbound based on a domain, IP, port, or other criteria. They usually run top to bottom, with the first matching rule taking effect. A broad rule placed near the top can prevent more specific rules below it from being reached. What happens when no rule matches depends on the core and client-generated configuration. Check the default outbound rather than assuming unmatched connections will use the proxy.
Traffic routing sends connections to different outbounds—such as proxy, direct, or block—according to rules. For example, local network addresses can go direct while selected domains use a proxy. This describes how traffic is handled after it enters the core; it does not make every application send traffic there automatically. If an app bypasses the system proxy, changing routing rules alone usually will not affect it. Check how its traffic enters first.
GeoIP is a categorized collection of IP addresses that routing rules can reference with entries such as geoip:private. Matching uses the actual destination IP and data file, not the domain text or server label. The collection can change as address allocations and data are updated, so confirm the current data file includes the category you reference.
GeoSite is a categorized collection of domain rules. Entries such as geosite:cn or geosite:category-ads-all simplify routing for large numbers of domains. The specific data file determines what each category covers; it does not guarantee that every listed domain behaves the same way on the network. Matching also depends on whether the core knows the domain and whether an earlier rule has already matched.
An outbound is the configuration the core uses to handle a connection. It can connect through a proxy server, connect directly from the local machine, or reject the connection. proxy, direct, and block are commonly used label names; the associated configuration determines what they do. Make sure a referenced label matches a defined outbound—a name in a rule does not create one.
Traffic entry and DNS resolution paths
Network modes determine which traffic enters the client; DNS determines how domain names are resolved. They affect each other, but enabling one does not automatically configure the other.
DNS resolves domain names to IP addresses and other records so applications can find their destinations. The operating system, browser, and proxy core may each use a different resolver, so changing one does not necessarily change the others. To troubleshoot, identify which component makes the query and which route it takes, then check the cache and response—not just a different DNS address.
A system proxy is a proxy setting provided by the operating system. Only apps that honor it will use it. Browsers, extensions, and command-line tools may have separate proxy settings, so browser access does not prove that command-line tools use the same route. If an app keeps trying to connect to a closed local proxy port after the client exits, check whether the system proxy settings were restored.
TUN mode uses a virtual network interface to capture system traffic and pass it to the proxy client, typically covering more traffic than the system proxy. It also requires system routing, DNS, and appropriate permissions, and may be affected by other VPNs, virtual adapters, or security software. Turning it on does not guarantee that all traffic is being handled as intended. Test web, command-line, and local network access separately.
FakeDNS returns a synthetic IP from a managed address pool for a domain and stores the mapping between them, allowing the domain to be recovered for later connections. The synthetic address is not the destination site's real public IP. Subsequent traffic must pass through a path that can recognize the mapping. FakeDNS needs to work with traffic capture and routing; if an app still has a synthetic address cached after FakeDNS is disabled, clear the cache or reconnect.
A DNS leak usually means a domain lookup was handled by a resolver or network egress other than the intended path. Assess it against your routing goals: an intentionally direct DNS lookup is not automatically a problem just because it bypasses the proxy. Check system DNS, browser Secure DNS, client DNS settings, and the actual IPv4 and IPv6 paths.