This guide is for Mac and Android users who have imported a VLESS subscription but aren’t sure how REALITY differs from the flow setting. We’ll break down the three layers—application TLS, proxy transport, and VLESS—then explain when Vision can reduce redundant encryption and walk through field checks and troubleshooting in v2rayN and v2rayNG. Performance gains depend on traffic and the runtime environment; changing the flow label alone won’t make a connection faster.
TLS Handshakes and Proxy Tunnels: Where Encryption Is Repeated
When you visit an HTTPS site, your browser first negotiates TLS with the destination. During the handshake, they agree on protocol settings, verify the site’s identity, and establish session keys. The TLS record layer then encrypts HTTP requests and responses. Even when traffic passes through a proxy, this TLS connection generally remains end to end between the browser and the website.
If the proxy client also creates a TLS tunnel to the proxy server, the browser’s TLS-encrypted data becomes payload inside that outer tunnel. The client encrypts already-encrypted data again; the server removes the outer layer, then forwards the inner ciphertext to the website. This is often called TLS over TLS, but the two layers protect different connections.
Repeated encryption adds cryptographic work, record-layer overhead, and memory copying. But it isn’t necessarily the main reason a connection feels slow. A page’s first load is also affected by DNS lookups, cross-network round-trip time, packet loss, and server queues. Vision optimizes a specific data path; it can’t remove all of these costs.
- Inner TLS: Encryption between the browser and destination website. The proxy server generally doesn’t have the website’s session keys.
- Outer secure transport: Protection between the client and proxy entry point. REALITY handles the handshake and authentication on this leg.
- VLESS: Carries information such as user identity and destination address in a proxy request; it isn’t an encryption algorithm for application data.
REALITY: Real-Site Certificates and Client Authentication
REALITY is a transport security mechanism in Xray. A typical configuration specifies a real TLS destination and selects a server name and handshake characteristics compatible with it. REALITY uses the destination’s real handshake material and certificate appearance so the entry point behaves much like a normal TLS service, while providing a dedicated authentication path for preconfigured clients.
“Borrowing a certificate” doesn’t mean downloading a certificate and impersonating any website, nor does it give the proxy server the destination’s private key. In addition to handling the TLS handshake, a REALITY client uses preconfigured information such as a public key to verify the corresponding REALITY server. A real-site certificate is not a substitute for the public key configured by the user.
| Concept | What it does | Common misconception |
|---|---|---|
| Destination site | Provides a target for REALITY’s handshake behavior and must meet the requirements of the implementation in use | It isn’t the final website for every request forwarded through the proxy |
| serverName / SNI | Specifies the server name in the handshake; it must match the server configuration | It isn’t the connection address; don’t enter an arbitrary popular domain |
| Public key / pbk | Corresponds to the server’s private key and is used during REALITY authentication | It isn’t the website certificate itself or the VLESS user ID |
| shortId / sid | Helps identify REALITY clients and must match a value allowed by the server | It isn’t an abbreviation for the VLESS user ID |
Depending on the REALITY configuration and implementation, unauthenticated connections may be routed to the destination site. That doesn’t mean every probe receives exactly the same response. The outcome depends on whether the destination is reachable, whether its TLS behavior is compatible, and on the characteristics of the entry point and network path. If the destination is wrong, changing the client fingerprint alone usually won’t fix the problem.
XTLS Vision: When It Can Reduce Encryption Overhead
Vision is commonly configured with the flow value xtls-rprx-vision. It’s more than a configuration label: it includes behavior for identifying and padding early connection data, as well as deciding how to forward subsequent traffic. Both ends must support and correctly configure this behavior; changing the client field alone can make the connection fail.
For inner TLS 1.3 traffic that Vision can identify and that meets its requirements, Vision can switch data handling after the handshake. Application data already protected by inner TLS can then avoid being encrypted again by the outer TLS record layer. The destination website’s TLS connection remains in place, and the browser still verifies its certificate; what’s reduced is redundant processing of that ciphertext by the proxy layer.
- Establish the outer connection: The client first sets up a secure connection to the proxy server and authenticates; REALITY parameters still need to be checked.
- Send the proxy request: VLESS carries user credentials and destination details, while Vision handles early data and inspects inner-protocol characteristics.
- Check eligibility: Only TLS traffic that is recognized and meets the requirements may use the path with reduced outer-layer encryption.
- Forward subsequent data: Inner TLS ciphertext continues through the connection. Traffic that doesn’t meet the requirements isn’t sent as “plain text.”
Ordinary HTTP, unrecognized traffic, UDP, and QUIC over UDP don’t fit the explanation “TLS 1.3 ciphertext passes through directly.” TLS 1.2 traffic shouldn’t be assumed to get the same optimization either. Whether the efficient path is used also depends on the actual core implementation, transport combination, and operating system.
Verify the Core and Flow Before Testing Speed
In the client’s node editor, check VLESS, REALITY, and xtls-rprx-vision, then review the runtime log to confirm that the active core supports this combination. The node’s display name alone can’t tell you whether Vision is working.
Protocol Numbers: TLS Versions, Port 443, and Performance Limits
These figures describe protocol details and common deployment settings; they aren’t benchmark results from this article. They help distinguish the connection entry point from how data is handled, but they can’t predict the speed of a particular subscription node.
When a large file transfer maxes out the client or server CPU, reducing redundant encryption may lower CPU usage and increase available throughput. Some environments can also use more efficient data-copying techniques. However, Mac desktop clients and servers don’t have identical system capabilities; zero-copy behavior on one platform doesn’t necessarily apply to every device.
Latency improvements are also conditional. Under heavy load, less processing may reduce queueing time. For a small request on an idle connection, network round-trip time is often still the main factor. Vision isn’t a compression algorithm, and it can’t shorten the physical distance between the proxy server and the destination website.
- When comparing CPU usage, monitor both the client and server. A drop on your Mac may simply mean the server has become the bottleneck.
- To compare throughput, keep the entry point, destination resource, routing rules, and number of concurrent connections the same. Run each test at least three times and save the results.
- When comparing page latency, distinguish first connections from reused connections. DNS caching and connection reuse can significantly affect the results.
- Don’t simply remove the flow setting for a supposed control test. The server must provide a matching configuration for each test; otherwise, you’re comparing a working connection with a misconfigured one.
v2rayN and v2rayNG: Check Settings After Importing a Subscription
On desktop, import the subscription in v2rayN and update the group, then open the relevant node’s editor and check its fields. On Android, v2rayNG uses the Xray core and lets you inspect the same configuration concepts. v2flyNG uses the v2fly core; support for some VLESS links doesn’t mean it supports Xray’s REALITY and Vision combination.
Editor layouts, translations, and underlying field names can vary between versions. The checks below are based on what each setting means, not on a specific version’s menu labels. In share links, pbk commonly refers to the REALITY public key; the interface may use a different label, so follow the requirements of the core you’re using.
| Setting | Expected value | What to do if it’s wrong |
|---|---|---|
| Protocol and transport | VLESS; in newer interfaces, traditional TCP may also be labeled RAW | Restore the value from the subscription; don’t switch to a different transport arbitrarily |
| Secure transport | security=reality | Check that it wasn’t mistakenly imported as regular TLS |
| Flow control | flow=xtls-rprx-vision | Compare with the server configuration; don’t infer the value from the node name |
| Address and port | The entry address and port provided by the service provider | The entry point may use port 443 or another port |
| User ID, SNI, public key, shortId | Match each value to the server configuration | Update the subscription; if entering values manually, check for spaces and missing characters |
| Client fingerprint | Use a fingerprint supported by the current core and required by the node | Don’t paste a full browser version string into the fingerprint field |
Share links commonly include encryption=none as well. This describes the VLESS protocol layer; it doesn’t mean the entire connection is unencrypted. REALITY provides secure outer transport, and HTTPS traffic also has inner TLS. Don’t change the value to something the protocol doesn’t support just to make the field look “more secure.”
Handshake Failures or Connected but Can’t Browse? Troubleshoot by Symptom
Start by separating troubleshooting into three stages: can the entry point be reached over TCP, did REALITY authentication succeed, and is application traffic going through the proxy? Change one setting at a time and note the corresponding log entry. Changing the SNI, port, flow, and fingerprint all at once makes the cause harder to pinpoint.
The import succeeded, but why does the handshake fail as soon as I connect?
First enable automatic system time synchronization, then check the entry address, SNI, public key, and shortId. REALITY’s time checks can cause authentication to fail when the system clock is significantly off. If the entry point is reachable and all fields match, ask the server administrator to check destination-site connectivity and handshake requirements. Don’t disable certificate verification as a first step.
The log says the flow isn’t supported. Can I remove it?
First confirm that the active core is an Xray version with Vision support, then check the startup log for configuration parsing errors. The client and server settings must match; removing xtls-rprx-vision isn’t a universal fix. After updating the client, restart the core and test again with the original subscription settings.
The node test passes, but websites still won’t load in my Mac browser. What should I check?
Check whether v2rayN has enabled the system proxy. Then, in macOS, go to “System Settings” → “Network” → your current network service → “Details” → “Proxies” and verify the actual address and port. The system proxy affects only apps that honor it; command-line tools may need separate configuration. Use the port currently set in the client.
TUN is enabled but the connection is still slow. Will switching to Vision help?
First, test the same node with TUN off and only the system proxy enabled. This helps rule out conflicts with virtual network adapter routing, DNS, and other network tools. TUN controls how traffic enters the client; Vision controls how some outbound data is handled. Also check whether routing rules are sending the destination traffic direct.
If the log shows a TCP connection timeout, start with the network path, entry-point listener, or firewall. If authentication succeeds but only one website has a problem, check that site’s DNS results, outbound connectivity, and routing rules. Don’t blame every connection error on REALITY, and don’t mask field errors by repeatedly switching global modes.
Recommended Order: Match the Configuration Before Comparing Performance
First get one node, one connection mode, and one HTTPS destination working reliably, then test system proxy and TUN separately. CPU and latency changes are meaningful only when the connection path is clear.