This article is for readers who already know how to import subscriptions and want to understand how VLESS + REALITY + XTLS Vision work together. It explains what REALITY and Vision each do, where the speed gains come from, and how to verify client parameters, identify performance bottlenecks, and troubleshoot handshake failures.
Where TLS handshakes and redundant encryption come from
When visiting a regular HTTPS website, the client first establishes a TCP connection with the server and then begins the TLS handshake. The handshake negotiates the TLS version, cipher suite, server name, and ephemeral keys, while also validating the certificate presented by the server. Only after the handshake is complete does the browser send HTTP data through the encrypted channel. A new TCP and TLS connection usually requires several network round trips, so higher latency makes the wait for the first page load more noticeable.
If a proxy protocol adds another TLS layer while the application itself already uses HTTPS, the result is an inner HTTPS connection carried inside an outer encrypted channel. This does not simply mean the data is encrypted twice: each layer protects a different connection, but the outer layer still adds record framing, encryption and decryption, buffer copies, and connection-state handling. During high-throughput downloads, on weaker devices, or with many concurrent connections, this extra work is more likely to show up as higher CPU usage and a measurable speed difference.
Traditional VLESS + TCP + TLS requires the server to hold a certificate matching the domain and to handle certificate renewal and DNS resolution correctly. VLESS + REALITY still performs a TLS-like handshake, but its authentication method and deployment model are different; XTLS Vision operates at the data-transfer layer and identifies encrypted traffic that can be sent more directly. They are not the same feature, and REALITY should not be treated as a simple “speed boost” switch.
How REALITY performs the handshake and authentication
REALITY is a transport security solution in the Xray ecosystem, commonly used with VLESS, TCP, and Vision. The server does not need a public certificate for its own domain; instead, it selects a real target website that can be reached reliably from the server's location and presents suitable TLS characteristics. After the client sends its handshake parameters, the server uses the REALITY private key, the public key configured on the client, the Short ID, and time information to determine whether the request is valid.
- Build the client handshake: Use the configured Server Name, REALITY public key, Short ID, and browser fingerprint to create the request, then connect to the server address and port supplied by the subscription.
- Authenticate on the server: The server uses its private key to verify the client parameters. The public and private keys must match, and the Short ID must be one of the values allowed by the server.
- Create a TLS-like appearance: The handshake follows the target site's TLS characteristics, making the connection observed on the network resemble ordinary TLS traffic.
- Enter the VLESS session: After authentication succeeds, the connection carries VLESS data; when
xtls-rprx-visionis configured, Vision then processes the subsequent traffic. - Handle unexpected requests: Connections that do not meet REALITY authentication requirements do not enter the proxy session; the server handles them according to its configuration for connections to the target site.
“Borrowing a real site's handshake” refers to the handshake characteristics and target selection. It does not mean obtaining the target site's private key, nor does it mean the proxy server decrypts the target site's HTTPS content. The client ultimately trusts the server identity associated with the REALITY public key. Copying only the Server Name without the correct public key or Short ID will still result in a failed connection.
VLESS + REALITY + Vision
- Network
- TCP
- Security
- reality
- Flow
- xtls-rprx-vision
- Port
- 443
- Fingerprint
- chrome
After importing a subscription, retain the public key, Short ID, Server Name, and Flow; do not copy only the server address.
VLESS + WebSocket + TLS
- Network
- WebSocket
- Security
- tls
- Path
- /ws
- Port
- 443
- Certificate
- Domain match
This is a different deployment path that depends on a domain, certificate, and WebSocket path; do not apply Vision's Flow to it.
Why XTLS Vision reduces extra processing
XTLS Vision is a Flow mode for VLESS, configured as xtls-rprx-vision. It determines, after the proxy connection is established, which data still needs complete outer-record framing and which qualifying TLS traffic can use a more direct transport path. Ordinary web browsing, video, and downloads mostly use HTTPS, making this traffic the primary target of Vision's optimization.
| Comparison | Standard TLS framing | XTLS Vision |
|---|---|---|
| Protocol combination | The VLESS outer layer continues handling TLS records | The VLESS Flow identifies inner TLS traffic |
| Data copying | Usually involves more buffering, framing, and record processing | Can reduce redundant data movement when conditions are met |
| CPU load | Outer-layer processing is more noticeable during high-speed transfers | Large transfers generally make it easier to reduce CPU usage |
| Supported protocols | Can be used with multiple TLS combinations | The Flow is configured only for VLESS and is not used with VMess |
| Compatibility requirements | Depends on the selected transport and security layers | The Xray capabilities of the client and server must match |
Vision does not disable HTTPS encryption or send application data in plaintext across the public internet. TLS protection between the browser and the target website remains in place, as does the REALITY handshake authentication. The optimization affects the data path and framing method, aiming to avoid unnecessary repeated processing of already encrypted continuous data.
Not every connection enters the direct transport path immediately. Vision needs to inspect the initial data, identify TLS records, and apply its own flow-control rules; ordinary plaintext TCP, unrecognized payloads, and connections that do not qualify are still transmitted normally. Test results therefore depend heavily on the type of traffic: a large HTTPS download is more likely to show a difference than a short request of a few dozen KB.
Bottom line: Vision optimizes the data path, not the network distance
If the baseline round-trip latency is 180 ms, enabling Vision will not turn the physical latency into 20 ms; it is more likely to reduce CPU, copying, and outer-record overhead during sustained transfers. If the first byte is slow, check the route and handshake first; if the connection cannot fill the available bandwidth, then examine Vision and device performance.
How to understand the latency and throughput benefits
The practical benefits of combining REALITY and Vision usually come from three areas: fewer certificate-maintenance variables on the deployment side, a handshake shape that resembles normal TLS, and less redundant framing and data copying during high-volume transfers with Vision. They cannot fix congestion, detours, severe packet loss, or insufficient server egress bandwidth, so comparisons must keep the server, route, target file, and test time consistent.
These figures illustrate a testing method rather than a fixed result that every route can reproduce. The example used the same four-core server, route, and single 2 GB HTTPS file, with five consecutive tests summarized by the median. The Vision combination reached a median of 36 MB/s, compared with 31 MB/s for standard VLESS + TCP + TLS; however, idle round-trip latency was close to 38 ms for both, showing that higher throughput does not necessarily mean lower network round-trip time.
- Web pages open slowly at first: Record TCP connection time, TLS handshake time, and time to first byte. If all three are high, check route distance, DNS, and server load first.
- Downloads start fast and then slow down: Check whether the server's egress has reached its limit, along with local single-core CPU usage, power-saving mode, and wireless network fluctuations.
- Speed-test results barely differ: On low-bandwidth routes or with short-lived connections, outer-layer processing is not the main bottleneck; fluctuations within 5% may simply be network jitter.
- Performance drops during peak hours: Test the same node at different times. If RTT and packet loss rise together, switching protocols usually cannot bypass congestion.
- Multiple connections are normal but one connection is slow: Check TCP congestion control, path MTU, and intermediate network quality; do not judge protocol performance from aggregate speed tests alone.
Bottom line: Establish a control group before judging protocol gains
Use the same server and target file, run five tests for each setup, and compare the median. Only persistent differences in throughput, CPU usage, or handshake success rate should be attributed to the transport combination. Comparing different nodes directly confuses route differences with the effects of REALITY or Vision.
How to verify client parameters
A subscription usually provides the address, port, user ID, Flow, transport, REALITY public key, Short ID, Server Name, and fingerprint in one bundle. If any one of these differs from the server configuration, the result may be a timeout, an immediate disconnect, or an authentication failure in the logs. Manually overwriting a single field after updating a subscription is one of the most common causes of parameter mismatches.
Desktop client checklist
- Client
- v2rayN
- Entry point
- Edit server
- Core
- Xray
- Flow
- xtls-rprx-vision
- Local port
- 10808
In “Settings” → “Parameter settings,” confirm the local listening port; on the server edit page, focus on the transport, security, and REALITY fields.
Android client checklist
- Client
- v2rayNG
- Core
- Xray
- Network
- tcp
- Security
- reality
- Fingerprint
- chrome
Long-press the configuration to open its edit page, check the public key, Short ID, Server Name, and Flow, then save and reconnect.
v2rayNG uses the Xray core and is suitable for using REALITY and Vision directly. v2flyNG uses the v2fly core, so its feature set depends on what the v2fly core supports; similar-looking interface fields do not guarantee support for Xray-specific combinations. When a subscription includes a REALITY node, first confirm that the selected client and core explicitly support the relevant parameters.
Protocol: VLESS
Transport: TCP
Security: REALITY
Flow：xtls-rprx-vision
Server port: 443
Fingerprint: chrome
Must match: user ID, public key, Short ID, Server NameCommon questions and configuration boundaries
REALITY, Vision, and VLESS often appear in the same node configuration, but they serve different roles: VLESS is the proxy protocol, REALITY handles transport security and server authentication, and Vision is a VLESS flow-control mode. Separating these roles makes it possible to identify whether a problem lies in the handshake, authentication, transport, or client takeover stage.
Does REALITY always have lower latency than standard TLS?
Not necessarily. Baseline RTT is mainly determined by physical distance and the network route. Run five consecutive handshake-time tests on the same server; when the difference is only a few milliseconds, treat it as normal variation rather than a consistent protocol-related reduction.
What should I do if the handshake fails after importing a subscription?
First enable automatic system time synchronization, then update the subscription once more. Next check the server port, public key, Short ID, Server Name, and fingerprint. In particular, do not overwrite REALITY's domain field with the domain value from a standard TLS configuration.
Can Vision be used with a VMess node?
No. xtls-rprx-vision is a Flow for VLESS. A VMess node must use the transport and security settings specified by its subscription; adding this Flow manually does not convert the node to VLESS.
Is it normal for the speed to remain unchanged after connecting?
Yes. If the route is capped at 20 Mbps, the test file is too small, or the device has ample performance, redundant framing is not the bottleneck. Test with an HTTPS file of at least 1 GB and record CPU usage, RTT, packet loss, and average throughput at the same time.
Why can't I connect even after changing the fingerprint?
The fingerprint is only one handshake parameter. Restore the value supplied by the subscription and check the core logs; if the connection still fails, ask the server administrator to verify the private-key/public-key pairing, permitted Short IDs, target address, and system time.
What to check when choosing a combination
- Both the server and client use an Xray core that supports REALITY and Vision, and the feature versions meet the configuration requirements.
- The node is explicitly labeled VLESS, TCP, REALITY, and
xtls-rprx-vision; do not assemble fields from other protocol combinations. - Use the parameters delivered by the subscription as the source of truth. After updating it, test the original configuration before adjusting routing or the system proxy.
- When troubleshooting, disable parallel variables, change only one field at a time, and retain the core logs from the corresponding time.
- Judge speed alongside RTT, packet loss, CPU usage, and server egress; do not draw conclusions from a single web speed test.
Overall, REALITY addresses certificate deployment and handshake authentication, while XTLS Vision addresses extra processing for specific data flows. Their combination is most likely to help on stable routes with high-bandwidth, sustained HTTPS traffic; when the bottleneck is congestion, packet loss, or an incorrect route, fixing the network and configuration is more effective than changing protocol names.