How REALITY and XTLS Vision work: why the next-generation VLESS transport can be faster

What layer do VLESS, REALITY, and Vision operate on?

“VLESS + TCP + REALITY + Vision” in a node name doesn’t mean four interchangeable protocols. It describes different settings for the same proxy connection. VLESS carries user identity and destination details; TCP transports the byte stream; REALITY provides a secure handshake and authentication; and Vision is a VLESS flow-control mode that can optimize the data path when conditions allow.

VLESS does not provide payload encryption in the traditional sense. In common configurations, encryption=none does not mean the entire connection is sent in plaintext. With REALITY, protection comes from the outer security mechanism. Don’t change VLESS’s encryption field to an option from another protocol just to “make it more secure.”

This article covers the Xray combination of VLESS + REALITY + Vision. v2rayN manages nodes and runs the core; it isn’t the combination itself. To determine whether a connection will work, check the core that actually starts and the configuration it generates—not just the client’s name.

Where does redundant encryption happen when HTTPS goes through a proxy?

When you visit an HTTPS site, your browser establishes a TLS session with the destination. A proxy usually just relays this already-encrypted data; it doesn’t decrypt the page. If the proxy link also uses TLS, the client may need to wrap and encrypt the inner TLS data again before sending it to the proxy server, which then removes the outer layer.

There are two distinct security layers: the inner one protects content between the browser and the website, while the outer one protects traffic between the client and proxy server. Both serve a purpose, but fully encrypting large amounts of already-encrypted data again adds CPU, buffering, and data-copying overhead. This overhead is more likely to become a bottleneck under high throughput or on less powerful processors.

This model doesn’t apply to every request. Ordinary HTTP has no website TLS layer, and UDP traffic isn’t an HTTPS byte stream that follows the same processing path. So “less double encryption” doesn’t mean every app will get a fixed speed boost.

How XTLS Vision changes the data forwarding path

Vision doesn’t disable protection when a connection starts. It first handles the protocol header and initial data, then checks the inner TLS state. For eligible TLS 1.3 traffic, it switches to an optimized data path at the appropriate stage, avoiding unnecessary outer encryption of application data that’s already encrypted.

1. Establish the connection. The client and server complete the outer secure handshake and exchange the VLESS identity and destination details.
2. Identify the traffic. Vision checks the inner TLS handshake and record characteristics. During the initial stage, it also uses padding to adjust early packet characteristics.
3. Switch only when conditions are met. Eligible TLS 1.3 traffic moves to a direct forwarding path, while the inner TLS continues to protect website data.
4. Other traffic keeps its applicable handling. If the conditions aren’t met, don’t assume the outer encryption has been removed; the core determines the actual path.

“Direct forwarding” doesn’t necessarily mean a specific operating-system-level zero-copy operation is enabled. Whether further copying can be reduced depends on the system, connection type, and core implementation. Setting xtls-rprx-vision in the configuration only enables that flow-control mode; it doesn’t guarantee every connection will use the same fast path.

How REALITY works without your own certificate

A conventional TLS server usually needs a certificate and private key for its domain. REALITY uses a different handshake and authentication design, incorporating TLS handshake characteristics from a destination site so the proxy server doesn’t need to obtain and renew a public certificate for its domain in the usual way. It doesn’t mean copying an arbitrary website’s certificate to the server.

The client still needs to verify that the connection is trusted. Common deployments use an X25519 key pair generated by the server: the private key stays on the server, while the public key is shared with clients. The client also needs the correct SNI, Short ID, and other parameters. The Short ID helps identify connections, but it can’t replace key authentication and shouldn’t be treated as the sole login password.

• SNI: Must match a server name allowed by the server configuration. The connection address can be an IP, while SNI is usually a domain name; they are different fields.
• Public key: Comes from the node’s server configuration. Don’t use the destination website’s certificate key or copy one from another node.
• Short ID: Must match a value allowed by the server. It’s represented in hexadecimal and has configuration-specific length limits; keep the value provided by your subscription whenever possible.
• Fingerprint: A common client option is chrome. It shapes the handshake characteristics and doesn’t mean you have to use that browser.
• Time: Keep the device clock accurate. If the server enforces a time-difference limit, a significant clock mismatch will cause authentication to fail.

The server also sets a handshake destination, which may appear as target or, in older versions, dest. The destination needs suitable TLS support and must be reachable from the server; a poor choice can disrupt the handshake. Connections that fail authentication may be routed to the destination site, but this doesn’t mean a proxy is undetectable in every network environment.

v2rayN setup: check each field instead of guessing from the node name

Import the complete subscription or share link from your provider, then open the node editor. The two cards below illustrate fields to check for the same connection; they aren’t ready-to-use node settings. Port 443 is just a common example—use the value configured on your server.

In v2rayN, go to Settings → Parameter Settings to check the local listening port, then verify which core the current node actually uses. Menu details vary by version, but the local and remote ports are always separate. Your browser connects to the local proxy entry; the core connects to the node’s remote port.

On Android with v2rayNG, check the VLESS, REALITY, and Flow fields, along with core support. v2flyNG uses the v2fly core, so don’t assume this Xray-specific combination will work unchanged. A node appearing in the list doesn’t guarantee the current core supports every feature it uses.

How to verify a speed improvement—not just check the latency

When comparing protocols, keep the server, exit, and test destination as consistent as possible. Comparing servers in different regions can make route differences look like protocol gains. A basic TCP connectivity test only shows that a connection to a port can be established; it doesn’t prove REALITY authentication succeeded or that Vision switched to its optimized path.

1. Keep conditions consistent: Record the client and core versions, node address, transport, Flow, and system proxy status. Close other downloads.
2. Confirm traffic uses the proxy: Check the logs for the destination connection and routing result to make sure the speed test domain isn’t matched by a direct-connection rule.
3. Track metrics separately: Record time to first byte, sustained download speed, and CPU usage on the client and server. Don’t use a single latency reading as an overall score.
4. Repeat measurements: Run each setup three times for 60 seconds per run, then compare the median. This is a suggested test method, not a result measured for this article.
5. Investigate unexpected results: If speed drops, check packet loss, server load, and exit bandwidth limits. If CPU usage falls but speed doesn’t change, bandwidth may already be the limiting factor.

Common REALITY and Vision connection problems

Follow a consistent troubleshooting order: local entry, remote port, authentication parameters, core compatibility, DNS and routing, and only then performance testing. REALITY deployment and Vision forwarding optimizations can reduce overhead at specific stages, but whether a connection works still depends on the entire path.