REALITY Protocol and XTLS Vision Explained: Handshake Mechanics and Performance

First, separate REALITY, VLESS, and XTLS Vision

A common subscription profile is “VLESS + TCP + REALITY + XTLS Vision.” These are not protocol names at the same layer. VLESS handles user identification and proxy request formatting between the client and server; TCP carries the data; REALITY handles the outer handshake, server identity verification, and traffic appearance; XTLS Vision is a flow-control mode that recognizes application data already encrypted by TLS and adjusts the forwarding path.

REALITY is therefore better understood as a transport security scheme in the Xray core, not as a standalone proxy protocol replacing VLESS. It does not require the server to obtain a public certificate for its own domain or point a dedicated domain at the server. The client identifies the target server with parameters such as publicKey, shortId, and serverName, while the server uses a configured real website as the handshake profile and fallback target.

XTLS Vision is not a new encryption algorithm. Web traffic is usually already encrypted by HTTPS. If conventional outer TLS also processes that ciphertext in full, the proxy core ends up with a “TLS inside TLS” data path. Vision optimizes forwarding after confirming the connection characteristics, reducing duplicate processing and memory copies while retaining the padding and handshake protection needed at the start of the connection.

How REALITY borrows real-site handshake traits

A conventional TLS server sends a public certificate matching its own domain. REALITY takes a different approach: the client first builds a ClientHello resembling that of a common browser and places the configured serverName in SNI. The server uses the private-key/public-key relationship and shortId to determine whether the connection comes from a valid client, then completes the corresponding identity check.

If the connection lacks valid authentication data, the server can route the handshake to a preconfigured target website. To an outside observer, the SNI, TLS version, cipher suites, and target-site response then share a consistent context, without exposing a self-signed certificate deployed specifically for proxy service. “Borrowing” here means reusing the target site’s public handshake traits and fallback behavior—not copying its private key or forging its official certificate.

1. Build the greeting: The client constructs a TLS ClientHello from the fingerprint parameter; chrome is a common value.
2. Send the target name: serverName goes into SNI, must belong to the server’s allowed-name set, and must match the server configuration.
3. Complete authentication: The client’s publicKey must correspond to the server’s privateKey, and shortId must match an allowed server value.
4. Classify the connection: After authentication succeeds, the session enters VLESS; unauthenticated ordinary TLS traffic is routed to the target site according to the server configuration.
5. Start proxying: VLESS parses the destination address, after which Vision determines whether subsequent data uses standard handling or optimized forwarding.

How XTLS Vision reduces duplicate encryption overhead

When opening an HTTPS website, the browser first establishes a TLS layer with the target site. If standard TLS is also used outside the proxy tunnel, the proxy core must continually process application data that is already encrypted. The two encryption layers protect different links logically, but repeatedly sending large, incompressible TLS ciphertext through generic encryption, decryption, and buffering adds CPU usage, memory copies, and scheduling overhead.

Vision examines the connection’s initial data to identify the inner TLS handshake and record boundaries. Once the conditions are met, it can move subsequent encrypted data onto a more direct forwarding path. The goal is not to remove a security layer, but to avoid unnecessary rewrapping of large data flows that already show end-to-end encryption characteristics. Plaintext connections and unrecognized data are still handled according to the applicable rules.

The opening phase of the connection still matters. Vision applies the necessary padding and shaping to the initial data, reducing conspicuous fixed packet lengths and first-packet patterns. After the protocol state, direction, and data type are confirmed, it switches to more efficient copying. This is why the throughput benefit is more apparent for long-lived connections, large downloads, and high-definition video; short connections carrying little data usually show a smaller difference.

• Heavy HTTPS traffic: The inner data is already encrypted, so Vision can more readily enter its optimized path.
• Short web requests: DNS, TCP setup, and server response time account for more of the total, so the speed difference may be only a few milliseconds.
• High-bandwidth servers: Throughput gains are more visible when CPU or memory copying is the bottleneck.
• High-loss links: Retransmission and congestion control are still governed by TCP; Vision cannot fix packet loss on the underlying link.

How to read latency, throughput, and CPU usage

Here is a same-host comparison designed to illustrate the difference: a 2-core virtual machine as the server, a gigabit wired client connection, roughly 42 ms round-trip latency, and a 1 GB test file. Each test ran three times, with the median reported. Standard VLESS + TCP + TLS and VLESS + REALITY + Vision used the same server and egress. These figures show a typical trend, not a fixed result for every route.

Bottom line: throughput matters for large transfers; the route matters for short requests

If the main issue is a slow initial page load, check DNS, node distance, and packet loss first. If server CPU stays above 80% during downloads, switching to REALITY + Vision on the same route is more likely to produce a visible improvement.

Do not change the node, target website, and protocol at the same time. Otherwise, you cannot tell which change caused the improvement. A reliable method is to stop other downloads, use the same test file, run each setup three times, and compare the medians and CPU peaks. Instantaneous browser speed readings fluctuate widely; transfers lasting at least 30 seconds provide a better reference.

Which parameters should you check after client import?

The v2rayN desktop client and v2rayNG Android client usually import REALITY nodes with a subscription. Successful import does not guarantee a complete profile: flow, serverName, fingerprint, publicKey, and shortId may be lost during subscription conversion or manual editing. v2flyNG uses the V2Fly core and is not suitable for nodes that depend on Xray REALITY and Vision; choose a client whose core matches the subscription requirements.

For compatibility checks, Xray-core v1.8.0 can serve as a conservative REALITY baseline. In practice, prefer the updated core bundled with the client’s current stable release. If an older core does not recognize realitySettings or xtls-rprx-vision, common symptoms include failure to start, configuration validation errors, or a log message reporting an unknown field.

1. Update the subscription first, then open the node editor and confirm that the protocol is VLESS and the transport is TCP.
2. Check the address and port. 443 is common, but the subscription’s actual value is authoritative.
3. Check that the security type is REALITY and that serverName is a complete domain name.
4. Confirm that chrome is the common fingerprint value and that publicKey and shortId have not been truncated.
5. Check whether flow is xtls-rprx-vision; do not add it yourself if the server does not enable it.
6. Save the changes, restart the core, and check the logs for handshake, authentication, or unknown-field errors.

Common questions and handshake troubleshooting

REALITY connection problems usually occur in three places: incomplete client import, mismatched client and server core capabilities, or a network path that cannot reach the server’s listening port. First confirm that the core starts, then confirm TCP connectivity, and only then analyze the REALITY handshake. This order prevents an unreachable port from being mistaken for a public-key error.

Troubleshooting order: start, port, handshake, proxy

Check that the core is running normally, then test whether the server port is reachable, verify the REALITY identity parameters, and finally check the system proxy and routing. Change one item at a time and retest to pinpoint the actual fault.

REALITY + Vision is a good choice when using the Xray core, reducing certificate deployment steps, and optimizing HTTPS-heavy forwarding are priorities. It does not automatically solve node distance, egress congestion, or TCP packet loss. Only when the client version is suitable, subscription parameters are complete, and the server route is stable do handshake camouflage and data-path optimization translate into observable connection quality.