REALITY and XTLS Vision Explained: How Less Encryption Can Be Faster

What do REALITY, VLESS, and Vision each do?

These technologies operate at different layers and can be combined, but none replaces the others. VLESS carries proxy requests and user identity information, but does not generally encrypt payloads. REALITY provides secure handshakes and authentication. Vision is an XTLS flow-control mode focused on identifying TLS traffic, applying padding, and optimizing subsequent forwarding.

A typical VLESS + REALITY + Vision node uses TCP transport. The client passes browser connections to a local proxy listener, then its core connects to the proxy server, which in turn connects to the destination site. At least two separate security contexts are involved: the connection from the client to the proxy server and the connection from the browser to the website. These are not a single handshake.

These capabilities are provided by the core, not by the client app’s name. v2rayN is a desktop management interface; to use these nodes, make sure it is configured with an Xray core that supports the required features. On Android, v2rayNG uses the Xray core. v2flyNG uses the v2fly core, so importing a VLESS profile does not mean it can run the Xray-based REALITY and Vision combination.

• Protocol layer: VLESS and the user ID in your subscription define how proxy requests are structured and how users are identified.
• Security layer: REALITY uses parameters such as the server’s public key and server name to establish the connection.
• Flow-control layer: Both client and server must support xtls-rprx-vision.
• Transport layer: TCP is commonly used. Some interfaces and configuration guides call it RAW; check the field definitions for your core.

Why does “TLS over TLS” add overhead?

Wrapping already-encrypted HTTPS data in another layer of protection adds work for the proxy. When a browser visits an HTTPS site, the application data is already encrypted by the site’s TLS session. A traditional TLS proxy tunnel then wraps that ciphertext in another TLS layer. The outer layer does not need to inspect webpage content, but it still has to handle record framing, encryption and decryption, buffering, and data transfer.

Vision doesn’t disable website encryption. Once it identifies eligible inner TLS traffic, it changes how subsequent data is forwarded, avoiding the need to keep fully wrapping that encrypted data in outer TLS records. Vision also includes early-stage padding and other processing, so it’s not simply “sending everything raw from the start.”

Reducing copies and reducing encryption are not the same thing. The core implementation, operating system, and connection type all affect whether a more direct data path is possible; using Vision does not mean every connection achieves zero-copy transfer. Eligible inner connections, such as TLS 1.3, are central to understanding this optimization. It does not follow that all UDP, video, or download traffic will get faster by the same amount.

Why doesn’t REALITY require your own domain certificate?

REALITY uses an authentication method different from the one used to deploy a standard website certificate, so the server generally doesn’t need to obtain and renew its own domain certificate for the proxy connection. The server holds a private key, while the client uses the matching public key and other parameters to authenticate the connection. That doesn’t mean there is no authentication, or that entering any website name will make a connection work.

The server also specifies a target site and the server names it accepts. Under REALITY’s design, connections that fail authentication can be directed to the configured target site, while legitimate clients complete the required authentication. The target site must meet the deployment requirements; TLS 1.3 and HTTP/2 support are common baselines. Simply being able to open a site in a browser does not prove full compatibility.

Public keys are usually displayed as encoded text, so “32 bytes” does not mean the input field should contain only 32 characters. Public and private keys are generated as a pair. Never copy the server’s private key into the client, and don’t generate a new public key to replace the one in your subscription, or the keys won’t match.

How do you set flow, public key, and shortId in v2rayN?

Import the full subscription first, then compare its settings against the provider’s parameters. This is usually more reliable than assembling the configuration by hand. In the v2rayN main window, select the node and double-click it to open the editor. Check the VLESS node’s transport, security, and flow-control fields. Labels vary between interface versions, so go by what each field means rather than changing unrelated settings just to find a menu with a matching name.

The two cards below describe settings for the same node; they are not ready-to-use connection examples. Port 443 is only a common example. The actual port, user ID, public key, shortId, and server name must all come from the same server configuration.

• flow: A common value is xtls-rprx-vision; enter it with the exact spelling and hyphens. Don’t substitute other flow values from outdated guides, and don’t add Vision to a node that doesn’t use it.
• Public key: The common parameter name in share links is pbk. Different core generations or interfaces may use labels such as publicKey or password for the corresponding value. Check the documentation for your version, and don’t blindly populate multiple fields in the raw configuration.
• shortId: Usually an even-length hexadecimal string, up to 16 hexadecimal characters. An empty value is valid only if the server allows it; it is not a free-form node label.
• Fingerprint: chrome selects a handshake fingerprint. It doesn’t require you to browse with that browser, nor does it install a browser for you.

After saving, reselect the node and reload the configuration in the core. If you edit an entry in the node list without updating the active outbound, the logs may appear to contradict the editor. In v2rayNG on Android, check the relevant fields in the node editor, then confirm the startup result in the main screen’s logs.

How to troubleshoot connection failures and unchanged speeds

First identify where the connection stalls, then consider performance tuning. If the handshake hasn’t completed, there’s no point estimating Vision’s throughput. If the website opens normally, a speed test that shows no improvement does not mean the public key is wrong. Change one setting at a time and keep a copy of the original node so you can revert without losing the working configuration.

1. Check that the core starts: Look for errors in the logs such as unknown fields, an invalid flow, or failed configuration parsing. At this stage, check the core type and configuration format rather than changing DNS.
2. Check the address and port: Make sure the address and port match the subscription. A successful TCP connection to the port only confirms that the network endpoint is reachable; it doesn’t mean REALITY authentication succeeded.
3. Check authentication settings: Verify the user ID, public key, shortId, and SNI, and make sure the system date and time are correct. Handshake errors can have several causes; a generic connection-closed message alone does not prove the public key is wrong.
4. Check that the app is using the proxy: Browsers, terminals, and other apps may use different proxy entry points. First check whether the logs show a request to the expected destination, then check the system proxy or the app’s own proxy settings.
5. Check routing and name resolution last: If the proxy connection succeeds but a particular domain fails, investigate DNS, routing rules, and whether the destination site is reachable. The issue may have nothing to do with REALITY or Vision.

For a meaningful performance comparison, keep the server, target file, network connection, and number of concurrent transfers the same. Record CPU usage on both client and server, sustained throughput, and failures. For example, run each setup three times for 60 seconds and compare the stable middle portion rather than the initial spike. This is a suggested test plan, not a benchmark result from this guide.

Configuration issues that are easy to mix up

Most confusion comes from treating feature support, successful authentication, and app traffic going through the proxy as the same thing. Use the questions below to narrow down the issue. For more on routing, see the site’s advanced configuration guide.

When choosing a node, first check the provider’s complete settings and core requirements, then make sure it suits your network. REALITY removes the burden of deploying your own certificate, while Vision provides a more efficient forwarding path for eligible TLS traffic. Neither replaces a reliable server, a healthy network connection, or accurate client settings.