REALITY and XTLS Vision: How Flow Control Reduces Redundant Encryption and Improves Speed

Understand the roles of VLESS, REALITY, and Vision

The common “VLESS + TCP + REALITY + Vision” setup combines several configuration layers; these are not four interchangeable protocol names. VLESS handles proxy requests and user identification; TCP provides the transport connection; REALITY provides the security layer; and Vision is a flow-control mode set with xtls-rprx-vision. Getting the UUID right does not mean the security layer and flow control are configured correctly.

This guide covers the Xray implementation. v2rayN is a desktop client for managing configurations, not a core in its own right; this setup requires the Xray core that supports it. On Android, v2rayNG uses the Xray core. v2flyNG uses the v2fly core. The ability to import some VLESS links does not mean it supports this entire setup.

Nested TLS: Why HTTPS Gets Encrypted Again

When you visit an HTTPS site, TLS is already established between your browser and the site. When that request passes through a proxy, a standard TLS proxy tunnel wraps those encrypted bytes in another layer. The connection from your client to the proxy server can therefore carry data with “outer TLS wrapping inner TLS.”

Inner TLS remains in place beyond the proxy server and terminates only at the destination website. The proxy server typically does not have the website session keys and does not need to decrypt page contents. Outer TLS protects the link between your client and the proxy server, preventing unencrypted proxy requests and other traffic from being exposed. The two layers protect different endpoints, so neither is simply “useless.”

• Processing overhead: The same already-encrypted data is encrypted and decrypted again by the outer layer. The cost is more noticeable at high throughput or on lower-powered CPUs.
• Encapsulation overhead: TLS records require headers, authentication tags, and buffering—not just another encryption operation.
• Traffic fingerprints: The relationship between inner and outer handshakes and data lengths can create observable patterns. Changing the port alone does not eliminate them.

That is why “low handshake latency” does not necessarily mean “fast downloads.” Handshake time measures connection setup; sustained download speeds also depend on bandwidth, packet loss, congestion control, and CPU performance. Redundant encryption is only one factor.

How Vision Reduces Redundant Encryption—and What Protection Remains

Vision does not send all data in plaintext. It identifies the handshake and data phases of inner TLS and applies padding to traffic at the start of a connection. Once it identifies qualifying inner TLS 1.3 traffic, it can switch to a more direct forwarding path, avoiding repeated outer encryption of data already protected by TLS.

After the switch, TLS between your browser and the website still encrypts and protects page contents. Traffic that does not meet the detection criteria cannot be assumed to have switched to direct forwarding; it must still use the appropriate secure transport path. In particular, ordinary HTTP, non-TLS applications, and UDP requests do not necessarily receive the same optimization just because Vision is enabled on the node.

“Flow control” here does not mean bandwidth limiting. xtls-rprx-vision will not turn a 100 Mbps plan into a faster connection or fix congestion between networks. It reduces extra processing for certain types of traffic and can make some nested-TLS patterns less pronounced. Actual gains depend on your connection.

The REALITY Handshake: How the Public Key, SNI, and Target Site Work Together

REALITY handles secure handshakes and authentication. It uses the TLS handshake structure together with server keys and client authentication settings, allowing legitimate clients to verify the server and establish a protected connection. Unlike traditional website TLS, it does not require you to obtain and install a publicly trusted certificate for the proxy endpoint.

That does not mean you can “use any domain you like.” The server is configured with a target site and permitted server names, so the client’s SNI must be compatible with the server settings. The public key must correspond to the server’s private key. SNI is a name sent in the handshake, not a substitute for the node’s server address, and it cannot turn an arbitrary website into a proxy server.

1. Connection address: The client first connects to the node’s IP address or domain and port—for example, the provider’s assigned 443—not directly to the website named in the SNI.
2. Handshake parameters: The client sends the specified server name, fingerprint, and required REALITY authentication information. Use values from the same node configuration for every field.
3. Authentication path: The server recognizes a legitimate request and establishes the proxy connection. Connections that fail authentication may be routed to the configured target site according to REALITY’s behavior.
4. Proxy request: Once the security layer is established, the server validates the VLESS user and handles the destination connection. With Vision configured, it also identifies subsequent traffic.

Client setup: Check the two groups of fields separately

Import the complete link or subscription from your provider first, then verify the fields. To enter settings manually in v2rayN, go to “Servers” → “Add VLESS server”; to edit an existing node, open its edit window. In v2rayNG, tap “+” in the top-right corner to enter a VLESS configuration manually. Labels and menus can vary by version, so match fields by their meaning rather than relying only on where they appear.

shortId is a hexadecimal string, usually no more than 16 hex characters and with an even length. Whether it can be empty depends on the server configuration. Do not pad it with zeros or enter the UUID here. The client only needs the corresponding public-key authentication parameter; never give the server’s private key to the client.

• Check the encryption field: encryption=none in a common VLESS configuration does not mean the connection is unprotected. REALITY provides the security layer in this setup.
• Check the local port: In v2rayN, go to “Settings” → “Parameter settings” and check the local listener. If the actual port is 10808, your browser or test tool must connect to that port; do not copy a port from another setup.
• Check the running core: Review the startup log to confirm that Xray actually launched, and note its version. The client version and core version are separate.
• Check the link: Copy share links with parameters in full; chat apps may truncate everything after the question mark. Import subscription URLs and single-node links through their respective import options.

Speed tests: Don’t use latency as a substitute for throughput

To find out whether “reducing redundant encryption improves speed,” you need comparable test conditions. Ideally, get two configurations from the same server and change only the variable you want to test. If you also change the server region, transport, and routing, you cannot attribute the difference to Vision. Without control of the server, the results reflect the overall experience of two nodes.

1. Keep the route consistent: Use the same device, network, and download target. Confirm that the request matches your proxy rules so one test is not direct while the other goes through the proxy.
2. Keep the local endpoint consistent: Use the same local proxy port for both tests. Stop other downloads first to prevent background traffic from competing for bandwidth.
3. Repeat the tests: Run 3 tests per setup, each lasting 60 seconds, alternating the order. Record average throughput, CPU usage, and failed requests.
4. Use consistent units: 100 Mbps converts theoretically to 12.5 MB/s, before accounting for protocol overhead. Do not compare the numbers without converting the units.
5. Keep test logs: Record the test time, core version, node configuration type, and error messages. Remove UUIDs, subscription URLs, and other credentials before sharing.

The test counts and durations above are recommendations, not results measured by this site. Similar throughput with lower CPU usage may still indicate reduced resource overhead. A faster initial connection alone does not prove that sustained downloads are faster. For more on the handshake and its fields, see the REALITY section in the protocol reference.

REALITY and Vision FAQ