VLESS handles request formatting and user authentication, REALITY provides the outer secure handshake, and XTLS Vision identifies traffic and optimizes forwarding. For users who have already imported a node and want to understand its settings and performance, this guide walks through the handshake, certificate validation, flow control, and client setup, then lists the parameters to check when a connection fails. Performance claims are explained in terms of how the mechanisms work and where they apply; protocol names alone do not determine real-world speeds.
What VLESS, REALITY, and Vision Each Do
These are not three interchangeable protocols. The common “VLESS + REALITY + Vision” setup is a layered combination: VLESS describes proxy requests, REALITY provides transport security, and Vision is a flow control used with VLESS. Because client interfaces show all three in the same node editor, it is easy to assume that selecting REALITY automatically enables Vision.
| Layer | Main role | Where to check |
|---|---|---|
| VLESS | Carries the user identifier, destination address and port, and request type | Protocol, UUID, encryption |
| REALITY | Performs a TLS-style handshake with authentication and provides secure transport | security, SNI, public-key parameters, shortId |
| XTLS Vision | Handles initial padding, identifies inner TLS, and optimizes forwarding when conditions allow | flow = xtls-rprx-vision |
| TCP | Carries the underlying reliable byte stream | Transport type and server listening port |
VLESS encryption is usually set to none. “No encryption” here means only that the VLESS protocol does not add another layer of payload encryption; it does not mean the entire connection travels over the network in plaintext. In this setup, REALITY provides outer-layer security. When a browser visits an HTTPS site, the application also establishes a TLS connection to the destination site.
It is also important to distinguish the client from its core. v2rayN is a desktop client, and running a node requires selecting a core that supports the relevant features. v2rayNG uses the Xray core. v2flyNG follows the V2Fly core line, so the fact that its interface accepts VLESS settings does not mean it can run the same REALITY and Vision combination.
The REALITY Handshake and What “Borrowing a Certificate” Really Means
A standard TLS proxy typically presents a domain certificate from the server, which the client validates against the certificate chain and domain name. REALITY changes this deployment and authentication model: the server is configured with a target site, while the client sends an SNI, a fingerprint, and the authentication parameters REALITY requires. The server distinguishes valid clients from other connections.
“Borrowing a certificate” is a useful shorthand, not a literal copy of the target site's private key to the proxy server. For authenticated connections, REALITY uses its own keys and validation mechanisms to generate and validate temporary certificates. In cases such as failed authentication, the connection may be forwarded to the configured target site and exhibit that site's normal TLS behavior. The exact handling also depends on server configuration and implementation version.
The client does not simply disable all validation and accept any certificate. Server public-key parameters held by the client participate in authentication; the short ID must match a value allowed by the server, and the SNI must be one the server accepts. Assuming that “the certificate looks like it came from the target site” means “any domain will work” will cause the handshake to fail.
A typical REALITY deployment relies on a suitable TLS 1.3 target site. The handshake can be affected by whether the server can reach that site, whether the SNI is on the allowed list, and whether the client's clock is significantly off. When errors occur, check these concrete requirements first before considering whether changing the fingerprint will help.
How XTLS Vision Reduces Redundant Encryption and Encapsulation
When a browser visits an HTTPS site, TLS already protects the connection between the browser and the site. If a proxy then wraps that TLS ciphertext in another full layer of TLS, the result is often called “TLS over TLS.” It can still work, but processing the outer records—including encapsulation, encryption and decryption, and buffering—uses resources.
Vision does not stop encrypting as soon as it sees arbitrary data. It handles the initial connection traffic and padding, then identifies characteristics of the inner TLS handshake and records. When the implementation determines that conditions are met—particularly for inner TLS 1.3 traffic suitable for direct forwarding—it can switch to a more direct forwarding path and avoid redundant processing of existing ciphertext.
- At the start of a connection: Authentication, the VLESS request, and traffic identification are still required. This does not mean the outer handshake is skipped entirely.
- Eligible HTTPS traffic: Application-side TLS continues to protect website content. Vision primarily reduces redundant outer-layer processing; it does not decrypt the data exchanged between the browser and the site.
- Traffic that does not qualify: It cannot simply use the direct forwarding path; the required secure encapsulation and protocol handling still apply.
- Forwarding implementation: More efficient forwarding mechanisms may also be used when the system and connection conditions allow. The same path is not used on every platform or for every connection.
This helps explain why reducing redundant encryption can matter more on a low-powered CPU, under high concurrency, or during sustained transfers. Vision cannot increase the server's outbound bandwidth or turn a congested route into a low-latency one. If the bottleneck is packet loss or queueing across networks, less encryption overhead on the local machine may not noticeably improve download speeds.
How to Evaluate It: Measure Handshake Time and Sustained Throughput Separately
For a fair comparison, keep the server, destination site, and test window constant. Record the time to the first request, sustained download speed, and client CPU usage separately. If throughput improves but the first-request time barely changes, that is generally more consistent with reduced forwarding and encryption overhead—not proof that a network round trip was eliminated.
Configuration Fields: Port, SNI, Short ID, and flow
Whether a node works depends on the client and server parameters matching as a set. Get the complete configuration from your provider first, then check what the client imported. The figures below describe protocol or configuration limits, not performance tests by this site. Port 443 is common, but it is not the only valid port for REALITY.
Protocol and transport
- Protocol
- VLESS
- encryption
- none
- Transport
- TCP; some newer configurations call it RAW
- security
- reality
- flow
- xtls-rprx-vision
These options describe the combination covered here; they are not a complete node configuration you can connect with as-is.
Authentication and handshake
- Address and port
- Use the connection endpoint provided by your service provider
- UUID
- The corresponding VLESS user on the server
- SNI
- Must match a server-allowed serverNames value
- Public-key parameters
- Provided by the server's REALITY key configuration
- shortId
- Must match a value in the server's shortIds
The names of public-key fields in the interface or configuration may vary by version. Refer to the current core documentation and subscription format.
shortId is represented in hexadecimal. A non-empty value must have an even number of characters, up to 16 characters (8 bytes). Whether an empty value is allowed depends on the server's configuration. It is not an abbreviation of the UUID, nor should you generate one based on the node name. The safest approach is to keep the value supplied in the subscription.
SNI and the server address are not the same thing. The address identifies the host to connect to; SNI declares the server name during the handshake. A node address can be an IP address while the SNI is a domain allowed by the configuration. Do not change the SNI to the server IP just because the address is different, and do not hide authentication errors by skipping certificate validation.
v2rayN Setup and Connection Checks
Check the configuration in this order: correct import, supported core, successful handshake, working proxy. Seeing a latency value in the node list does not prove that REALITY authentication succeeded; a basic TCP probe only shows that the port is reachable to some extent.
- Check the node settings. Double-click the target node in the v2rayN list and confirm that the protocol is VLESS, security is set to REALITY, and flow is
xtls-rprx-vision. Interface section names may change between versions, but the meaning of these fields does not. - Check the active core. Open “Settings” → “Parameter Settings,” then review the core options. Confirm that the node is actually running on an Xray core that supports REALITY and Vision. Do not infer feature support from the client installer name alone.
- Check the local listener. In the same settings area, verify the local proxy port. For example, if the listener is actually at
127.0.0.1:10808, external test tools must use that address. If you changed the port, update the test command as well. - Run a real connection test. Select the node and use the real-connection latency test from the node list menu, then check the core logs. Authentication errors, incorrect public-key parameters, and connection timeouts require different fixes; they should not all be dismissed as “a slow node.”
- Verify the application path. Enable the system proxy and visit an HTTPS page. You can also specify a SOCKS proxy explicitly in a command-line tool to rule out the possibility that the application is ignoring the system proxy settings.
The command below applies only if the local SOCKS endpoint is listening on port 10808. socks5h lets the proxy resolve the domain, preventing local DNS results from affecting this test. The response status code can help confirm that the request completed, but it does not by itself prove that the specified flow was used for outbound traffic. Check the active node and logs as well.
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 -I https://example.com/On Android, v2rayNG also requires checking the imported REALITY parameters and granting the required VPN connection permission. If your configuration comes from a subscription that supports Xray extensions, do not copy it unchanged to v2flyNG and expect the same result. Being able to read subscription text and having a core that supports every field are two different things.
Performance Limits: Why Not Every Route Will Be Faster
“Less overhead” describes the mechanism; “lower latency” is a result that must be measured. REALITY still needs to establish an underlying connection and complete a secure handshake, and Vision's optimizations apply only to eligible traffic. If a page requires multiple DNS lookups, connects across regions, or waits while the server queues requests, encryption savings may account for only a small fraction of the total time.
| Observed behavior | Check first | Conclusion to avoid jumping to |
|---|---|---|
| Port is reachable, but the real connection fails | UUID, SNI, public-key parameters, shortId, system clock | If the port is open, authentication must have succeeded |
| Fast downloads, but slow first page load | DNS, connection setup time, destination response | High sustained throughput means every request has low latency |
| Throughput drops in the evening | Route congestion, packet loss, server load | Changing flow will fix a bandwidth bottleneck |
| CPU usage drops, but speed stays the same | Outbound rate limits, destination rate limits, local access bandwidth | The optimization is not working |
Keep the download target, number of connections, and proxy rules consistent across comparison tests. Run at least three tests and record the median. Do not compare a browser-cache hit with a cold-start request, or attribute results from servers in different regions to flow control alone. A controlled test helps distinguish protocol overhead from routing quality and server resource differences.
FAQ: Troubleshooting Connection Failures and Configuration Mismatches
Why configure Vision if REALITY is already selected?
REALITY is a transport security setting; Vision is VLESS flow control. Reopen the node editor and check the security setting and flow separately. If your provider requires xtls-rprx-vision, the client and server user configurations must match; an empty flow is not a substitute.
TCP latency shows a value, but the real connection keeps failing. Why?
Open the core logs first, then check the UUID, SNI, public-key parameters, and shortId. Next, make sure automatic time synchronization is enabled on the device and the server can reach the configured target site. A TCP latency test does not include full proxy authentication, so it cannot rule out a handshake problem.
Does setting the fingerprint to chrome make the connection behave like a real browser?
No. This setting mainly affects the client's TLS handshake fingerprint; it does not make all subsequent network behavior look like a browser. Keep the fingerprint recommended by your provider and supported by your current core. If the logs report that it is unsupported, update to a compatible core or check with your provider instead of cycling through random names.
Can I keep using the old public key and short ID after updating my subscription?
Use the new subscription parameters first. If the server has changed its keys or allowed short IDs, the old values may no longer authenticate. Reimport or update the node, check for an older node with the same name, and make sure the updated configuration is selected. Changing only the displayed name is not enough.
The key to understanding this configuration is to distinguish the roles of the proxy protocol, outer-layer security, and flow control. First make sure the parameters match the core, then check the handshake and actual requests. Only after confirming the connection path can you meaningfully compare Vision's CPU savings or its effect on request time.