Why REALITY and XTLS Vision Are Fast: A Guide to Handshake Overhead and Forwarding Paths

When discussing REALITY and XTLS Vision performance, it is easy to mix up two different layers. REALITY handles connection setup, server authentication, and the shape of the outer handshake. Vision is a VLESS flow-control mode focused on data forwarding after the connection is established. The former affects whether the handshake completes smoothly and how many intermediate layers traffic passes through; the latter affects copying, encapsulation, and encryption paths during sustained transfer.

Three names to separate first: VLESS, REALITY, and Vision

VLESS carries user authentication data and proxy requests. It is not itself a transport layer, nor does it automatically provide a complete secure outer connection. A working node usually specifies a transport such as TCP, then selects a security layer such as TLS or REALITY. Even if subscription entries all begin with VLESS, their internal combinations can be completely different.

REALITY is a transport-security scheme in the Xray ecosystem. The client sends parameters including server public-key information, a short ID, the server name, and a client fingerprint; the server uses them to validate the connection. REALITY structures the outer traffic around handshake characteristics observable from a genuine target site, but the client still connects to the configured proxy server—it does not send all application requests to the target site first and then relay them back.

XTLS Vision corresponds to the commonly used xtls-rprx-vision flow-control value. It identifies TLS traffic patterns in the connection and, when conditions allow, changes how subsequent data is handled to reduce unnecessary re-encapsulation and memory copying. It cannot shorten the physical route or fix congestion, packet loss, or insufficient server bandwidth.

Why REALITY’s handshake is usually more direct

A new TCP connection normally starts with the TCP handshake, followed by a security-layer handshake. With a 50 ms round-trip time between client and server, one extra round trip can noticeably delay the first request. REALITY does not reduce network round trips to zero; its advantage is that Xray handles the security handshake and proxy authentication directly, without relying on traditional certificate deployment or an additional web-service entry point.

A traditional WebSocket, reverse proxy, and TLS stack may involve more software layers: an entry service terminates TLS, parses the HTTP upgrade request, and passes the data to the backend proxy. Each layer usually adds only a small amount of time, but scheduling, buffer copies, and interprocess handoffs accumulate on low-spec servers, under high concurrency, or when short-lived connections are created frequently. With REALITY over TCP, the data path is usually shorter and the configuration chain simpler.

This does not mean REALITY’s TLS handshake inherently removes one complete round trip. The client still establishes TCP and exchanges the required handshake data. The noticeable difference usually comes from removing an extra HTTP upgrade, reducing reverse-proxy forwarding, and avoiding delays caused by multi-layer entry-point configurations.

The figures above compare the same server, upstream connection, and test window: the client used v2rayN 7.10.5 with Xray-core 25.3.6, established 30 cold connections in succession, and reported the median. They show the scale of processing-path differences and should not be applied directly to other routes. If two nodes are in different data centers, an 80 ms geographic-routing gap can easily outweigh a protocol-layer difference of a dozen milliseconds.

How XTLS Vision shortens the sustained data path

When a browser visits an HTTPS site, the application data is already inside a TLS connection. If the proxy’s outer layer then fully encapsulates and processes everything again in the traditional way, the result is the familiar TLS-over-TLS setup. The cost is not just an encryption instruction; it also includes reading buffers, identifying records, copying data, rebuilding data blocks, and writing to sockets.

Vision observes the shape of traffic at the start of the connection and uses techniques such as padding to handle stages that might expose fixed patterns. Once it determines that later traffic meets the optimization conditions, it can switch to a more direct forwarding path. The HTTPS connection between the target site and browser still provides the inner-layer security; Vision optimizes how the proxy carries that already encrypted data, not whether the target site’s encryption exists.

The benefit is easier to see with large downloads, video buffering, and long-lived HTTPS connections, because substantial data continues to flow after a single handshake. When opening only a few small pages, DNS lookups, TCP slow start, and the number of page resources account for a larger share of the time, so Vision’s processing savings may not translate into a noticeable improvement.

• Already encrypted, long-lived HTTPS connections are Vision’s primary optimization scenario.
• Ordinary plaintext traffic is still protected by the outer security mechanism; this does not mean all data bypasses processing.
• UDP, DNS, and other atypical traffic do not automatically receive the same scale of throughput improvement.
• The client and server must both support the same Flow; enabling it on only one side can cause connection failures or parameter mismatches.

How to run a meaningful speed comparison

The most common mistake in protocol comparisons is testing nodes from different regions, providers, or load conditions side by side. That mainly measures route differences. The proper approach is to place both inbound configurations on the same server whenever possible, keep upstream bandwidth, routing, and test time consistent, and change only the security layer or transport combination.

1. Record the baseline RTT: Test the server’s reachable address 20 times, recording the median, maximum, and packet-loss rate. The example baseline is a 52 ms median, a 61 ms maximum, and 0% packet loss.
2. Fix the client versions: Use the same v2rayN and Xray-core throughout the test. Do not switch core versions, routing modes, or DNS settings between the two groups.
3. Eliminate connection-reuse interference: Fully exit the test program before measuring each group so you test cold connections rather than reuse established sessions.
4. Measure initial connection and throughput separately: Run at least 20 to 30 initial-connection tests; for throughput, use the same HTTPS file and sustain each run for more than 60 seconds.
5. Alternate the test order: Rotate the order as A, B, B, A to prevent traffic rising during peak hours from unfairly penalizing the group tested later.

In v2rayN, open “Settings” → “Parameter Settings” to check the local listening ports and core options. The common local SOCKS port is 10808, and the HTTP port may be 10809, but use the values shown in the current client interface. The speed-test tool must explicitly use the same proxy entry point; do not send one group through the system proxy while bypassing the proxy for the other.

Node parameters can be checked by opening the edit window from the server list. For a REALITY connection, pay attention to the address, port, user ID, transport, server name, public key, short ID, fingerprint, and Flow. When a subscription imports correctly, these fields are usually populated automatically; if you change any one of them manually, every value must match the server configuration.

When it will not be faster

The first case is when the route itself is the bottleneck. If cross-network packet loss reaches 5% during peak hours, TCP repeatedly retransmits and reduces its congestion window. Saving a little CPU time and memory copying cannot offset the pauses caused by retransmissions. Switching protocols may change the short-term graph, but sustained throughput usually will not rise consistently.

The second case is a restricted server uplink. For example, if the port is capped at 100 Mbps and a standard TLS setup already sustains 94 Mbps, Vision cannot exceed a physical or provider-imposed limit. It is more likely to reduce server load and leave capacity for concurrent connections than to push a single connection beyond the bandwidth cap.

The third case is application traffic that does not match the optimization conditions. Many short requests, frequent disconnects and reconnects, UDP-heavy communication, or requests passing through another application-layer relay can all prevent Vision’s sustained-forwarding advantage from emerging. Optimize DNS, routing rules, and node distance first.

A practical order for configuration checks and troubleshooting

When a REALITY node fails to connect, do not blame Vision first. Sustained-forwarding optimization has not started because the connection is not established. Confirm that the system clock is accurate, the subscription is up to date, and the server address and port are reachable before checking security-layer parameters. A large clock offset can affect handshake validation, while a port blocked by a local firewall or network policy will cause a direct timeout.

When the connection succeeds but is slow, use this order: route, server load, local settings, then protocol path. Check packet loss and peak-hour changes first, then inspect server CPU and uplink usage, followed by v2rayN’s system proxy, routing rules, and DNS. Only when these conditions are closely matched is it useful to compare REALITY, TLS, TCP, or other transport combinations.

• Cannot connect: Update the subscription, correct the system time, and verify the port, public key, short ID, server name, fingerprint, and Flow.
• Connects but the first load is slow: Measure baseline RTT and check whether DNS, the system proxy, or routing rules are sending requests on a longer route.
• Initial load is normal but downloads are slow: Check packet loss, server CPU, uplink bandwidth, and throttling at the test source.
• One node varies between fast and slow: Record at least three data sets at different times and first assess congestion on the shared route.
• Only some sites are slow: Check domain split routing, DNS results, and the target site’s own connection quality.

The value of combining REALITY with XTLS Vision can be summarized in two points: a more direct connection entry point and a shorter sustained-forwarding path for qualifying TLS traffic. They address protocol processing and deployment-chain issues; they do not replace a good route or change the network distance. Once this boundary is clear, speed-test results are easier to interpret, and configuration choices do not have to rely on the node name alone.