Why REALITY and XTLS Vision Are Fast: Handshake Reuse and Flow Control Explained

Why TLS Handshakes Affect Time to First Byte

Connection speed involves at least three separate metrics: how long setup takes, what sustained throughput a transfer can reach, and how much CPU processing each packet requires. REALITY mainly changes the handshake and traffic appearance, while XTLS Vision mainly optimizes the data path after transmission becomes stable. Treating both as simple bandwidth boosters is misleading.

With TLS 1.3 over TCP, the client first completes the TCP three-way handshake and then sends ClientHello. The server returns ServerHello, certificate-related messages, and a handshake completion message. A full TLS 1.3 handshake typically requires one network round trip before protected application data can be sent. When latency between client and server is high, this exchange directly adds to the wait for the first web request or application connection.

A full TLS 1.2 handshake usually requires more message exchanges, so TLS 1.3 already reduces startup overhead. However, a proxy chain may carry the browser’s own HTTPS inside an outer TLS connection. The outer layer protects the proxy tunnel, while the inner layer protects the site being accessed; if the proxy repeatedly encrypts, copies, and wraps already encrypted TLS records, CPU and memory work may be duplicated.

What REALITY Actually Does

REALITY is a security layer in Xray for establishing authenticated, TLS-like connections, commonly combined with VLESS over TCP. The client includes authentication data derived from REALITY parameters in ClientHello. The server validates the connection using the private/public key relationship, shortId, time window, and other conditions. Once authenticated, the connection proceeds to VLESS and flow-control processing.

“Borrowing a real website’s certificate” is better understood as reusing the target site’s TLS appearance and handshake context, not copying its private key. A REALITY server does not need the target site’s certificate private key. The configured serverName must match a name allowed by the server, and the client must use the correct publicKey, shortId, and fingerprint; a mismatch in any one of these fields can cause the handshake to fail.

The server usually also specifies a reachable destination. Unauthenticated probe connections can be redirected to that destination according to the configuration, making the observed response resemble a conventional TLS service. This addresses handshake appearance and authentication; it does not automatically fix server congestion, packet loss across networks, or inefficient carrier routing.

How XTLS Vision Reduces Duplicate Processing

VLESS itself does not add a general-purpose encryption layer to application data; security is provided by an external layer such as REALITY or TLS. XTLS Vision is an Xray flow-control mode, commonly configured as xtls-rprx-vision. It observes TLS characteristics on the connection and, after the necessary handshake and authentication, uses a more direct forwarding path for qualifying data.

When a browser accesses an HTTPS site, an end-to-end TLS layer already exists between the browser and the destination. If a traditional proxy security tunnel then continuously encrypts the entire inner TLS stream as ordinary payload, the result is encrypted TLS data inside another secure channel. Vision does not remove the destination site’s HTTPS; it detects this already encrypted traffic and reduces redundant outer encryption, buffering, and memory copying.

This optimization is generally easier to observe during large-file transfers, concurrent HTTPS connections, or periods of high server CPU usage. The total time for a short connection may still be dominated by DNS, TCP setup, and network round trips, while a slow link may be limited by bandwidth first. Vision also does not change the destination site’s certificate verification; the security boundary between the browser and the site remains intact.

• Short web requests: More affected by round-trip time, DNS, and the initial handshake; throughput differences may be minimal.
• Sustained downloads: Make differences in memory copying, encryption overhead, and server CPU easier to observe.
• High-concurrency connections: Monitor Xray logs, process CPU, and system connection counts together; a single connection is not enough evidence.
• High-loss networks: TCP retransmission and congestion control usually dominate, and Vision cannot bypass lower-level retransmissions.

Why REALITY and Vision Often Appear Together

REALITY and Vision handle different stages of the same connection. REALITY establishes an authenticated channel with a specific TLS appearance; Vision optimizes qualifying traffic after the channel is established. The common combination is therefore VLESS for user and request handling, REALITY for the secure handshake, Vision for flow control, and TCP for reliable transport.

This combination requires the client and server parameters to match exactly. The client has only the publicKey, not the server’s privateKey; shortId must come from the server’s allowlist; serverName must match the server configuration; and Flow must be set to xtls-rprx-vision. Simply copying a regular TLS node’s domain and port into REALITY fields will not produce a usable connection.

When importing through a subscription in v2rayN, these values are usually written into the server profile automatically. To verify them manually, open “Servers” → “Edit server” and check the address, port, user ID, Flow, transport protocol, security type, SNI, fingerprint, public key, and shortId. Then open “Settings” → “Parameter settings” and confirm that the current Core type is an Xray core supporting this combination.

Protocol: VLESS
Transport: TCP
Security: REALITY
Flow：xtls-rprx-vision
SNI: Match the server’s serverNames
Fingerprint：chrome
Public key: Generated from the server public key
Short ID: Must exactly match an allowed server value

1. Update the subscription first and reselect the corresponding server to avoid continuing to use an old publicKey or shortId.
2. Open v2rayN’s server editor and verify VLESS, TCP, REALITY, and Vision field by field; do not check only the address and port.
3. Save the changes and start the connection. In “Help” → “View logs,” watch for Xray startup, handshake, and outbound errors.
4. Enable the system proxy, visit a regular HTTPS page, and then test a sustained download to assess the handshake and transmission stages separately.
5. If a local application uses a manual proxy, make sure it points to v2rayN’s current listening port. The common local mixed-proxy port is 10808, but use the actual value shown under “Settings” → “Parameter settings.”

Which Scenarios Fit—and Which Bottlenecks Remain

The VLESS, REALITY, and Vision combination suits setups where both client and server can reliably run an Xray core, especially HTTPS-heavy workloads, sustained transfers, and desktop or Android connections where reducing duplicate processing matters. v2rayN supports Windows, macOS, and Linux desktop environments; on Android, use v2rayNG when this combination is needed and make sure it uses an Xray core supporting the required parameters.

v2flyNG uses the v2fly core, so its configuration capabilities must be judged against that core’s actual support. When a subscription includes REALITY or Vision, successful import alone does not prove that a connection can be established; a client interface displaying a field does not mean the active core implements the corresponding handshake and flow control.

The quality of the underlying route still sets the performance ceiling. If the server has fixed egress bandwidth, Vision cannot exceed that limit; sustained cross-region packet loss causes TCP to slow down and retransmit; and a large server clock offset can make REALITY authentication fail. Choose protocols based on logs, network paths, and resource usage together.

How to Identify the Source of a Performance Improvement

To determine whether a protocol suits the current network, start with repeatable comparison conditions. Keep the same server address, egress port, and test file, changing only the security layer or Flow. Run each setup at least three times and establish a new connection before every test; otherwise DNS caching, server load, and network fluctuations can hide the real differences.

If the first byte is slow but sustained downloads are normal, check network round trips, DNS, and the handshake first. If the first byte is normal but CPU usage is high during long connections, duplicate encryption or copying is a more likely cause. If throughput drops periodically with TCP retransmissions, address packet loss first. Handshake failures in the logs indicate configuration problems and should not be analyzed as performance issues.

• Record the time from clicking connect in v2rayN or v2rayNG until the core reports that the connection is ready.
• Use the same HTTPS resource for at least 60 seconds and observe the stable phase rather than momentary peaks.
• Record Xray process CPU usage in the desktop system’s task manager or system monitoring tool.
• Test direct and proxy routing rules separately to confirm that routing does not send the target to the wrong egress.
• Check the core logs for handshake timeouts, connection resets, port conflicts, or DNS resolution errors.

REALITY and XTLS Vision do not derive their benefits from a single “speed boost” switch. REALITY establishes a verifiable connection with the target TLS appearance, while Vision detects already encrypted application traffic inside the secure channel and reduces duplicate processing. The combination shows up as shorter startup waits, lower resource use, or steadier sustained transfers only when parameters match, the core is compatible, routing is correct, and the network bottleneck allows it.