What is XTLS Vision?

Consider what happens when you load an ordinary HTTPS page through a TLS-based tunnel. Your browser encrypts its request for the site. The tunnel client then encrypts that encrypted data again for transport. The server decrypts the outer layer and forwards the inner one, still encrypted, to its destination.

The outer encryption protected data that was already protected. The cost shows up in two places.

• Processing. Every byte is encrypted twice on the way out and decrypted twice on the way in. On a phone this is battery; on a busy server it is throughput.
• Detectability. TLS records have length headers. Wrapping a stream of TLS records inside another TLS stream produces a characteristic relationship between inner and outer record lengths — a pattern that does not occur in ordinary traffic and that has been used in published research to identify nested TLS with high confidence.

The observation behind XTLS is that the inner data is already properly encrypted by the application. If the tunnel can authenticate the connection and then recognise that what it is carrying is itself TLS, it can forward those records directly rather than wrapping them again.

1. 1

   Authenticate normally

   The session begins as an ordinary TLS connection, with the full handshake and the full protections that implies. Nothing is skipped at this stage.

2. 2

   Detect that the payload is TLS

   Once data flows, the implementation recognises that the inner stream is itself TLS — not arbitrary plaintext that would need the tunnel's own protection.

3. 3

   Pass records through

   From that point the inner records are relayed without a second layer of encryption. They were never readable by the tunnel or by anyone on the path, so nothing is exposed that was not already protected end to end.

4. 4

   Shape the visible pattern

   Vision adds padding to the early part of the session, which is where the nested-TLS length relationship is most pronounced and most useful to a classifier.

The name distinguishes the generations. Earlier XTLS flow modes achieved the pass-through but were found to leave their own detectable characteristics; Vision is the revision that addresses those, chiefly through its padding strategy, and it is the one in current use.

This is the right question to ask, and the answer turns on what the skipped layer was protecting.

Pass-through applies only when the inner payload is already TLS — that is, the application has its own end-to-end encryption to its own destination, which the tunnel could never read in any case. The outer layer was providing confidentiality that the inner layer already provided. Removing a redundant wrapper is not the same as removing protection.

Traffic that is not already encrypted end to end does not qualify for pass-through, and continues to be carried inside the tunnel's own encryption as normal. The distinction is made per connection, not once for the session.

What does change is the metadata visible to an observer on the path: inner record boundaries become the outer record boundaries. That is precisely why the padding exists, and it is a real trade-off rather than a free win — it is the reason Vision replaced the earlier flow modes rather than simply extending them.

• Lower CPU cost at both ends, which shows up as better battery life on mobile and higher capacity per server.
• Higher throughput on connections dominated by HTTPS, which today is nearly all of them.
• Removal of the most-cited length signature for nested TLS, which is the detection-side benefit.
• No configuration burden for the person using it: it is a property of the connection profile, not something to tune.

Vision is usually discussed alongside REALITY because they address different halves of the same problem. REALITY makes the connection's establishment unremarkable; Vision makes what happens afterwards unremarkable. Either alone leaves a gap the other covers.