VLESS, REALITY and CDN: Three Pieces of the Modern Proxy Puzzle

This article explains the design ideas behind open-source proxy protocols from a technical angle. It is for learning and lawful network research only — please comply with the laws of your jurisdiction.

An overlooked premise: the fight is about “detection”, not “encryption”

Many people assume the key to a proxy is “encrypting the traffic”. But HTTPS already encrypts your content. The real difficulty is this: censorship systems (DPI, deep packet inspection) don’t need to decrypt your content at all — as long as they can recognize that “this is a proxy connection”, they can block it.

So the evolution of proxy protocols over the years has had only one main thread: make your traffic look indistinguishable from normal HTTPS, and ideally defeat active probing too. Grasp this thread, and VLESS, REALITY and CDN all fall into place.

VLESS: a transport protocol built by subtraction

VLESS is the core transport protocol of the Xray (Project X) project — think of it as the “lightweight successor” to the older VMess.

Its most counter-intuitive trait: VLESS itself does not encrypt.

• VMess carried its own encryption and a time-based authentication scheme (alterID). That added overhead, and the encrypted traffic still had statistically detectable “fingerprints”.
• VLESS hands encryption entirely to the transport-layer TLS, and only uses a UUID for identity. The result is lighter, faster, and with fewer features to detect.

The trade-off: VLESS is almost always paired with TLS (VLESS + TLS). With XTLS Vision flow control on top, it even avoids the double-encryption overhead of “TLS inside TLS”.

In one line: VLESS handles “transport”, TLS handles “looking like HTTPS”.

REALITY: borrowing someone else’s storefront

VLESS + TLS sounds perfect, but the TLS layer has a long-standing headache — certificates and domains:

• You need your own domain and certificate;
• The SNI and certificate exposed during the TLS handshake reveal “this server is running a self-hosted service”;
• A censor can run active probing: connect to your port directly, and if the certificate looks suspicious or there’s no real website behind it, flag it as a proxy and block it.

REALITY’s idea is clever: stop using your own certificate, and instead “borrow” the handshake of a real, popular website.

Roughly how it works:

• When the client initiates the handshake, it puts a real, well-known site (e.g. www.microsoft.com) in the SNI;
• A client holding the correct key is recognized by the server and routed through the proxy;
• For an active prober with no key, the server transparently forwards it to that real website — the prober receives Microsoft’s genuine certificate and real page, with nothing out of place.

The payoff: no domain or certificate of your own needed; your TLS fingerprint is that of a real major site; and active probing can’t break through, because what it reaches is the real website.

The key part of the server config looks like this (Xray):

{
  "protocol": "vless",
  "settings": {
    "clients": [{ "id": "your-UUID", "flow": "xtls-rprx-vision" }],
    "decryption": "none"
  },
  "streamSettings": {
    "network": "tcp",
    "security": "reality",
    "realitySettings": {
      "dest": "www.microsoft.com:443",
      "serverNames": ["www.microsoft.com"],
      "privateKey": "server private key",
      "shortIds": [""]
    }
  }
}

dest / serverNames are the “borrowed” target site; privateKey pairs with the client’s public key to complete authentication.

CDN: hiding your origin IP

REALITY solves “traffic fingerprinting” and “active probing”, but one weak spot remains: your server’s IP is exposed via a direct connection. Once that IP is targeted, it can simply be blocked by IP.

A CDN (such as Cloudflare) offers another route:

• The client connects to the CDN’s IP, and the CDN relays traffic back to your server;
• The censor only sees the CDN’s huge pool of shared IPs, which can’t be blocked wholesale (doing so would take down countless legitimate sites);
• Your real origin IP stays hidden behind the CDN.

A CDN setup usually looks like this: VLESS + WebSocket + TLS, because CDNs primarily proxy HTTP / WebSocket traffic.

One crucial realization here: REALITY and CDN are essentially mutually exclusive. A CDN terminates (decrypts) TLS on its side, whereas REALITY requires the genuine TLS handshake to reach your own server untouched. So they are “two different routes”, not something you stack.

How to choose: REALITY vs CDN

Quick rule of thumb:

• Want low latency and strong anti-probing, and don’t mind rotating IPs → choose REALITY;
• Origin IP gets blocked easily, want to hide the server → choose CDN (WS + TLS);
• Advanced users run both and switch depending on the network environment.

Summary

• The core tension of a proxy is not being detected, not encryption;
• VLESS subtracts: it hands encryption to TLS and only does lightweight transport;
• REALITY uses “impersonating a real site’s handshake” to solve the certificate/domain and active-probing problems;
• CDN takes a different angle, hiding your origin behind shared IPs at the cost of latency and privacy.

None of the three replaces the others — each fills in a piece of the puzzle against “detection” and “blocking”.