In the VLESS article I described Reality in two paragraphs: it uses someone else\u2019s certificate, the observer sees a normal site, and it works. That is enough for an overview. It is not enough for understanding, and I realized that from the messages after that article.<\/p>\n
The main question remained unanswered. Fine, the certificate is someone else\u2019s. But where does the server get it, what happens when the visitor is a checker rather than a client, and why can\u2019t you simply put any popular domain into the config and live happily ever after?<\/p>\n
I\u2019ll break down the mechanics in detail. It will get technical and occasionally pedantic, with some TLS fundamentals. There will be no deployment instructions. And a confession: I did not understand all of this on the first try. The key_share part clicked only after I was reading someone else\u2019s config and finally understood why there was an eight-character fragment there.<\/p>\n
The logic \u201cwrap the tunnel in HTTPS and it will look exactly like a site\u201d sounds solid: port 443, encryption, certificate. Dozens of solutions were built on this idea, and one after another they stopped being effective.<\/p>\n
The reason is that TLS is not only encryption. Before encryption starts, the two sides have a detailed conversation, and that conversation is visible. The first message is ClientHello and it is sent in the clear. It contains surprisingly much information: supported protocol versions, the offered cipher suites and their order, supported curves, enabled extensions and their order, plus SNI \u2014 the domain name the client is trying to reach. Different libraries build this message differently. Chrome has one profile, Firefox another, Safari another. Go\u2019s standard library, used by a huge amount of network software, has yet another profile and does not look much like a browser.<\/p>\n
This is the TLS fingerprint: not one field, but the combined snapshot of how a client constructed its first message. Comparing these fingerprints is not new; methods such as JA3 and JA4 are well established.<\/p>\n
A simple analogy, but I cannot think of a more accurate one: handwriting. The text is the same, the letters are the same, but the hand is different.<\/p>\n
[Image: ClientHello packet broken down by fields \u2014 version, cipher suites, extensions and SNI, with the fingerprint-forming fields highlighted]<\/p>\n
This is where older solutions fell apart. The connection goes to port 443 and looks like HTTPS, but its fingerprint does not match any browser people actually use. Very few people browse the web through a custom Go client. So it is probably not a browser \u2014 it is a tunnel. Add a second layer of clues: TLS inside TLS, where the browser has already encrypted the request and the tunnel encrypts it again. That creates characteristic packet sizes and timings. XTLS-Vision addresses that layer, but it does not magically erase the fingerprint of the initial handshake.<\/p>\n
It is important to separate two mechanisms that are constantly mixed together. I confused them myself for months until I drew the distinction on paper.<\/p>\n
Passive analysis.<\/strong> The system sits on the traffic path and observes. It compares the fingerprint with browser profiles, evaluates packet sizes, traffic rhythm and session duration. It does nothing to the connection \u2014 it watches and accumulates evidence.<\/p>\n Active probing.<\/strong> This is fundamentally different. After suspecting a connection, the system connects to the same address and port, pretends to be a client, sends its own handshake and sometimes repeats the kind of handshake it observed. It then checks the response. It is like a mystery shopper: you can put up any sign you like, but someone walks in, asks for the product and finds out whether the shop is real.<\/p>\n As far as I understand the authors\u2019 reasoning, it was simple: if a fake is always worse than the original, stop making fakes. Let\u2019s go step by step.<\/p>\n Step one.<\/strong> The client creates ClientHello not in its own fingerprint, but as an exact copy of a real browser\u2019s fingerprint. The uTLS library handles this by reproducing Chrome, Firefox and Safari profiles down to extension order and GREASE values. In the config this is the Step two.<\/strong> In SNI, the client writes the domain of a third-party cover site rather than the address of your server. To an observer, the connection looks like a connection to that site.<\/p>\n Step three<\/strong> is the cleverest part. ClientHello contains the And finally, step four.<\/strong> The server verifies the marker with its private key. From there, the connection branches, and that branch determines everything.<\/p>\n [Image: simplified Reality handshake \u2014 two branches for a legitimate client and a probe, showing what happens in each case]<\/p>\n If the marker is valid<\/strong>, it is a legitimate client. The server connects to the cover site, obtains the real certificate chain and sends it to the client, while the CertificateVerify signature is replaced with its own signature. The client, which has the If the marker is missing or invalid<\/strong> \u2014 exactly what happens during probing or when an ordinary browser connects \u2014 the server transparently proxies the connection to the cover site, including the handshake. The checker receives the real site with a valid certificate because it really is the real site. It simply reached it through your server without knowing that.<\/p>\n This is also where the resilience comes from. There is little to probe: the address really serves what it is expected to serve. Think of a shop with a genuine storefront and real products. A passer-by or an inspector enters and sees a real shop; legitimate customers have a private entrance opened by a particular knock. The analogy is imperfect, but it conveys the branch.<\/p>\n This is one of the most underestimated parts. Guides often reduce it to \u201center any popular domain.\u201d That is bad advice; there are quite a few requirements.<\/p>\n Technical.<\/strong> The site must support TLS 1.3 \u2014 the scheme depends on it \u2014 and X25519. HTTP\/2 is preferable. It should not require client certificates.<\/p>\n Geography.<\/strong> The domain should make sense relative to your server address. A server in the Netherlands using a cover site primarily served from Australia creates a strange mismatch: the name points one way, the IP address another.<\/p>\n Popularity.<\/strong> It should be a site people actually visit. A connection to a domain nobody in the target country has heard of can itself be anomalous, especially if many long-lived connections originate from the same server.<\/p>\n Reachability.<\/strong> This sounds obvious, but it is often forgotten. If the cover domain is blocked, the tunnel can fail with it even though your server itself is healthy.<\/p>\n Stability.<\/strong> The resource should not constantly move between hosting providers.<\/p>\n There is another point that guides rarely mention and that surprised me when I first encountered it. Do not blindly take a domain from the first GitHub guide you find. If thousands of servers use the same name, the same SNI can appear unusually often and become a statistical anomaly. Ideally the cover is chosen for the server\u2019s location and reviewed periodically. That is part of operating the infrastructure, not a one-time setting. For a single server it is manageable manually; for a larger setup it belongs in monitoring<\/a>.<\/p>\n From the observer\u2019s side the picture is boring \u2014 or rather, indistinguishable, which is the whole point. It sees a connection to port 443 at an unremarkable address, a ClientHello with a browser fingerprint, the SNI of a known domain and an encrypted stream. It does not see a tunnel signature in the handshake or the obvious TLS-in-TLS pattern. If it actively probes the address, it receives a working site.<\/p>\nReality\u2019s idea: do not imitate a site \u2014 use a real one<\/h2>\n
fp<\/code> parameter. The fingerprint is not browser-like; it is an actual browser profile.<\/p>\nkey_share<\/code> extension, where the client sends an X25519 public key. Reality uses it as a container: a marker derived from the server public key (the pbk<\/code> in the config) and a short sid<\/code> identifier is embedded there. From the outside these are just random-looking bytes, of which every handshake contains plenty. No extra fields or packets appear.<\/p>\npbk<\/code> in its config, verifies that signature. If it matches, the other end really is our server; if not, the client closes the connection like a browser that rejected a certificate.<\/p>\nHow the cover site is chosen \u2014 and why it matters<\/h2>\n
What DPI ultimately sees<\/h2>\n