TLS SNI (Server Name Indication)
What it is (Definition)
SNI (Server Name Indication) is a TLS extension sent by the client during the handshake to indicate the hostname it wants to connect to (for example, api.example.com). This matters because many servers host multiple domains on the same IP address. Without SNI, the server would not know which certificate and configuration to present before encryption is established.
In practical troubleshooting, SNI is often the only “application hint” available for HTTPS traffic when you cannot decrypt. It helps answer: “Which hostname was the client attempting to reach?” That is valuable when IPs are shared across many services (CDNs, reverse proxies, multi-tenant platforms).
Where it appears in the stack
SNI appears inside the TLS handshake (typically ClientHello). In classic HTTPS, TLS runs over TCP/443. For other protocols, similar concepts can exist, but SNI is specifically a TLS extension. Depending on capture location and TLS features, SNI may be visible to the network even when application data is encrypted.
How SNI affects server selection
- Client opens a TCP connection to an IP (often shared by many hostnames).
- Client sends ClientHello including SNI = desired hostname.
- Server selects the appropriate certificate and policy for that hostname.
- Handshake completes; application data flows encrypted.
If SNI is missing or incorrect, the server might return a default certificate, route to a default virtual host, or terminate the handshake depending on configuration.
Common values and outcomes (Value table)
| SNI value / state | Meaning | Common outcome | Notes |
|---|---|---|---|
| Valid hostname | Client requests a specific site | Correct certificate and routing | Most normal HTTPS traffic |
| Missing SNI | No hostname provided | Default certificate / wrong site / failure | Legacy clients or special tooling; less common today |
| Wrong hostname | Mismatch vs intended site | Certificate mismatch or policy block | Can happen with proxies or misconfigured clients |
| Blocked hostname | Policy uses SNI for filtering | Handshake fails or resets | Some networks apply domain-based controls at TLS layer |
| Encrypted/hidden indication | Hostname not visible to observer | Harder network-side debugging | Visibility depends on TLS features and capture point |
How it looks in Wireshark
Display filter example:
tls.handshake.extensions_server_nameWhat you typically see:
- ClientHello details including SNI hostname.
- Certificate subject/SAN that should match the requested hostname.
- Handshake alerts when policy or compatibility fails.
Quick read tip: When users report “wrong certificate” or “site blocked,” check SNI first. If the SNI is wrong or missing, everything above it will look broken even if TCP is fine.
Common troubleshooting patterns
Certificate mismatch on shared IP
If the server presents the wrong certificate, the most common cause in shared hosting is that the server did not select the intended virtual host. Confirm that the client’s SNI matches the expected hostname and that the certificate SAN covers it.
TLS handshake fails only on certain networks
Some environments apply policy controls based on hostname. If a domain is blocked, you may see resets or TLS alerts shortly after ClientHello. Comparing captures on “working network” vs “failing network” and comparing SNI is often decisive.
Related pages (internal links)
- Back to Fields Index
- Dictionary: TLS overview
- Dictionary: HTTP/1.1 overview (HTTPS runs HTTP over TLS)
- Topics Index (Reading a TLS handshake — Soon)