XTLS
XTLS grew out of noticing that in the typical case data gets encrypted twice in a row. Someone opens a site over HTTPS — that stream is already encrypted. It then travels through a tunnel that is itself wrapped in TLS and gets encrypted a second time. There is little point: the content is already unreadable, while the processor pays for both operations, which shows on weak hardware such as a router. XTLS detects that an already-protected stream is passing through and, instead of re-encrypting, forwards it as is while keeping the outer TLS shell for any observer.
In short
The gain shows on low-powered devices and at volume: a router, an older phone, a long download. On a modern computer the difference is barely visible, since encryption there has long been hardware-accelerated and cheap. The limitation is real: the technique applies only when a genuine TLS stream is inside; for unencrypted traffic within the tunnel it does not apply.
Frequently asked
Surely double encryption is safer — why drop it?
It is not safer. Strength comes from the strongest layer, not from how many there are: if the inner TLS cannot be broken, the outer one adds nothing to that fact. It does add CPU cost and latency, so the repeat is dropped wherever inner protection is already guaranteed.
Does XTLS need to be enabled by hand?
Not in client apps. Transport parameters arrive inside the subscription link and the app applies them itself. Manual configuration comes up only when running your own server, where the mode is chosen explicitly.