SNI
SNI, Server Name Indication, is a field in the first TLS message where the client names the site it is reaching for. It exists because of something mundane: hundreds of sites share a single IP address, and the server must know whose certificate to present before encryption is established. The resulting order surprises people: an HTTPS connection begins by sending the site name in the clear. Page content is thoroughly encrypted afterwards, but the fact of reaching that particular domain is visible to anyone on the path. This is not a bug; it follows from certificate selection being impossible to postpone.
In short
The practical takeaway: HTTPS hides what you read, not where you went. ECH, Encrypted Client Hello, closes that by encrypting the first message too, but it works only where both ends support it and DNS is set up accordingly. Protocols such as Reality answer the same question differently: rather than hiding the SNI, they present the genuine name of a third-party site.
Frequently asked
Why send the site name before encryption at all?
So the server knows which certificate to present. Hundreds of domains share one address, each with its own certificate, and the choice has to happen at the very start of the handshake, before a shared key exists. Hence the field in the clear: without it, virtual hosting over HTTPS would not work.
Is ECH usable yet?
In places. The extension needs support in both browser and server, and its parameters are published in DNS — which means encrypted DNS is required too, or the name leaks there instead. Large content delivery networks have switched it on, but that has not changed the overall picture yet.