REALITY and XTLS Vision Explained: TLS Handshake Mimicry and Reduced Encryption Overhead

At a glance

REALITY handles authentication and handshake behavior for the outer connection, while XTLS Vision optimizes forwarding for eligible traffic. They are not the same protocol setting. This guide is for readers with a VLESS configuration who want to understand SNI, public keys, shortId, and flow. It walks through the handshake, encryption layers, and client-side troubleshooting so you can tell what each setting does and where to start when a handshake fails or a connection works but websites won’t load.

1. What VLESS, REALITY, and Vision Each Do

“VLESS + REALITY + Vision” is a common layered setup. VLESS carries proxy request details such as the user ID and destination address, but does not encrypt application data itself. REALITY provides secure transport and authentication in this setup, while Vision uses a more suitable forwarding method for eligible traffic. Calling all three “encryption protocols” can make their settings confusing.

Connection and authentication layer

Proxy protocol: VLESS
User identity: UUID
Secure transport: REALITY
Server authentication: Public key and handshake verification

The UUID and REALITY public key serve different purposes and are not interchangeable.

Transport stack discussed in this guide

Transport: TCP / RAW; names vary by version
Flow value: xtls-rprx-vision
Example handshake fingerprint: chrome
Common remote port: 443; check your actual configuration

Don’t add a WebSocket path or another transport wrapper to this setup.

v2rayN is a desktop GUI client, and feature support depends on the selected core. v2rayNG uses the Xray core. v2flyNG uses the v2fly core, so don’t assume it supports the same REALITY and Vision settings just because its name is similar. A successful import only means the client accepted the configuration; it doesn’t guarantee that the active core supports those features.

2. REALITY’s “Handshake Mimicry” Doesn’t Give You the Target Site’s Private Key

In a standard TLS connection, a browser verifies a website’s identity using its certificate chain and domain name. REALITY is designed to handle two kinds of connections: clients with valid authentication material, and ordinary visitors or probes without it. By mimicking the target site’s handshake behavior and forwarding unauthenticated connections to a fallback, it can make those connections look like visits to the target site rather than exposing an obvious proxy error.

Client handshake Server authentication Ephemeral certificate verification VLESS request Forward traffic to destination

The flow above describes an authenticated proxy connection. The client uses the preconfigured server public key and handshake context to verify REALITY’s ephemeral certificate mechanism; it does not simply trust any certificate. The server does not obtain the target site’s private key or issue a publicly trusted replacement certificate for that site. “Borrowing certificate characteristics” is a useful shorthand, but it does not mean a copied certificate can be used to impersonate any website.

For connections that fail REALITY authentication, the server can forward them to the configured target site, so visitors see the target’s genuine TLS behavior. The target is not a throwaway setting: reachability from the server, TLS 1.3 support, and connection behavior all affect the quality of the configuration. Depending on the Xray version, the server-side target field may be named target or the older dest; check the version you’re running.

3. Which Layer of Redundant Encryption Does Vision Reduce?

When a browser connects to an HTTPS site, TLS is already in place between the browser and the destination. If the entire connection is then wrapped in the proxy’s outer TLS, the same application ciphertext may go through another layer of record encapsulation and encryption. The proxy server also has to handle outer-layer decryption and forwarding, adding compute and data-transfer overhead. The actual impact depends on the implementation, hardware, and traffic type.

Stage or traffic type	How Vision handles it	What you can’t conclude from this
Connection setup and proxy request	Completes the outer secure handshake, authentication, and required protocol processing.	The secure tunnel is not bypassed from the very first byte.
Eligible inner TLS 1.3 traffic	Once the secure switch conditions are met, traffic can use a direct-copy path to reduce the overhead of continued outer TLS encapsulation.	Not every HTTPS connection will use this path.
Plaintext traffic or traffic that does not meet the switch conditions	Continues through the applicable protected forwarding path.	You can’t claim that all data skips a layer of encryption.
Underlying system-level forwarding	When supported by the core, operating system, and connection conditions, more efficient data-transfer methods may also be available.	Enabling Vision does not guarantee zero-copy transfers.

“Direct copy” does not mean web traffic is exposed as plaintext on the network. Data on this path is still protected by TLS between the browser and the destination site. Vision detects the inner protocol state and switches paths; it does not simply turn off encryption. This explanation doesn’t apply when the required conditions aren’t met.

How to test: verify flow settings before comparing throughput

First, confirm that both client and server use xtls-rprx-vision. Then compare CPU usage and throughput on the same route, with the same large HTTPS download, at similar times. A single page-load test can’t show whether the direct-copy path is active, and it can’t support a fixed speed-up percentage.

4. Settings to Check After Importing

A subscription usually fills in most parameters, but missing fields after an update, manual edits, and core version differences can still cause problems. Keep a record of the original import, then edit a copy one setting at a time so you can correlate log changes with configuration changes.

TLS 1.3

Key versions for the handshake and inner-layer switching discussed here

443

Common remote HTTPS port; not required

Maximum number of hexadecimal characters in shortId; length must be even

Server address and port: Must point to the proxy server’s actual listening address. Remote 443 and the client’s local SOCKS listening port are different settings and must not be swapped.
UUID and flow: The UUID identifies a VLESS user on the server. The client’s flow must match that user’s server-side setting. Setting xtls-rprx-vision does not enable Vision on a server that hasn’t configured it.
Public key: Use the public key corresponding to the server’s REALITY private key, not text from a website certificate. Share links commonly carry this value in pbk. Field names in the GUI and core JSON may vary by version, so check the documentation for your version; don’t copy a link parameter name directly into a JSON field.
SNI and fingerprint: serverName must be within the range of names allowed by the server. The chrome example for fingerprint describes the ClientHello fingerprint; it does not change your local browser or hide every network characteristic.
shortId: The client value must match an entry in the server’s allowlist. It uses hexadecimal characters, must be even in length, and can contain up to 16 characters. Leave it blank only if the server allows an empty value.

In v2rayNG, long-press the configuration and choose “Edit” to check the server address, port, transport security, SNI, public key, and other settings. Labels may vary slightly by version. In v2rayN, double-click the configuration to edit it and verify which core is selected. Don’t enable options such as “Allow insecure certificates” as a troubleshooting shortcut; they do not replace REALITY public-key authentication.

5. Troubleshoot in Order: Handshake, Proxy Request, Application Traffic

“The node won’t connect” can describe several different problems. If the TCP port is unreachable, changing SNI won’t help. If REALITY authentication fails, changing routing rules won’t fix it either. Gather information in the order the connection is established instead of changing settings at random.

First, confirm the connection destination: Check the server address, actual port, server listener, and firewall rules. A timeout and a refused connection are different outcomes; a timeout may also point to packet loss or filtering along the route.
Next, check handshake authentication: Compare the public key, SNI, shortId, and fingerprint settings. If the server enforces a handshake time-difference limit, make sure both systems’ clocks are synchronized so clock skew isn’t mistaken for a key error.
Then check the VLESS user: If the connection still fails after the handshake, verify the UUID, flow, and server-side user settings. Establishing the outer connection does not mean the proxy request was accepted.
Finally, check the application path: Confirm that application traffic reaches the client, then check DNS, routing rules, and server egress. A successful connection entry in the log does not prove that the browser is using the proxy.

Why does the handshake still fail when both the public key and UUID are set?

Start with a fresh copy imported from the original subscription, then compare SNI, shortId, and whether transport security is set to REALITY. Check that the server public key was updated if the private key changed, and compare client and server logs from the same time. Don’t rely on latency tests alone.

The connection works, but websites won’t load. Should I change the fingerprint?

First, check that the browser uses the system proxy or the specified local proxy, and look for its requests in the client log. If requests are reaching the proxy, check DNS resolution and the routing exit. If there’s no handshake error, repeatedly changing the fingerprint should not be your first step.

I enabled Vision, but speeds haven’t changed. Is it not working?

Not necessarily. First compare the flow settings on both ends, then use the same download source and test window to monitor CPU usage and throughput. Available bandwidth, packet loss, or rate limits on the destination server can all be bottlenecks. Small webpages are also unlikely to show the benefits of reduced forwarding overhead.

Why won’t the same subscription work in v2flyNG?

First check whether the configuration relies on Xray’s REALITY and Vision features. Use a v2rayNG version that supports those features, or v2rayN with a compatible core. Changing the client name or transport label won’t resolve differences in core capabilities.

6. Know the Limitations Before Changing Your Configuration

REALITY does not hide the proxy server’s IP or guarantee that traffic can’t be identified. The target site, server deployment, network path, and client version all affect how it performs. Vision mainly improves processing efficiency for eligible traffic; it does not change the physical link’s bandwidth or latency. Packet loss, congestion, and server load still need to be investigated separately.

If your configuration is stable, keep it as a baseline. Don’t change the server, transport, and DNS all at once.
If you maintain settings manually, record the core version and field changes. After an upgrade, test one configuration before updating the rest.
When sharing troubleshooting details, hide your UUID, subscription URL, and server private key. Include the error type, timestamp, and relevant field names.
For field definitions, see the site’s JSON Reference. For your first import and proxy setup, follow the Getting Started guide.

What matters is not whether all three names appear in the interface, but whether the full chain works: the client connects to the right server, REALITY authentication succeeds, the VLESS user and flow settings match, and application requests follow the intended route. Treating each layer separately makes configuration and troubleshooting easier to reproduce.