REALITY and XTLS Vision Explained: How VLESS Avoids Double Encryption

What VLESS, REALITY, and Vision Do

“VLESS + REALITY + Vision” in a node name does not mean three peer protocols. VLESS operates at the proxy protocol layer: it identifies users with details such as a UUID and carries the destination address. VLESS does not provide its own data encryption like VMess, so connections over the public internet need a suitable security transport. Setting VLESS encryption to none does not mean the entire connection is sent in plaintext.

REALITY is a security transport in the Xray ecosystem. It combines TLS handshake characteristics, server keys, and client authentication data to establish a protected connection. XTLS Vision uses the flow setting to handle initial traffic, apply padding, and optimize forwarding when conditions allow. A client with V2Ray in its name does not necessarily support this configuration in its current core; this guide covers the Xray implementation.

This sequence shows the logical roles of each component; it does not mean that every stage opens a separate network connection. In practice, authentication, handshaking, and traffic processing work together. When troubleshooting, identify the failing layer first: an unreachable port points to a connection issue, a mismatched public key to a security handshake issue, a mismatched UUID to proxy authentication, and incorrect website routing usually calls for checking routing.

Understanding REALITY Through the TLS Handshake

When a browser connects to an HTTPS website, it first sends a ClientHello containing supported TLS versions, cipher suites, extensions, and other details. The server replies with handshake messages, and both sides negotiate keys. A traditional proxy's outer TLS layer follows a similar process. If the browser also uses HTTPS to reach the website inside the tunnel, the result is website TLS nested inside proxy TLS.

REALITY is not designed to produce the same handshake behavior just by entering any well-known domain. The server must be configured with a suitable destination and permitted server names; the client also needs the matching public key, shortId, and other parameters. A legitimate client uses these details to authenticate the server and establish a connection; it does not rely solely on the destination website's standard certificate trust chain.

• Connection address: The server IP address or domain the client actually connects to. It can differ from serverName.
• serverName: The server name used in the handshake, usually corresponding to SNI in the client interface. It must match the server's permitted configuration.
• Public key: Paired with the server's private key for REALITY authentication. The private key must remain on the server.
• shortId: A short identifier accepted by the server, often represented as a hexadecimal string. It is not an abbreviated UUID.

Connections that fail the relevant authentication checks can be handed off by REALITY to the configured destination, making their outward behavior more like that of a real website. This “borrowing” does not mean legitimate proxy traffic is routed through that website or that the destination website forwards user data for the proxy server. The choice and reachability of the destination, along with handshake compatibility, still affect the deployment.

How XTLS Vision Reduces TLS-in-TLS

With a conventional encrypted proxy forwarding HTTPS traffic, the browser has already encrypted the application data into TLS records, and the proxy encrypts it again in the outer layer. This protects the tunnel but adds encryption, decryption, and encapsulation work, and can create observable nested-traffic patterns. One goal of Vision is to recognize suitable inner TLS traffic and, when conditions allow, avoid applying the same outer encryption path to payloads that are already encrypted.

Vision handles the initial connection data and applies padding, then chooses the next path based on the detected TLS state. Supported, identifiable TLS 1.3 traffic that meets the implementation requirements can enter the optimized forwarding path. This does not mean every byte, protocol, and connection is passed through directly from the start. Non-TLS traffic and connections that do not meet the requirements still need tunnel protection.

Vision does not need to decrypt HTTPS content between the browser and the destination website. The browser still validates the website certificate, and the inner TLS connection remains end to end. REALITY protects and authenticates the client-to-proxy connection, while website TLS protects application data between the browser and the destination. These are separate security boundaries.

Check Flow and Fingerprint Settings in the Client

In v2rayN, first make sure the node is running on the Xray core, then edit the existing VLESS node. In common versions, select the node and right-click “Edit server.” To add one manually, look for the VLESS option under the “Servers” menu. Menu labels may vary by version; check the protocol, transport, security, and flow fields in the edit window instead of relying on the node label.

flow specifies the flow control mode; it is not an encryption algorithm dropdown. The server-side user configuration and client must be compatible. If the server requires Vision, leaving the client field blank may cause authentication or flow checks to fail. Do not substitute other XTLS flow values found in older guides for xtls-rprx-vision.

fingerprint controls the simulated characteristics of the client's TLS ClientHello. chrome is a common value, but it does not turn the proxy into a browser or guarantee that the connection cannot be identified. The core may reject arbitrary strings, and switching fingerprints repeatedly will not fix an incorrect public key. Keep the node's supplied setting unless you have a specific compatibility reason to change it.

{
  "flow": "xtls-rprx-vision"
}

{
  "security": "reality",
  "realitySettings": {
    "fingerprint": "chrome"
  }
}

These are two separate JSON excerpts showing where the fields belong, not a complete configuration to merge and run. In the first excerpt, flow belongs to the VLESS outbound user object; in the second, security settings belong under streamSettings. A working configuration also needs the server address, UUID, server name, and key-related fields. Public key field names can differ between the interface, share links, and core versions. Use a configuration generated by your client instead of copying fields mechanically across versions.

Check the Port, Core, and Logs—in That Order

Before troubleshooting, distinguish the remote server port from the local proxy listener. The server determines the remote port used by the node; 443 is common but not required by REALITY. The client determines the local proxy port. If an app connects to the wrong local port, its requests will not use the expected outbound route even when the remote node is configured correctly.

1. Save the current configuration. Keep the original node address, remote port, UUID, flow, SNI, public key, and shortId. Hide authentication details in screenshots, and never share a full subscription URL.
2. Confirm which core is actually running. Check the core name and version in the startup log. v2rayN can manage multiple cores, and updating the interface does not automatically switch the core currently in use. On Android, v2rayNG uses the Xray core; do not treat v2flyNG, which uses the V2Fly core, as an equivalent way to configure REALITY.
3. Check TCP reachability. If the connection times out or is refused, check the remote listener, firewall, and address resolution first. A successful TCPing only confirms that a TCP connection can be established; it does not mean REALITY authentication succeeded.
4. Check the handshake and authentication. If the port is reachable but requests fail, compare the server name, public key, shortId, UUID, and flow one by one, and synchronize the system clocks on both ends. Routing rules cannot fix a key error.
5. Test with a new request. Save the changes, reload the node, and make a new website request. The browser may keep using an existing connection. Check the outbound tag in the logs too, to confirm the request is using the intended proxy.

If the core starts and the node test succeeds but some websites still will not open, check DNS and routing. A domain may match a direct-connection rule too early, an app may not use the system proxy, or UDP requests may bypass the proxy. Repeatedly changing the REALITY public key only introduces more variables. See the Configuration Reference for field definitions, or the User Guide for setup instructions.

REALITY and Vision FAQ