REALITY and XTLS Vision Explained: TLS Handshake Masquerading and Lower Encryption Overhead

VLESS, REALITY, and Vision: What Each One Does

Think of “VLESS + TCP + REALITY + Vision” as four layers. VLESS is the proxy protocol that carries details such as user identity and destination; it does not encrypt the transport. TCP carries the connection. REALITY provides a secure handshake and authentication. Vision is an XTLS flow-control mode that determines how proxy traffic is encapsulated and forwarded.

REALITY is not a complete node you can import on its own, and Vision is not a speed switch you can enable by changing the server address. The client and server must support the same combination. Xray and V2Ray are different cores; similar names do not mean their configuration fields are interchangeable.

This sequence shows the logical flow; it does not mean every stage adds another network round trip. Route selection means the client decides whether a request goes direct or through a proxy node. Only traffic routed through that node uses its REALITY and Vision settings. The speed of a directly accessed site says nothing about the node's protocol performance.

What Does REALITY “Borrow” During the Handshake?

In short, REALITY does not borrow a real site's private key or ask the destination site to decrypt traffic for the proxy server. “Borrowing” is a simplified way to describe the handshake's appearance and forwarding behavior. Keep two kinds of connection in mind: clients with valid authentication data, and ordinary or unauthenticated connections.

1. The client starts the handshake. It connects to the proxy server's address and port, then sends a TLS ClientHello based on its configuration. SNI is the server name declared in the handshake; the client fingerprint affects how the handshake message is constructed.
2. The REALITY server checks the authentication data. A valid client uses configured parameters, including a public key, for authentication and key negotiation. The server processes the handshake with the corresponding private key. Short ID is a separate matching parameter, not a password that replaces the user identity.
3. Authenticated connections proceed to proxy handling. After authentication succeeds, the two sides establish a protected connection and process the VLESS request. The final website visited in the browser can differ from the name declared in the handshake.
4. Unauthenticated connections can be forwarded to a target site. Depending on its configuration, the server forwards this traffic to a real TLS site, which responds as a normal site would. The exact behavior still depends on the implementation, target site, and network conditions.

The server generally does not need a public certificate or its private key for the borrowed name, but it does need a correctly configured REALITY key pair. The client receives the public key; the server's private key must not be included in a subscription. Changes to the real target site's handshake behavior can also affect connectivity, so this mechanism does not guarantee a permanently fixed appearance.

A port number only identifies a listening endpoint; it does not prove which protocol is in use. A node using port 443 is not necessarily using REALITY, and a real site supporting TLS 1.3 is not automatically a suitable target for every server deployment. If you use a subscription, keep the provider's settings rather than swapping target sites by trial and error.

How XTLS Vision Reduces Redundant Encryption

When a browser visits an HTTPS site, TLS already encrypts traffic between the browser and the site. If that already-encrypted data is wrapped in another layer of proxy TLS, it goes through additional encapsulation and processing. This “TLS over TLS” works, but adds some compute, copying, and record-processing overhead.

Vision identifies inner TLS traffic and, when conditions allow, switches to a more direct forwarding path to reduce redundant outer-layer processing of already-encrypted application data. It also pads early data to improve certain length characteristics. It does not disable browser HTTPS or send webpage content in plaintext.

It is inaccurate to summarize this as “all data gets encrypted one fewer time.” Whether traffic can use the optimized path depends on the inner protocol and implementation. Non-TLS data does not magically become protected by inner TLS. Further reducing copies through direct forwarding also depends on the platform, kernel, and connection conditions; setting Flow does not guarantee zero-copy operation.

Which Settings to Check in Your Client

On desktop, select the node in v2rayN, right-click it, choose “Edit,” and check the protocol, transport, security type, and Flow. Field groupings can vary between versions, so look for the field names rather than relying on the node label. On Android, tap the edit icon on the v2rayNG node card and check the corresponding fields. For subscription nodes, refresh the subscription to retrieve the provider's settings. Before making manual changes, save a copy for comparison.

• Address and port: These determine which server to connect to. If you use a domain name, it must also be resolved through DNS; SNI does not replace the server address.
• Server name: Often shown as SNI or Server Name, this must match a value allowed by the server. A domain opening in your browser does not mean it is suitable for this node.
• Public key and Short ID: Keep the subscription values exactly as provided, and make sure no characters are lost when copying. Short ID and UUID are separate fields; swapping them will prevent authentication from working.
• Fingerprint: For example, chrome is a handshake fingerprint option; it does not mean you need to use that browser. It affects the handshake sent by the proxy client, not a browser extension setting.
• Flow: Set xtls-rprx-vision only when the server uses the corresponding flow-control mode. Do not add it to a VMess node or confuse a WS path with Flow.

Check the core as well. v2rayNG uses the Xray core and can run compatible configurations. v2flyNG uses the v2fly core and is not an equivalent runtime for REALITY and Vision nodes. If v2rayN is configured to use different cores, make sure the current node is actually running on an Xray core that supports these parameters—not merely that the client has started.

Why REALITY and Vision May Not Make Your Connection Faster

They cannot increase your provider's bandwidth or fix congestion between networks. Long-distance latency, packet loss during peak hours, server load, node speed limits, and device performance can all matter more than encryption overhead. If the bottleneck is the server's outbound bandwidth, reducing encryption processing will not let a download exceed that limit.

1. Keep test conditions consistent. Use the same device, network connection, and download resource, and pause other downloads. Nodes in different regions or on different carriers are not a valid direct comparison for proving that one flow-control mode is faster.
2. Make sure traffic is using the proxy. In v2rayN's main window, open “System Proxy” and select “Set system proxy automatically,” then check the routing mode. The system proxy only affects apps that honor that setting; it does not automatically route every program.
3. Separate latency from throughput. Check whether the connection stays up, whether sustained download speed fluctuates, and whether the logs show repeated reconnects. Low latency means the wait may be shorter; it does not necessarily mean higher download bandwidth.
4. Change one setting at a time. For a valid comparison, use two configurations explicitly supported by the server. Do not remove Flow in the client alone and then mistake an authentication failure for worse performance.

Handshake Errors and Common Misconceptions

A log error is a troubleshooting clue, not proof of a single cause. EOF, timeouts, and connection resets need to be interpreted in context: first check whether the server was reached, then whether the handshake succeeded, and finally whether the proxy request completed. Before sharing logs, redact subscription URLs, user identities, and other authentication details.