What Is SNI Filtering, and How Does It Block Connections?

SNI filtering is a network-control technique that reads the server name sent near the start of a TLS connection and applies a rule to that name. If the name matches a blocked entry, the network can drop packets, reset the connection, or prevent the handshake from finishing. The filter usually does not need to decrypt the later HTTPS content.

The complete VPN guide separates routing metadata from protected content. This article focuses narrowly on the TLS server_name signal, the enforcement decision, and the limits introduced by Encrypted ClientHello (ECH).

Key Takeaways

• SNI carries the hostname a client wants to reach when several HTTPS sites share one address.
• Traditional SNI is visible in the TLS ClientHello, so an on-path device can compare it with a rule list.
• A block may look like a reset, timeout, or TLS failure even though DNS and TCP worked.
• ECH can encrypt the real ClientHello, but it does not hide the destination IP or guarantee reachability.
• One failed connection is evidence of a path failure, not automatic proof that SNI filtering caused it.

What information does SNI expose?

TLS protects application data only after the client and server agree on security parameters. Before that protected session exists, the client sends a ClientHello. RFC 6066 defines the server_name extension so a client can tell a server which hostname it intends to use.［1］ This is necessary when many virtual hosts share an IP address and the server must choose the right certificate and configuration.

In classic TLS 1.2 and TLS 1.3 handshakes, the hostname in that extension is observable to a device that can inspect the ClientHello. It is not a full URL. It normally reveals a host such as example.com, not the HTTPS path, query, page text, password, or message sent after encryption begins.

That distinction matters. A network can make a hostname-level policy decision without learning the specific page. Conversely, seeing an IP address alone may be ambiguous when unrelated hostnames share a CDN edge. SNI supplies a more precise name for the policy engine to compare.

Visible item	Usually available before filtering	What it does not reveal
Destination IP and port	Yes	Exact hostname on shared hosting
TLS server_name	Yes with traditional ClientHello	URL path or page contents
TLS versions and extensions	Yes	Decrypted application messages
HTTPS request path	No, after TLS succeeds	Not available to a passive SNI filter
Account credentials	No, after TLS succeeds	Not available merely from SNI

How does an SNI filter make a blocking decision?

An on-path device first identifies a TLS ClientHello and parses enough of it to find the server_name extension. It normalizes the hostname according to its implementation, compares the value with an allowlist, blocklist, or policy category, then either permits the handshake or interferes with it. The enforcement point may sit in an enterprise gateway, school network, access provider, or other managed path.

The comparison can be exact, suffix-based, or category-based. Exact matching treats blocked.example as one name. Suffix rules may also cover subdomains. Poorly designed substring rules can overmatch innocent names, while stale lists can miss a new name or block a hostname whose ownership has changed.

Figure key: 1 is the client ClientHello; 2 is extraction of the visible server name; 3 is policy comparison; 4 is the permitted TLS handshake; 5 is a drop, reset, or other blocked result. The diagram shows a decision path, not every packet exchanged by TLS.

The filter does not have to send an explanatory web page. It can silently discard a ClientHello or later handshake packet. It can inject a TCP reset where that transport is used. It can also route the request to a policy response. Different mechanisms produce different symptoms at the application.

Where can SNI filtering occur?

The device must be able to observe traffic before the TLS handshake reaches its destination. A local gateway sees traffic leaving one network. A carrier can observe traffic on its access path. An enterprise TLS-inspection system may terminate and recreate TLS under an installed organizational trust policy, but that is broader than passive SNI matching and should not be confused with it.

Filtering can also happen at the server or reverse proxy. A server that receives an unsupported name can reject the handshake. That is name-based routing or access control at the endpoint, not necessarily censorship by an intermediary. The packet trace and server logs determine which actor made the decision.

DNS filtering is a separate control point. DNS decides how a name is resolved; SNI filtering evaluates a name carried in a later TLS exchange. A client may resolve the correct address and still fail at the ClientHello. Likewise, encrypted DNS can protect the resolver exchange while leaving traditional SNI visible. The encrypted-DNS boundary explains why changing one signal does not erase the outer connection.

What does an SNI-blocked connection look like?

Common symptoms include a browser reporting that the secure connection failed, a connection that stalls after TCP setup, or a reset shortly after the ClientHello. The same IP may work when contacted with a different permitted hostname. A non-TLS service on that address may also behave normally.

None of those symptoms uniquely identifies SNI filtering. Packet loss, a broken route, an incompatible TLS version, certificate problems, server-side name rejection, or endpoint blocking can look similar. A useful diagnosis identifies the first stage that differs instead of naming the filter from a generic timeout.

A controlled comparison can hold the device, software version, destination IP, and time constant while changing only the network. Server logs can show whether the ClientHello arrived. A packet capture can show whether TCP opened and whether a reset appeared, but captures should be handled as sensitive records because they contain addresses, timing, and potentially hostnames.

Why can one hostname work on a shared IP while another fails?

When two hostnames share one IP, an address-only rule affects both. A name-aware rule can allow one SNI value and block the other. That difference is a strong reason to investigate hostname policy, but it is still necessary to exclude server-side virtual-host behavior.

The reverse is also possible: a network may block the shared IP, causing every hostname on it to fail regardless of SNI. This is coarser and can create more collateral damage. The website-blocking overview compares name, address, routing, and application-layer controls.

How does ECH change SNI filtering?

ECH encrypts the sensitive inner ClientHello, including the real server name, to a server that can decrypt it. RFC 9849 defines the current ECH protocol, while RFC 9505 describes the privacy problem created when identifiers such as SNI remain exposed.［2］［3］ A passive intermediary that only understands the outer exchange should no longer receive the real inner name in cleartext.

ECH does not make the whole connection invisible. The destination IP, transport, packet sizes, timing, and an outer ClientHello remain observable. The outer name is chosen as part of the ECH deployment and may identify a public-facing service shared by many protected origins. Networks can block that address, interfere with ECH discovery, or apply policy to the outer signal, though such actions may affect many unrelated sites.

Deployment is also a chain. The client, DNS discovery, fronting service, and origin routing all need compatible ECH configuration. A fallback to a non-ECH handshake may reveal the traditional SNI, depending on client policy and server availability. Therefore “the browser supports ECH” is not enough to prove that a particular connection protected its inner name.

Does ECH make SNI filtering obsolete?

It makes direct filtering on the real cleartext SNI less available when ECH is successfully negotiated. It does not remove every name-based policy mechanism. An endpoint can still apply policy after decrypting the inner ClientHello, and a managed device may enforce rules before traffic leaves the host.

Networks may shift to IP reputation, DNS controls, endpoint policy, traffic classification, or coarse blocking. These methods have different accuracy and collateral costs. ECH changes the observation surface; it does not promise universal access.

How does a VPN change the observation point?

When a system tunnel is established correctly, the local access network normally sees the outer VPN connection rather than each inner destination's TLS handshake. The VPN exit side then creates or forwards the destination connection, so observation moves to a different part of the path. Browser extensions, split tunneling, leaks, and applications excluded from the tunnel can produce a different result.

This is a boundary, not a guarantee that every product or protocol defeats every network policy. A network may block the VPN endpoint, restrict its transport, or classify the outer connection without ever reading the inner destination SNI.

To check this observation point on your own connection, turn on global mode in AethoVPN, so every app's traffic enters the tunnel, and connect before loading the destination you are testing; the local network then sees the outer VPN connection rather than that site's handshake. Switching global mode off sends traffic for sites in your own region outside AethoVPN, which helps you tell a local-site problem apart from a filtered foreign destination. Use it only where VPN use is permitted, and remember that it cannot hide destination IPs from the exit side or make every filtering system disappear. Start a 3-day free trial with your email to run the comparison.

For diagnosis, first prove which interface carried the failing connection. Then distinguish failure of the outer tunnel from a destination failure after the tunnel connected. Mixing those stages often produces the mistaken claim that an SNI rule “blocked the VPN” when the evidence only shows one application request failed.

Summary

• SNI filtering reads a hostname from a traditional TLS ClientHello and applies a name-based rule.
• It can stop a handshake without decrypting later HTTPS content.
• Resets, timeouts, and TLS errors are compatible with SNI filtering but are not unique proof.
• ECH protects the real inner ClientHello when the full deployment path succeeds.
• IP addresses, timing, transport, and outer connection behavior remain visible.
• A VPN moves inner destination observation behind the tunnel but does not guarantee reachability.

FAQ

Is SNI the same as DNS?

No. DNS maps names to addressing information. SNI carries a server name in the TLS handshake so a server can select the correct virtual host. Either can be filtered independently.

Can SNI filtering read the full HTTPS URL?

Not by SNI alone. Traditional SNI exposes a hostname, while the path, query, headers, and content are sent inside the protected TLS session after the handshake.

Does a TCP reset prove SNI filtering?

No. A middlebox can inject a reset, but servers, firewalls, and broken paths can also reset connections. The timing and controlled comparisons provide context.

Can changing DNS bypass SNI filtering?

Changing resolvers may avoid a DNS-specific failure, but it does not remove a traditional cleartext SNI from the later TLS ClientHello.

Does TLS 1.3 encrypt SNI automatically?

No. TLS 1.3 encrypts more of the handshake than earlier versions, but protecting the real ClientHello name requires ECH and a compatible deployment.

Can a shared IP still be blocked?

Yes. A network can block the whole address instead of selecting one hostname. That is less precise and may disrupt unrelated services on the same address.

Does a VPN always hide destination SNI from local Wi-Fi?

Only traffic that actually enters an established tunnel gains that boundary. Split-tunneled apps, leaks, browser-only protection, or a failed tunnel can leave different traffic visible.

Disclaimer: This article is for general informational purposes only and does not constitute legal, technical, or other professional advice. We make no guarantees regarding the accuracy, completeness, or timeliness of the content.

Sources:

1. IETF, "RFC 6066: Transport Layer Security (TLS) Extensions: Extension Definitions": https://www.rfc-editor.org/rfc/rfc6066
2. IETF, "RFC 9505: A Survey of Worldwide Censorship Techniques": https://www.rfc-editor.org/rfc/rfc9505
3. IETF, "RFC 9849: TLS Encrypted Client Hello": https://www.rfc-editor.org/rfc/rfc9849

Sources checked 12 September 2026.

---

Related Articles:

• Understand the complete VPN path
• Separate SNI matching from TLS fingerprinting
• Compare common website-blocking mechanisms
• Understand the REALITY target contract
• See why encrypted DNS does not hide every signal