REALITY handles proxy connection handshakes and authentication, while XTLS Vision identifies and optimizes traffic inside the tunnel. They can be used together, but they are not the same feature. Starting with how VLESS, TLS, and the transport layer fit together, this guide explains the limits of certificate-free setups, when redundant encryption can be reduced, and which fields to check in v2rayN and v2rayNG. For readers who have imported a subscription and want to troubleshoot a connection or compare configurations.
How VLESS, REALITY, and Vision fit together
The short version: “VLESS + TCP + REALITY + Vision” is a combination of components at different layers, not four interchangeable protocol names. VLESS defines the proxy request format and user authentication data; TCP carries the connection; REALITY establishes an authenticated secure connection; and Vision is an Xray flow-control mode designed to work with specific transport combinations.
VLESS does not encrypt payloads on its own. So if a client shows none as the VLESS encryption setting, that does not mean data travels unencrypted over the network. Check whether the outer layer uses REALITY or TLS, and whether the application itself uses HTTPS. VMess works differently, so you cannot simply copy VLESS fields into a VMess configuration.
| Component or field | Purpose | What to check |
|---|---|---|
| VLESS | Specifies the proxy destination and user identity. | The user ID matches the server. |
| TCP | Provides a reliable, ordered byte stream. | The address, port, and transport match. |
| REALITY | Handles the secure handshake and peer authentication. | Server public key, serverName, and shortId. |
| xtls-rprx-vision | Identifies inner traffic and optimizes forwarding for eligible data. | Flow-control settings and transport are compatible on both ends. |
REALITY handshakes without self-signed certificates
“Without self-signed certificates” means the proxy server typically does not need to obtain and renew a certificate for its own proxy domain as in a traditional TLS deployment, and users do not need to manually trust a self-signed certificate. It does not mean authentication is skipped or certificate-related checks can be disabled. REALITY uses its own authentication design, and clients must have the correct server public key and other parameters.
The server is configured with a real TLS site as the handshake target. REALITY uses handshake behavior associated with that site to make the connection resemble a normal TLS service as closely as possible. Clients with valid authentication details are routed to the proxy; connections that fail authentication may be forwarded to the target site, depending on the implementation and configuration, but are not granted proxy access. “Using a real site's handshake” is a shorthand description, not a claim that the site's private key is copied.
Two addresses are easy to confuse: the client connects to the proxy server's address, while serverName is the name used in the handshake and must be allowed by the server. Changing it to a familiar website domain at random will not make the connection work. The real target site is not a substitute for the proxy server: authenticated proxy traffic is generally handled by the proxy server, which connects to the destination service. The target site does not relay arbitrary traffic.
Vision flow control and redundant encryption
When you open an HTTPS site, your browser establishes a TLS connection to that site. If the encrypted traffic then passes through another TLS-like proxy tunnel, the result is encrypted data wrapped in another layer of encryption. Extra record framing, buffering, and encryption or decryption can consume CPU and may create observable patterns of nested traffic.
Vision detects TLS handshakes and data phases inside the tunnel, using measures such as padding during the initial stage. For eligible inner TLS 1.3 traffic, it can switch to an optimized path, such as direct copying, to reduce redundant processing by the outer layer. It does not make every connection plaintext or decrypt HTTPS between the browser and website. End-to-end TLS for the application connection remains in place.
- Eligible HTTPS traffic: May use a path that reduces redundant encryption. Actual results depend on the core version, platform, and connection type.
- Regular plaintext traffic: The assumption that “HTTPS already provides protection” does not apply; it still needs protection from the outer security layer.
- UDP and other traffic: The optimization claims for inner TLS over TCP do not apply automatically. Check UDP support and forwarding separately.
- Combinations such as WebSocket: Adding a Vision field to an existing node is not enough to ensure it works. Check that the core supports the full combination.
That is why “Vision reduces redundant encryption” is more accurate than “Vision does not encrypt.” Not every connection or byte follows the same optimized path. Setting the correct flow-control mode is only a prerequisite for enabling the relevant mechanism, not a guarantee of higher bandwidth.
Key values and client fields
These values help explain the protocol and check a configuration; they are not benchmark results. Port 443 is common, but REALITY does not require it. If the server listens on another port, the client must use that port too. Enter shortId in hexadecimal, within the core's length requirements and matching a value allowed by the server.
In classic Xray REALITY configurations, shortId can be up to 8 bytes, or 16 hexadecimal characters, and the character count should be even. Whether an empty value is allowed depends on the server settings; do not remove a value from your subscription just because the client interface lets you leave the field blank. The public key field may appear under a different name, such as Public key, as client interfaces and cores evolve. Check the subscription format and current core documentation.
VLESS + REALITY + Vision
- Transport
- TCP, labeled RAW in some interfaces
- Security layer
- REALITY
- Flow
- xtls-rprx-vision
- Authentication parameters
- User ID, public key, shortId
- Handshake name
- Must match a value allowed by the server
This is an example of a common combination, not a ready-to-use node configuration.
VLESS + TLS + Vision
- Transport
- TCP, labeled RAW in some interfaces
- Security layer
- TLS
- Flow
- xtls-rprx-vision
- Certificates
- Requires a valid certificate and chain of trust
- Handshake name
- Must match the certificate domain
Vision does not require REALITY; traditional TLS combinations also need support on both ends.
In v2rayN, first make sure the selected node uses an Xray core that supports this combination, then edit the relevant VLESS server settings. v2rayNG also uses the Xray core and requires all the node fields. v2flyNG uses the V2Fly core; the fact that its interface can import VLESS does not mean it supports Xray's REALITY and Vision. Client version, core capabilities, and subscription parsing are three separate things to check.
Limits on speed, latency, and stability
REALITY does not shorten the physical distance between endpoints, and Vision cannot add bandwidth to a server. If the bottleneck is peak-hour congestion, an inter-region route, or limited server egress, reducing some encryption overhead may make little noticeable difference. Vision's resource savings are more likely to show when CPU usage is near saturation and the workload consists mainly of eligible, long-lived HTTPS connections.
- Keep comparisons consistent: Use the same device, network, test file, and roughly the same time of day. Compare protocols only if the server actually provides two configurations that can be fairly compared.
- Separate the metrics: Connection latency, webpage time to first byte, and sustained download throughput are different measures. Record how each test was run; do not treat a single latency reading in the client as overall performance.
- Track local resource use: Monitor CPU usage and client logs during testing. Avoid attributing changes caused by device heat and throttling or background downloads to the protocol.
- Repeat each test: Run each configuration at least 3 times and record failures and timeouts. Picking only the fastest run can be misleading.
How to choose: identify the bottleneck before comparing flow control
If the logs show that the connection is established and CPU has headroom, check packet loss, server load, and egress bandwidth before repeatedly changing Vision settings. Attribute a difference to the configuration only after it appears consistently under comparable conditions.
Stability also depends on whether the server can reach the handshake target, the target site's TLS behavior, system time, and compatibility between the implementations at both ends. REALITY can change how a connection appears, but cannot guarantee continuous availability on every network. Choosing a target site is server-side operations work; subscription users should not try to “fix the route” by changing serverName locally.
Troubleshooting connections and common questions
Start troubleshooting with the easiest fields to verify: address and port, user ID, transport, security layer, flow control, public key, shortId, and handshake name. Then check routing and DNS. Change one setting at a time and retry, keeping the original subscription configuration for comparison. Before sharing logs, remove subscription links, user IDs, and sensitive server details.
Why does the connection time out after a successful import?
A successful import only means the client could parse the text. First check the server address and actual listening port. For example, if the node specifies 443, do not change it to 8443 on your own. Then check the core logs. A timeout usually calls for checking network reachability, firewalls, and the server listener first; it does not, by itself, prove the public key is wrong.
Should I disable verification if the handshake fails?
Do not treat skipping verification as a general fix. First sync the device clock, then check the public key, shortId, and serverName one at a time. If you use a subscription, update it and select the original node again for testing. If REALITY authentication parameters are wrong, you need the correct values; disabling checks will not restore the correct identity match.
Why do some apps fail even though the node connects?
First check whether the app's traffic is actually going through the client. Desktop apps may ignore the system proxy, so check the app's own proxy settings or follow a guide to configure TUN mode. Then check whether routing rules send the destination directly and whether DNS resolves correctly. Do not start by changing the REALITY public key.
Should I switch nodes if enabling Vision does not make things faster?
Download the same HTTPS file 3 times and monitor CPU usage and error logs. If throughput is similar and the connection is stable, you can keep using it. Flow-control changes will not help if egress bandwidth remains the bottleneck; compare other available routes at the same time of day instead of stacking on more transport options.
Can I convert an existing VMess node to REALITY?
You cannot do it by changing the protocol name in the client alone. The server must provide matching VLESS, REALITY, and flow-control settings, along with the required authentication parameters. Get a complete new node or subscription and import it into v2rayN or v2rayNG. Keep the old node so you can compare and roll back if needed.
Choosing a configuration and getting started
If you already have a working subscription, keep the combination provided by the server. Do not judge a node only by whether its name includes REALITY or Vision. Check that your client supports the full configuration, the connection is stable, your usual apps work, and the route meets your needs.
- Check the core first: Choose REALITY and Vision based on Xray support. Names from the Project V, V2Fly, and Xray families do not guarantee full compatibility.
- Then import the complete settings: Use a trusted subscription and avoid mixing the public key, user ID, or handshake name from different nodes.
- Finally, test your traffic path: Start with a single HTTPS site, then check the system proxy, TUN, DNS, and routing rules.
For help with rule order, see Advanced Configuration. For subscription imports and basic connection steps, see the subscription section of Getting Started. Establish a baseline you can reproduce, then change one setting at a time. This usually makes problems easier to isolate than changing several protocol fields at once.