REALITY and XTLS Vision Explained: Why VLESS Can Be Faster

VLESS, Vision, and REALITY: What’s the Difference?

Node names often list “VLESS + TCP + REALITY + Vision” together, but these aren’t four competing protocols. VLESS defines how proxy requests are authenticated and encapsulated; TCP provides a reliable byte stream; REALITY handles the outer secure connection; and Vision is an Xray flow-control mode that identifies and optimizes eligible inner TLS traffic.

This flow illustrates the roles involved; it doesn’t mean every implementation step happens strictly in sequence. The secure handshake establishes the connection first, after which proxy requests and data can pass through. When you visit an HTTPS site, your browser also establishes its own TLS connection with the site. The outer connection protects traffic between your client and the proxy server; the inner connection protects content between your browser and the destination.

• VLESS: Uses parameters such as a UUID to identify users. It doesn’t provide its own payload encryption layer like VMess, so it’s typically used with TLS or REALITY.
• XTLS Vision: Specified by flow: "xtls-rprx-vision"; it isn’t a transport type you can freely substitute for TCP or WebSocket.
• REALITY: Specified by streamSettings.security: "reality", which is a different security setting from regular "tls".
• Xray: The core implementation that provides these features. A client interface that supports VLESS doesn’t necessarily mean its active core supports REALITY and Vision.

How Vision Reduces Redundant Encryption

Consider browsing an HTTPS site: the site’s TLS encrypts application data before it enters the proxy tunnel. If the outer tunnel also encrypts every byte, data is encrypted twice. This doesn’t necessarily cause noticeable lag, but it adds cryptographic and processing overhead. The cost is more apparent when the server CPU is busy, throughput is high, or device performance is limited.

Vision detects stages in inner TLS traffic and applies the appropriate encapsulation and padding to the initial data. When implementation requirements are met and the traffic reaches an eligible encrypted TLS 1.3 data phase, Vision can switch to an optimized transfer path, reducing redundant outer-layer processing of that already-encrypted payload. Some environments can also use more efficient forwarding mechanisms, depending on the operating system, connection type, and core implementation.

So “VLESS is faster” is shorthand. More precisely, under the same route and resource conditions, a suitable combination of VLESS, Vision, and secure transport may reduce processing overhead compared with a setup involving extra encapsulation or redundant encryption. If the bottleneck is peak-hour congestion, server-side throttling, or packet loss across networks, changing the protocol name is unlikely to make much difference.

REALITY: Handshake and Authentication

REALITY builds a secure connection using TLS 1.3 mechanisms and incorporates specific authentication information into the handshake. The client needs the server’s corresponding public-key information, an allowed server name, and parameters such as shortId. Unlike a conventional TLS deployment, the node administrator doesn’t need to obtain and maintain a publicly trusted certificate for the node’s own domain. The target site and server parameters still need to be configured correctly.

When the server recognizes an eligible client, it establishes a proxy connection. Connections that fail the relevant authentication checks are directed to the configured target site, as designed by REALITY. This target affects the handshake appearance and fallback behavior; it isn’t a regular CDN relay, and it doesn’t mean normal proxy traffic is continually routed through the target site.

shortId is a short identifier in the server’s allowlist, not a UUID or public key. A non-empty value must contain hexadecimal characters, have an even length, and be no more than 16 characters long. The client value must match an entry allowed by the server. Whether an empty value is accepted also depends on the server’s allowlist; don’t clear it at random when troubleshooting.

Map the Concepts to config.json Fields

When troubleshooting, distinguish proxy protocol settings from transport security settings. In a typical Xray VLESS outbound configuration, flow belongs to the user object, while security belongs to streamSettings. Putting these fields at the same level, or setting reality as VLESS encryption, isn’t an equivalent configuration.

The snippets below show where fields go; they aren’t complete node configurations and can’t run on their own. The first shows the flow-control field in a VLESS user object; the second shows the transport security object. A working configuration also needs the server address, port, user credentials, and REALITY authentication parameters.

{
  "encryption": "none",
  "flow": "xtls-rprx-vision"
}

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

• Field names evolve with the core: Older configurations commonly use publicKey for the public key, while newer core documentation and clients may use the name password. Let the client generate a configuration for the core you’re using; don’t assemble one by migrating a tutorial based on field names alone.
• Transport names can also vary by version: Traditional configurations commonly use network: "tcp", while newer ones may show raw. A change in the interface label doesn’t mean you can freely combine it with other transports.
• A fingerprint isn’t a server name: fingerprint controls the client’s handshake fingerprint, while serverName specifies the SNI. Don’t swap these values.
• Never mix up public and private keys: The client uses information corresponding to the server’s public key. Keep the server’s private key on the server; never include it in a share link or screenshot.

To check object nesting, see the configuration reference. If you use a subscription, it’s usually safer to re-import the complete node configuration from your provider and compare it with the effective exported configuration than to edit generated files manually. The client may overwrite those files the next time it starts the core.

Check Settings in v2rayN and Android Clients

On desktop, when using v2rayN, first confirm that the node is running on an Xray core that supports REALITY and Vision. On Android, v2rayNG uses the Xray core, but check that your installed version recognizes the subscription parameters. v2flyNG uses the v2fly core; VLESS support alone doesn’t mean it can run Xray-specific configurations.

1. Check the imported settings. In the v2rayN main window, select the node, right-click it, and choose “Edit.” Check the address, port, UUID, flow, and transport security. Interface labels may vary by version; rely on the exported fields and values.
2. Check transport security. A REALITY node should use security=reality, and a Vision node’s flow should be xtls-rprx-vision. Don’t treat a “TLS” checkbox as a universal substitute for every security mode.
3. Check how traffic is routed. Open the v2rayN tray menu and select “System Proxy” → “Automatically configure system proxy,” then test with a browser that follows the system proxy. In v2rayNG, make sure you’ve granted permission and started the system VPN connection.
4. Check the local port. For example, if the local proxy is set to 127.0.0.1:10808, the app’s port and proxy type must match the actual inbound settings. 10808 is only an example; use the values in your current settings.
5. Keep logs minimal. Test a webpage once and note the time and error message, then change one field at a time. Before sharing logs, redact UUIDs, subscription URLs, and authentication parameters.

How to Measure Whether It’s Faster

A fair protocol comparison requires controlled variables. If you test two nodes from different regions or providers, the results primarily reflect differences in their routes, not Vision’s overhead. Ideally, use the same server, bandwidth limit, and a similar route, changing only the transport being tested. If you can’t control these conditions, call it a “node experience comparison,” not a protocol comparison.

1. Use the same device, network, test target, and time window, and close background downloads. Test each setup three times and record the median.
2. Use the same 100 MiB test file. Record time to first byte and sustained download speed, not just the peak.
3. Monitor CPU usage and outbound bandwidth on the server at the same time. If outbound bandwidth is already saturated while CPU usage is low, reducing encryption overhead is unlikely to increase throughput.
4. Leave time between tests to avoid triggering rate limits on the target site. Then test a frequently used webpage to make sure the large-file results haven’t hidden interactive latency.

For example, downloading a 100 MiB file in 10 seconds averages about 10 MiB/s, or roughly 83.9 Mbps. This is a unit conversion example, not a benchmark from this article. When the client shows MB/s and a speed test shows Mbps, convert to the same units before comparing. Proxy overhead, connection setup, and measurement windows can also affect the results.

REALITY and Vision FAQ