How REALITY and XTLS Vision Work: Why Removing a Layer of Encryption Can Improve Speed

First, separate the three names: VLESS, REALITY, and Vision

A common node setup in v2rayN or v2rayNG is “VLESS + REALITY + XTLS Vision.” These are three distinct components, not interchangeable protocol names. VLESS defines how proxy requests carry user credentials and destination addresses; REALITY handles the outer secure handshake and authentication; Vision is an Xray flow-control mechanism that determines how some data is handled inside the tunnel. Understanding these separate layers makes it easier to know which setting to check when something goes wrong.

A common value for VLESS encryption is none. This means the VLESS protocol does not add another layer of payload encryption; it does not mean the entire connection is sent in plaintext. With REALITY, the security layer still participates in establishing the connection. And when you visit an HTTPS site, the application’s own TLS encryption remains in place.

Why HTTPS traffic through a proxy can have two layers of encryption

When you open an HTTPS website, your browser first completes a TLS handshake with the destination. The page, login details, and response data are then encrypted at the application layer. The proxy simply carries this connection to the destination; it does not gain the keys needed to decrypt the website session.

If the proxy tunnel also uses TLS, the browser’s encrypted traffic is wrapped again in TLS records for the proxy connection. The client encrypts the outer layer, the server decrypts it, then forwards the inner ciphertext to the website. This “double wrapping” is common and useful in many cases, but with high-volume traffic it adds encryption and decryption work, buffer handling, and data-copying overhead.

Vision does not disable HTTPS. Instead, it identifies the stages of an inner TLS connection and changes how subsequent data is transferred when conditions allow. For recognized TLS 1.3 traffic, it can switch to direct forwarding at the appropriate stage, so already-encrypted application data avoids redundant TLS encryption and decryption by the outer layer. The initial handshake and necessary proxy information still need protection; the connection does not simply send all data in the clear once established.

• Website encryption remains unchanged: The browser still verifies the destination website’s certificate. The proxy should not ask you to disable certificate verification for websites.
• Optimization depends on traffic matching specific conditions: Not all TCP data or TLS versions can use the same optimized path.
• Plain HTTP does not become HTTPS: Vision does not add end-to-end encryption between an application and its destination website.
• The handshake stage still uses padding: Vision pads data during the initial stage, so it is inaccurate to say that “every packet gets smaller.”

How REALITY borrows the look of a real website’s handshake

A standard TLS proxy service usually needs its own domain and certificate. REALITY takes a different approach: the server is configured with a suitable real TLS destination, and the client starts a handshake using agreed authentication parameters. If authentication succeeds, the client and REALITY server establish a proxy tunnel. If it fails, the server can forward the connection to the configured destination, making it look like a normal TLS interaction with a real website.

“Borrowing a real website” is a useful way to understand the idea, but it does not mean the server has that website’s private key or that all proxy traffic is routed through the site. After successful authentication, the server forwards proxy data to the requested destination. The configured website is mainly involved in the handshake’s appearance and the handling of unauthenticated connections. The client also does not establish trust in the REALITY server simply by copying the destination website’s public certificate locally.

The server address, SNI, and real destination are different fields

• Server address: The IP address or domain the client actually connects to—the proxy server. Do not replace it with the website used as the handshake destination.
• SNI / Server Name: The name the client uses in the handshake. It must be allowed by the server. A reachable address does not mean this field is correct.
• Server’s real destination: Chosen by the server operator. Check for compatibility requirements such as TLS 1.3 and HTTP/2, along with latency and reachability from the server.
• Client fingerprint: Affects how the ClientHello is constructed, for example chrome. It cannot replace the correct key, SNI, or identity parameters, and it does not guarantee behavior identical to a real browser in every respect.

Which settings to check in v2rayN and v2rayNG

Start by importing a complete node from a trusted subscription, then check its fields in the node editor. Menu names vary across client versions, but the meanings of protocol, transport, security layer, and Flow stay the same. The cards below show how to check settings at both ends of the same connection; they are not complete nodes to copy and use as-is. Port 443 is only a common example—use the port the server actually listens on.

REALITY key parameters may have different names in client interfaces and across Xray configuration versions. Older configurations commonly use publicKey, while newer ones may use password. Don’t transfer JSON by matching field names alone; follow the documentation for the running core and the client’s import rules. The server’s private key should never be shared with regular users.

A Short ID is a hexadecimal string. If it is not empty, its character count must be even, with a maximum length of 16 characters. Whether an empty value is allowed depends on the server configuration. It is not a user ID or a field for a random note. If your subscription provides a Short ID, keep it unchanged; altering even one character can cause authentication to fail.

Why removing a layer of encryption can make things faster—and why it might not

Encryption is not the only source of overhead, but it can be a significant one on high-throughput connections. Vision reduces redundant encryption and decryption for eligible data and, where the implementation allows, uses a more efficient transfer path to reduce CPU usage and data-copying overhead. These gains are more noticeable when a server handles multiple high-volume connections than with short web requests.

If the bottleneck is packet loss on a mobile network, server egress bandwidth, ISP congestion, or destination rate limiting, removing a layer of encryption may not change download speeds. TCP congestion control still applies, and REALITY cannot increase a route’s physical bandwidth. A fast result from one node does not prove that “all REALITY nodes are faster than other setups.”

How to run a fair comparison

1. Use the same device, network, server, and download target. Close other bandwidth-heavy tasks, and don’t mistake changes in Wi-Fi signal strength for protocol gains.
2. Use two test configurations explicitly supported by the server. Don’t simply clear the Flow field to create a baseline; client and server settings must match.
3. Run a 60-second download three times per setup, and record average throughput, client CPU usage, server CPU usage, and connection errors.
4. Test a large file and initial webpage load separately. If CPU usage drops but throughput stays the same, the optimization is working, but the current speed bottleneck may be elsewhere.

Troubleshoot connection failures by handshake stage

“Handshake failed” only means the secure connection was not completed; it does not automatically indicate a certificate problem. Mismatched REALITY authentication parameters, an unapproved SNI, an unreachable server destination, or an incorrect device clock can all cause a connection failure. First check whether TCP connects, then verify REALITY authentication, and finally check the VLESS user and Flow settings. This is usually more effective than repeatedly switching encryption options.

1. Check the connection address first: Make sure the client is connecting to the proxy server, not the handshake destination. If the logs show a timeout or connection refusal, check the listening port, firewall, and network reachability.
2. Check the system clock next: In Windows, open Settings → Time & language → Date & time and check automatic time and sync status. On Android, enable automatic date and time. REALITY may enforce a time-difference limit based on the server policy.
3. Verify the authentication parameters: Compare SNI, the client authentication key parameters, and Short ID one by one. If the server key has changed, an old subscription may stop working even when the address is unchanged.
4. Check the user and Flow: Confirm the VLESS user ID exists on the server and both ends use compatible Vision settings. Don’t confuse REALITY security settings with the Flow field.
5. Check which core is actually running: Confirm that v2rayN is using an Xray core that supports this combination. Being able to save a node in the interface does not guarantee that the selected core accepts every field.
6. Check the destination and forwarding last: If the handshake succeeds but pages won’t load, check server DNS, outbound routing, destination reachability, and whether the client is sending that traffic through the proxy.