As of 2026, VLESS remains a lightweight, stateless proxy protocol, but “VLESS has no encryption” is no longer a complete description. Xray-core now offers optional VLESS Encryption. Deployments may also combine VLESS with TLS, REALITY, XTLS Vision, XHTTP, and XUDP according to their threat model. These layers solve different problems and should not be collapsed into one protocol.
Evidence policy: This guide uses primary Project X, Xray-core, sing-box, and AnyTLS sources. GitHub pull requests and discussions document maintainer design and implementation; they are not independent security audits. References to SingLink are architectural comparisons, not claims that SingLinkVPN implements these projects.
1. The modern VLESS stack at a glance
VLESS: a lightweight identity, command, and destination layer.
VLESS Encryption: an optional native payload-protection layer in current Xray-core.
TLS 1.3 / REALITY: outer transport security, authentication, and network appearance.
XTLS Vision: flow control and data-path optimization, not a separate cipher.
RAW / XHTTP / gRPC / WebSocket: transports that carry proxy data.
XUDP: a UDP packet-encoding option in the Xray ecosystem.
XMUX and other MUX systems: ways to share underlying connections.
Padding / FinalMask / Browser Dialer: tools for length, timing, outer transport behavior, or browser networking.
A connection can therefore be modeled as application traffic → VLESS identity and destination → protocol or outer security → Vision flow control → a transport such as RAW or XHTTP → TCP or UDP. Not every module is needed or compatible in every design.
2. What the VLESS base protocol does
Project X documentation defines VLESS as a lightweight, stateless transport protocol that does not depend on system time and uses a UUID or mapped ID for authentication. The public Xray-core encoding implementation shows version, user ID, addons, command, destination port, address, and following data.
In practical terms, the base layer answers: Who is the client, what connection is requested, and where should it go? Smart routing, node load, plan entitlements, and automatic reconnection normally belong to higher product and control layers.
Traditional configurations commonly use `encryption: "none"`. Current Project X guidance requires outer transport security unless the peer and link are trusted private infrastructure, or VLESS Encryption is enabled.
3. What VLESS Encryption changes
VLESS Encryption is an optional native protection layer merged into Xray-core in 2025. The merged PR #5067 and current configuration documentation describe the `mlkem768x25519plus` handshake, `native`, `xorpub`, and `random` appearances, `1rtt` and `0rtt` session behavior, and variable padding.
Published design goals
Derive session keys through an ML-KEM-768 and X25519 combination;
protect VLESS payloads without requiring outer TLS;
use tickets for later 0-RTT resumption and short-lived state to reduce replay risk;
use variable padding and optional XOR modes to alter fixed-length or public-key appearances.
These are maintainer design and implementation claims. We did not find an independent cryptographic audit covering every property, so this guide does not call the design “replay-proof” or “absolutely quantum-safe.”
What it does not automatically replace
VLESS Encryption protects the protocol payload. It does not automatically create an ordinary HTTPS certificate chain, website handshake, HTTP/2 or HTTP/3 behavior, or CDN compatibility. It is therefore not equivalent to TLS or REALITY.
4. TLS 1.3 and REALITY
TLS provides standardized certificate validation, key exchange, integrity, and transport encryption. It can accompany RAW, XHTTP, gRPC, or WebSocket; the negotiated version, ALPN, and certificate checks still depend on configuration and peer support.
Project X REALITY documentation describes a modified TLS-style security layer with target, serverNames, X25519 keys, and shortId settings, plus optional ML-DSA-65 verification data. REALITY can accompany RAW, XHTTP, and gRPC.
REALITY should not be reduced to “TLS without a certificate.” Its behavior combines client authorization with an external handshake appearance. Results still depend on the target, client fingerprint, transport, and deployment quality; it cannot guarantee invisibility to every classifier.
5. XTLS Vision is not an encryption protocol
The VLESS/Vision documentation classifies Vision as flow control. Under supported conditions it can recognize inner TLS traffic and reduce extra encryption or copying. On compatible Linux and TCP paths, the core may attempt `splice` so the kernel transfers data directly.
The accurate division is: TLS, REALITY, or VLESS Encryption supplies security; Vision optimizes how protected data travels through the proxy layer. Not every platform, transport, or traffic type can use splice.
6. The three XHTTP modes
The maintainer XHTTP design discussion describes an HTTP transport system that can operate in HTTP/1.1, HTTP/2, and HTTP/3 environments:
packet-up: multiple upstream POST requests with a continuing downstream response; designed for broad intermediary compatibility.
stream-up: a streaming upstream POST and a separate streaming downstream GET.
stream-one: one bidirectional streaming request; performance and compatibility depend on intermediaries.
XHTTP can also use header padding, split upload/download paths, and XMUX. Whether it works through a specific CDN depends on the mode, HTTP version, reverse-proxy behavior, and provider configuration.
7. XMUX, general multiplexing, and head-of-line blocking
XMUX manages XHTTP concurrency, underlying connection counts, reuse, lifetime, and keepalive. Its goal is not to hold exactly one connection forever; it balances handshake cost, concurrency, and long-lived connection patterns.
sing-box multiplex documentation also lists smux, yamux, and h2mux. Multiplexing can reduce handshakes, but loss or blocking on an underlying TCP connection may affect several streams. HTTP/3 avoids TCP-level cross-stream head-of-line blocking, while an individual QUIC stream can still wait on loss recovery.
8. XUDP is a UDP encoding option
sing-box VLESS documentation lists `xudp` as a packet-encoding option, alongside `packetaddr` and disabling additional encoding. This supports the limited conclusion that XUDP carries UDP in this ecosystem; it is not a complete, versioned packet specification.
Detailed session, address, boundary, and migration behavior should be verified against the exact core version and code. This guide deliberately avoids presenting inferred framing details as a universal standard.
9. Padding, FinalMask, ECH, and Browser Dialer
Padding: changes length or timing characteristics; it is not encryption.
FinalMask: its configuration documentation places it at an outer transport-processing stage with TCP, UDP, and QUIC-related settings.
ECH: sing-box TLS documentation includes Encrypted ClientHello configuration for protecting part of the ClientHello; ECH does not replace tunnel encryption.
Browser Dialer: Project X documentation lets a real browser establish TLS and HTTP connections, gaining more authentic browser behavior at the cost of deployment and performance constraints.
10. What Fallback can and cannot do
Project X Fallback documentation shows how unmatched SNI, paths, or protocol traffic can be forwarded to Nginx, Caddy, or a normal website, allowing one entry point to host proxy and ordinary services.
Fallback can avoid responding to every failed authentication attempt with one obvious error. It is not immunity from active probing; recognizability still depends on TLS, transport, responses, timing, and server configuration.
11. AnyTLS is a comparison, not a VLESS component
The AnyTLS protocol document describes TCP → TLS → `SHA-256(password)` authentication → a session → multiple streams. Frames contain Command, Stream ID, Data Length, and Data, with SYN, PSH, FIN, settings, padding, heartbeat, and version 2 SYNACK commands.
Its session model, multiple streams, dynamic padding, and health checks make a useful comparison. AnyTLS remains a separate protocol; VLESS does not automatically inherit these features.
12. Common combinations and their limits
VLESS + REALITY + Vision + RAW: oriented toward direct performance and a TLS-style outer appearance; no CDN dependency.
VLESS + TLS/REALITY + XHTTP: oriented toward HTTP carriage, reverse proxies, and conditional CDN compatibility.
VLESS Encryption + Vision: protects the protocol payload for relay or nonstandard outer-security scenarios, without an ordinary HTTPS appearance.
VLESS + TLS + XHTTP + Browser Dialer: uses a real browser network stack with higher operational cost.
AnyTLS + TLS: a separate session/stream and padding design, not a VLESS stack.
No configuration is always best for performance, compatibility, maintainability, appearance, and security at once. Selection should begin with a threat model, network path, CDN or proxy constraints, client platforms, and observability requirements.
13. What this means for SingLink research
Public VLESS and AnyTLS materials can inform research into identity, key exchange, sessions, streams, UDP, padding, multiplexing, recovery, and version negotiation. This article does not establish that SingLink 2.0 is based on VLESS, REALITY, XHTTP, or AnyTLS.
SingLinkVPN should continue separating published behavior, research directions, and undisclosed implementation. See the SingLinkVPN open-source plan for the currently published scope.
14. Frequently asked questions
Does VLESS encrypt traffic by itself?
Traditional `encryption: "none"` does not protect the protocol payload and requires trusted private infrastructure or outer security. Current Xray-core can enable VLESS Encryption, so the answer depends on implementation and configuration.
Can VLESS Encryption replace TLS or REALITY?
Not as an equivalent. It protects VLESS payloads but does not automatically provide a standard HTTPS certificate, handshake, or website appearance.
Does XTLS Vision perform encryption?
No. Vision primarily provides flow control and data-path optimization.
How should the three XHTTP modes be selected?
packet-up emphasizes compatibility, stream-up separates streaming directions, and stream-one uses one bidirectional stream. Each must be tested with the actual intermediary path.
How is XUDP different from a generic UDP proxy?
XUDP is a UDP encoding option in the Xray ecosystem. Exact behavior depends on core and version and should not be inferred from the name alone.
Is SingLink 2.0 based on VLESS or AnyTLS?
There is not enough public evidence to establish that relationship. This article is a technical comparison, not an implementation disclosure.
15. Conclusion and source date
Modern VLESS is a composable stack: VLESS carries identity and destination, VLESS Encryption adds optional protocol-layer protection, TLS or REALITY supplies outer security, Vision optimizes flow, XHTTP and XUDP carry traffic, and multiplexing or padding further changes connection behavior.
Original publication date: May 20, 2026. Technical sources reviewed: July 28, 2026. These projects continue to change; verify the documentation, changelog, and compatibility of the exact version before deployment.