Server name indication (SNI) is a TLS extension in which the client writes the hostname it wants, such as video.example.com, into its first handshake message, the ClientHello. The server reads that name before it responds and returns the matching certificate. This lets one IP address on port 443 terminate TLS for thousands of separate domains, each with its own certificate.
SNI was first specified in RFC 3546 in 2003 and is defined today in RFC 6066, section 3. As of 2026, every mainstream browser, mobile operating system and HTTP client library sends SNI by default, which is why CDNs can serve tens of thousands of customer hostnames from a single Anycast address. Its weakness is that TLS 1.2 and TLS 1.3 both send the SNI field in plaintext, and Encrypted Client Hello (ECH) is the extension built to hide it.
The client puts a server_name extension, of type host_name, into the ClientHello. The server parses that extension before it builds its reply, picks the certificate and TLS settings bound to that hostname, and continues the handshake. The name rides in the first flight, so SNI adds zero round trips and only a few dozen bytes.
SNI is a TLS-layer field, so the server can read it before any HTTP exists on the connection. TCP-mode load balancers depend on this: they can route on SNI without decrypting anything, which is the basis of TLS passthrough.
Before SNI, each certificate needed its own IP address and port pair, because the server had to choose a certificate with only the destination address to go on. Shared TLS hosting at CDN scale was impossible in practice. A short calculation shows the size of the problem.
Take a CDN with 20,000 customer hostnames, each on its own certificate. Without SNI, it needs 20,000 IPv4 addresses, a little over 78 full /24 blocks (20,000 divided by 256), announced from every edge location. At an estimated 30 to 60 dollars per IPv4 address on the 2024 to 2025 transfer market, that is roughly 600,000 to 1.2 million dollars in address space alone (our estimate). With SNI, the same 20,000 hostnames fit behind one address, or a few for redundancy.
The usual pre-SNI workaround was packing about 100 names into one SAN certificate. That still costs 200 addresses, and each reissue touches 100 unrelated customers. SNI removed both the address cost and the shared blast radius. Shared-IP Anycast delivery, where one announced prefix serves every tenant, works because of SNI. The BlazingCDN Anycast CDN includes custom domains and HTTPS certificates on every plan, terminating TLS 1.3 at the edge.
| Handshake | SNI visible on the wire | Certificate visible on the wire |
|---|---|---|
| TLS 1.2 | Yes, cleartext | Yes, cleartext |
| TLS 1.3 | Yes, cleartext | No, encrypted |
| TLS 1.3 with ECH | Only the provider's public name | No, encrypted |
TLS 1.3 alone hides the certificate but not the hostname, so ECH is the only standard way to keep the destination name off the wire.
SNI vs. Host header: SNI picks the certificate at the TLS layer, before encryption begins. The HTTP Host header in HTTP/1.1, or the :authority pseudo-header in HTTP/2 and HTTP/3, picks the virtual host after decryption. The two values can differ. That gap made domain fronting possible, and most large providers now reject requests where the values disagree.
SNI vs. SAN and wildcard certificates: Subject Alternative Names let one certificate cover many hostnames. SNI lets one IP address serve many certificates. They solve different problems, and CDNs combine them. Separate certificates per tenant isolate renewal and revocation, while SANs reduce the number of certificates to manage.
SNI vs. ECH: ECH does not replace SNI, it wraps it. The client sends an outer ClientHello carrying the provider's public name. The real ClientHello, with the true SNI, is encrypted inside it using HPKE (RFC 9180). The client gets the provider's public key from an HTTPS DNS record (RFC 9460).
ECH removes the last plaintext hostname from the TLS handshake. An on-path observer sees only a connection to the provider's shared public name. Firewalls, parental filters and analytics probes that classify traffic by SNI stop working, and they must fall back to IP reputation or DNS visibility. ECH also gives little privacy unless DNS is encrypted, because a cleartext DNS query leaks the same name.
The less obvious effect is that ECH privacy depends on how many hostnames share the public name. A single-tenant origin with ECH still reveals its identity through its IP address. A large multi-tenant edge hides each domain among thousands of others. ECH therefore strengthens the case for shared-IP delivery that SNI started. Operators should also plan for ECH key rotation, publish DNS records with matching TTLs, and support the retry-configs path for clients holding stale keys.
In nginx, each server block declares its server_name together with its own ssl_certificate and ssl_certificate_key directives. nginx matches the incoming SNI against those names. Add a default server block on port 443 with ssl_reject_handshake set to on (available since nginx 1.19.4). Connections with a missing or unknown SNI then fail at the handshake and never receive another tenant's certificate. In HAProxy TCP mode, the req.ssl_sni fetch routes TLS passthrough traffic to backends without decrypting it.
To verify, run openssl s_client against the edge IP with the servername flag set to each hostname, then repeat the run without the flag. Compare the subject and SAN list of each returned certificate. In packet captures, the Wireshark display filter tls.handshake.extensions_server_name shows exactly what a client sent.
SNI lets a CDN edge choose the correct TLS certificate for each customer hostname while every hostname shares the same IP addresses. Without SNI, each certificate would need its own IPv4 address at every edge location. That would make shared Anycast delivery for thousands of tenants far too expensive and would tie certificate renewals together across unrelated customers.
No, SNI is sent in cleartext in both TLS 1.3 and TLS 1.2, because it lives in the unencrypted ClientHello. TLS 1.3 encrypts the server certificate, which removes one leak, but the requested hostname stays readable. Encrypted Client Hello (ECH) is the standard extension that encrypts the real ClientHello, including the true SNI value, behind a provider's public name.
The server returns its default certificate, sends an unrecognized_name alert, or rejects the handshake, depending on its configuration. Browsers always send SNI, so failures usually come from scripts, monitoring probes or embedded clients that connect by IP address. Configuring a rejecting default server prevents those clients from receiving an unrelated tenant's certificate.
No, SNI adds no round trips, because the hostname travels inside the ClientHello the client already sends. The extra payload is a few dozen bytes. Certificate lookup on the server takes microseconds with a hashed name table. ECH adds DNS work to fetch keys and an occasional retry when a client holds stale keys.
Take your ten busiest hostnames and run openssl s_client against each edge IP twice: once with the servername flag and once without it. Record which certificate comes back each time. Any certificate returned without SNI that belongs to a real tenant is a leak to fix with a rejecting default server. Next, query your HTTPS DNS records to check whether ECH keys are published, and check whether any internal firewall rules still match on plaintext SNI, because those rules will stop working as ECH adoption grows. If you deliver large static files over many custom domains, the BlazingCDN features page lists HTTPS certificates, custom domains and TLS 1.3, all included on every plan.