What Is SNI? How Server Name Indication Works and How to Test It

Server Name Indication (SNI) is a field in the first message of a TLS handshake where the client states the hostname it wants to reach. It lets a server that hosts many HTTPS sites on one IP address choose the right certificate before any web request is sent. When the name is missing, or the server does not recognize it, the result is a certificate for a different site, a name-mismatch warning in the browser, or a failed handshake. An SNI check sends a chosen name to a server and shows which certificate comes back.

Test what a server returns for a name Send a hostname as the SNI and see the handshake result, the certificate, and the HTTP status. Optionally connect to a specific IP address.

What is SNI?

SNI is a TLS extension. The client puts the hostname in the ClientHello, the first message of the handshake, in a field called server_name. The extension was first specified in RFC 3546 in 2003 and is now defined in RFC 6066, section 3. TLS 1.3 uses it the same way as TLS 1.2.

Why do servers need SNI?

A certificate is issued for specific names, and the server has to present one before the encrypted connection exists. Before SNI, the server knew only the IP address and port the client had connected to. Each HTTPS site needed its own address, or one certificate had to list every site on the address. With SNI, one address can serve thousands of sites, each with its own certificate.

The HTTP Host header carries the same name, but it is sent inside the encrypted connection, after the certificate has been chosen. SNI exists because the server needs the name earlier than that.

What does a server do with the name?

The server compares the name with the sites it is configured for and presents the matching certificate. Web servers do this per virtual host: in nginx, the server_name of each server block listening on the address, and in Apache, the ServerName and ServerAlias of each virtual host. One of the blocks is the default for the address (default_server in nginx, the first virtual host in Apache), and its certificate is what a client gets when no name matches or none was sent.

The following is a real capture of one Cloudflare address (104.20.23.154) asked for three different names. The commands connect to the address, send the name after -servername, and print the subject of the certificate that comes back:

Same address, same port, three certificates. Addresses and certificates change over time, so a run today may differ in detail.

Can the server name be read by others?

Yes. In TLS 1.2 and TLS 1.3 the ClientHello is not encrypted, so any network on the path between the client and the server can read the name. TLS 1.3 encrypts the server's certificate, but the SNI stays visible.

Encrypted Client Hello (ECH), defined in RFC 9849 and published in March 2026, encrypts the ClientHello when both sides support it. It requires TLS 1.3, and the client finds the server's public key in a DNS HTTPS record. The IP address the client connects to is still visible. The HostChecker SNI Checker sends a standard ClientHello and does not use ECH.

What happens when the server does not recognize the name?

RFC 6066 gives the server two choices. It can continue the handshake with a default certificate, or it can abort with a fatal TLS alert, unrecognized_name (code 112). Which one you see depends on the server's configuration:

• A default certificate. The handshake completes, and the certificate belongs to another site. The browser compares it with the name in the address bar and shows a warning. In Chrome this is NET::ERR_CERT_COMMON_NAME_INVALID.
• The unrecognized_name alert. The handshake stops before any certificate is used. Chrome reports ERR_SSL_UNRECOGNIZED_NAME_ALERT and Firefox reports SSL_ERROR_UNRECOGNIZED_NAME_ALERT. The address has no site configured for that name.
• A refused handshake. The server closes the connection or sends a handshake_failure alert (code 40). Some CDNs and proxies do this for any name they have no customer for, and for connections that send no name at all.

How do I test SNI?

1. Use the SNI Checker. Enter the hostname in the SNI Checker. It connects on port 443 and sends the name as the SNI. The result shows the TLS handshake, the certificate presented for that name and whether it covers it, the HTTP status, and the certificate the same address presents when no name is sent.
2. Use openssl s_client. openssl s_client -connect example.com:443 -servername example.com shows the certificate chain and the handshake. Since OpenSSL 1.1.1, s_client sends the hostname given to -connect as the SNI by default, so -servername matters when connecting to an IP address or testing a different name. -noservername sends none.
3. Use curl. curl -v https://example.com/ prints the handshake and the certificate details. Curl takes the SNI from the host in the URL.

Leaving the name out shows how an address behaves for a client that sends none:

This address refuses the handshake without a name. A server that has a default certificate would instead return it, and the SNI Checker shows that certificate under "Without a server name".

How do I test a server before DNS points at it?

Send the real hostname to the new server's IP address. That presents the certificate and the response visitors would get after the DNS change, before anyone is sent there. In the SNI Checker, enter the hostname in the first box and the new server's IPv4 address in "Connect to". On the command line:

The --resolve option supplies the address for the name, so curl connects there and still sends example.com as the SNI and the Host header. Running curl -I https://104.20.23.154/ instead sends no SNI, and this address answers with a handshake failure.

Why does a server return the wrong certificate?

• The name was never added. A domain was pointed at the server in DNS, but there is no virtual host for it, or its certificate does not list the name. The request falls through to the default site. Compare the "Certificate for" card with "Without a server name" in the SNI Checker: if they match, the server has nothing of its own for your name.
• DNS points at the wrong server. The name resolves to an old host, a different load balancer, or a stale address. Check what the name resolves to with a DNS lookup, and if you changed it recently, see how long DNS propagation takes.
• A CDN or load balancer has not finished. Providers that serve custom domains from shared addresses choose the site by SNI. Until the domain is attached and its certificate is issued, the provider's default certificate or a handshake failure is what comes back.
• The client sent no name. It connected by IP address, which RFC 6066 does not allow as an SNI value, or it is old enough not to support the extension. Internet Explorer on Windows XP is the usual example.
• The certificate is valid but for another name. The right site answers, but the certificate lists only the bare domain or only www. The SSL checker lists the names a certificate covers, and the expired certificate post covers renewal.

What an SNI check does not tell you

• It runs from HostChecker's server. It shows what that server receives, which can differ from what your network gets.
• It covers port 443 and IPv4. Other ports and IPv6 addresses are not checked.
• The trust verdict uses this server's list of certificate authorities. A device with a different list can reach a different result.
• It is not a TLS audit. It reports the version and cipher suite that were negotiated. It does not test older protocol versions, weak ciphers, revocation, or ECH.
• It sends one HTTP request for the home page, headers only, and does not follow redirects. To follow them step by step, use Host Check.

Common questions

Do all browsers support SNI?

Every current browser and HTTP client sends it. The clients that do not are very old ones, such as Internet Explorer on Windows XP and the stock browser on Android 2.x, plus some embedded software and old scripts.

Is SNI the same as the Host header?

They carry the same name for different purposes. The SNI is in the TLS handshake and selects the certificate. The Host header is in the HTTP request and selects the site. They normally match, and they are separate fields, so a client can send different values.

Can I use an IP address as the server name?

No. RFC 6066 does not permit literal IPv4 or IPv6 addresses in the extension, so a client connecting to a bare IP sends no SNI. To test a name against a particular address, put the name in the SNI field and the address in the connect target, as in the --resolve example above.

Does a site with one certificate need SNI?

No. A server with one site on its address presents the same certificate to every client, with or without a name. SNI matters once an address serves more than one certificate.

What is the difference between SNI and a wildcard certificate?

SNI picks which certificate the server presents. A wildcard certificate such as *.example.com is one certificate that covers many names. They are often used together: a server uses SNI to choose among its certificates, and one of them can be a wildcard.