CLIENT TERMINOLOGY
Learn to read connection settings in share links. Browse six categories to distinguish which protocol is used, which core handles it and which traffic enters the proxy.
Setting names may vary between client versions. Follow the server settings, the current client interface and the capabilities of the selected core.
Ready to get started? See the quick-start guide →PROTOCOLS & TRANSPORT
The protocol defines how the two ends exchange proxy data; the transport determines how that data is carried. Both sets of settings must match the server.
VMess is a proxy protocol in the Project V ecosystem, with authentication and data encryption. Configurations typically use a UUID to identify the user. The alterId found in older documentation is a legacy compatibility detail; do not apply those old settings directly to a current server. A significant device clock offset can cause authentication failures, so check time synchronization and client logs when troubleshooting.
VLESS is a lightweight proxy protocol that does not provide VMess-style encryption. It is often paired with TLS or REALITY to secure transport. Nodes using VLESS can still differ in transport and flow settings. Successful import only means the client recognized the configuration; it does not guarantee that the current core supports every combination.
Trojan typically uses TLS to secure the connection and a password for user authentication. In addition to the address and port, the client must match settings such as the server name and transport. If the password is correct but the connection fails, check the certificate, device time and server configuration instead of repeatedly changing the password.
Transport is the configuration layer that carries proxy protocol data. Common options include TCP, WebSocket and gRPC. A protocol may support different transports, but available combinations depend on the core version. WebSocket path and Host fields mean different things from gRPC serviceName; changing the transport option alone while leaving other fields untouched can cause problems.
CORES & ECOSYSTEM
A client name is not a protocol name. Before choosing a core, check which features the connection configuration requires.
Project V is the open-source proxy ecosystem represented by V2Ray, with related projects building tools for protocol handling, transport and routing. GUI clients such as v2rayN organize connection settings into configurations the core can run. Knowing the ecosystem helps when researching, but compatibility depends on the specific project and version.
V2Fly continues the V2Ray project as a community ecosystem and maintains the core commonly known as v2fly. The Android client v2flyNG follows this core lineage; its feature set should not be assumed to match v2rayNG. If a configuration will not import or the client will not start, check protocol and transport support for the relevant version.
Xray originated in the V2Ray ecosystem and developed as an independent core fork, adding support for features such as VLESS and REALITY. v2rayNG uses the Xray core; the cores available in v2rayN depend on the current release. The two cores share some configuration, but newer fields, defaults and feature combinations are not always compatible.
The client provides a GUI for subscription management, node selection and system proxy controls; the core handles protocols, routing and connections. An option in the interface does not guarantee support in the selected core. When troubleshooting, record the client version, core type and core version separately. This is more useful than simply saying “V2Ray doesn’t work.”
CLIENT FEATURES
First check how traffic enters the client, then how it is routed. Traffic capture and outbound selection are separate steps.
System proxy settings tell apps that honor the OS configuration to send requests to a local proxy port. In v2rayN, “Set system proxy automatically” controls this layer, but not every program necessarily uses it. An app's own proxy settings, a separate network stack or another proxy tool may change the actual route, so check each case.
TUN mode captures traffic through a virtual network interface and often covers more apps than system proxy alone, but coverage still depends on routing, exclusions and implementation. It may require extra permissions and coordination with DNS and other virtual adapters. A desktop client's TUN toggle is not necessarily equivalent to Android's VPN-based traffic capture.
The listening port is where the client accepts proxy requests on the device; it differs from the remote node's port. For example, some v2rayN configurations use SOCKS on 10808 and HTTP on 10809, but check the current settings. When configuring an app manually, match the address, port and proxy protocol. Consider access controls before enabling LAN access.
Per-app proxy uses app identity to decide whether traffic enters the proxy path, and is commonly used in Android clients. First distinguish between “proxy selected apps only” and “bypass selected apps”; the two lists work in opposite ways. It can operate alongside domain-based routing, so the final path also depends on the client's routing rules.
ROUTING & DNS
Domain resolution, rule matching and outbound selection are interconnected. To check whether a configuration works, trace the actual connection path rather than relying on toggle states.
Traffic splitting selects an outbound route—such as proxy, direct or block—for each request based on its domain, IP or other conditions. Rules are usually evaluated in order; a broad rule placed too early can prevent later, more specific rules from taking effect. The domain strategy IPIfNonMatch determines whether IP matching is used after a domain rule fails to match. It is not a “proxy everything” switch.
GeoIP groups IP address ranges, while GeoSite groups domains; routing rules can reference either set. For example, geosite:category-ads-all references a domain set and only produces a specific outcome when paired with an appropriate blocking outbound. Available set names depend on the data file in use. After updating rules, check the data source and core compatibility.
FakeDNS returns synthetic addresses to apps while keeping an internal mapping between each address and its domain, so later connections can still be handled by domain. It is not a public DNS server address, nor can it be enabled simply by changing the resolver. Relevant traffic must return to a component that can restore the mapping; otherwise, DNS may resolve successfully while the connection fails.
A DNS leak occurs when queries take a different resolution path than intended—for example, using another resolver instead of the specified route. Encrypted DNS in the browser, system DNS, client DNS and the scope of TUN capture can all affect the result. Resolver names shown by leak-test sites are clues; check them against configuration and logs rather than drawing conclusions from a location label alone.
SUBSCRIPTIONS & ENDPOINTS
Subscriptions update multiple profiles at once; share links usually represent a single profile. Test results apply only to a specific target and connection attempt at a particular time.
A subscription lets a client fetch and update a set of connection profiles from a URL; it is not a single node. The response may contain Base64-encoded, line-separated share links or another configuration format, so the client must support that format. Subscription URLs may contain access credentials and should be treated as sensitive. If an update fails, check the response content and format before repeatedly importing it.
A node is a common name for a connection profile in a client, typically containing the server address, port, protocol, authentication and transport security settings. Its display name does not prove its actual location, performance or connectivity. The same server can have multiple profiles with different ports and transport settings.
A share link encodes a connection profile as copyable text. Common prefixes include vmess://, vless://, trojan:// and ss://. Missing trailing parameters, extra line breaks or unsupported extensions can affect import. Links may contain authentication details; check the fields after import and never show the full link in a public screenshot.
Real connection latency is usually measured by sending a request through the proxy to a test target. Depending on the implementation, the result may include DNS lookup, connection setup, security handshakes and the target's response time. It is not the same as ICMP ping or download speed. Timeouts may be caused by the node, test target or DNS path. For meaningful comparisons, use the same target and test conditions.
SECURITY & ENCRYPTION
A working connection and successful authentication are separate concerns. Identify the cause of certificate errors rather than simply weakening verification to dismiss them.
TLS provides transport encryption and authentication, and is commonly used to secure proxy connections. Standard certificate validation checks the trust chain, validity period and server name; an incorrect device clock can also cause failures. TLS protects the relevant connection segment, but does not guarantee the subscription source, remote service or behavior of every app is secure.
SNI is a TLS handshake extension that specifies the target server name. Clients may label this field serverName or server name. The connection address can be an IP, but enter the name specified by the server for certificate verification. SNI and WebSocket Host belong to different layers; changing one does not automatically update the other.
REALITY is a transport security method in the Xray ecosystem, often used with VLESS. It is not a node protocol alongside VLESS. The client must match server-provided settings such as the server name, public key and shortId; check the fingerprint and flow against the configuration too. Support depends on the core and client versions, so the link prefix alone cannot establish compatibility.
allowInsecure controls whether some core configurations skip TLS certificate verification. A GUI may label it “Allow insecure connections.” Enabling it can bypass some certificate errors, but weakens authentication and does not fix every handshake problem. Check the system time, server name, certificate chain and server configuration first; leaving it enabled is not recommended.