什么是 SNI(服务器名称指示 · 明文门牌)?
在 HTTPS 加密建立之前,服务器根本不知道你想要找大楼里的“哪家租户(哪个域名)”,也就不知道该掏出哪张 SSL 证书;而 SNI(Server Name Indication) 就像写在加密信封外面的“收件人公司门牌号” —— 既解决了单 IP 托管成千上万个 HTTPS 网站的世纪难题,也成了网络审查与防封博弈的核心风暴眼!
进门不开腔,服务器掏错证书
当一台服务器拥有 100 个 HTTPS 域名时,客户端连上来啥也没说(因为 HTTP 请求在加密层里面还没建立),服务器只能盲目甩出一张默认证书,导致浏览器疯狂报红“证书不匹配(ERR_CERT_COMMON_NAME_INVALID)”!
- ❌ IPv4 资源极度浪费:虚拟主机和 CDN 根本无法低成本规模化
- ❌ 证书频繁报错:多域名共享服务器时经常由于发错证书而打不开
先报收件人,精准返回正确证书
在 TLS 握手的第一步(ClientHello),客户端明文带上 server_name = site-b.com。服务器心领神会,精准掏出对应的 B 网站证书建立加密连接,单台服务器托管百万域名!
- ✨ 单 IP 托管百万站:Cloudflare 一个 Anycast IP 能同时给全网几千万网站加速
- ⚠️ 明文泄露隐患:因为写在信封外面,旁路审查者能看清你想去哪个网站
拆解 SNI 的 4 大核心维度与技术演进
从 TLS 握手扩展到 ECH 终极加密,读懂互联网的门牌战争
1. TLS ClientHello 扩展 (RFC 6066)
在 TCP 三次握手后的第 1 个 TLS 数据包中携带 server_name 字段,通知服务器客户端期望连通的完整主机名(FQDN)。
2. 拯救全球 IPv4 枯竭
没有 SNI,全球公网 IPv4 早在 15 年前就彻底耗尽。它是 CDN、Nginx 虚拟主机(Virtual Host)和反向代理不可或缺的生命线。
3. SNI 阻断与 TCP RST 劫持
深度包检测(DPI)设备在骨干网旁路监听 ClientHello,一旦嗅探到黑名单域名,0.1 毫秒内伪造 TCP RST 重置包将连接掐死!
4. 终极救赎:ECH (加密 ClientHello)
从 ESNI 进化而来的 ECH(Encrypted ClientHello):通过 DNS 预先拿到的公钥把 SNI 彻底加密,让信封外面的门牌号也彻底隐身!
🕹️ TLS 握手 SNI 嗅探与审查演练台
观察普通访问、黑名单域名被 SNI 阻断、以及开启 ECH 加密后的不同命运:
DPI 审查设备放行;服务器收到后精准下发苹果证书。
随后建立加密通道,通信正常进行。
Reality 为什么能利用 SNI?
既然审查者只看明文 SNI:
Xray Reality 索性在 ClientHello 里把 SNI 填成 gateway.icloud.com(借壳苹果),让审查系统以为你在同步相册直接放行,把“明文破绽”反向变成了“免死金牌”!
SNI 阻断切断了直连幻想
就算你在本地 hosts 把目标域名直接解析到真实海外 IP;
由于浏览器发起 HTTPS 请求时依然会在 ClientHello 里老老实实带上明文 SNI,骨干网 DPI 依然能瞬间抓包并下发 TCP RST 强制断开!
Cloudflare 与主流浏览器的抗争
目前 Chrome、Firefox 与 Cloudflare 正在全面普及 ECH(Encrypted ClientHello)。
配合 DoH(DNS over HTTPS),未来互联网将彻底消灭所有明文域名泄露,重塑真正的端到端网络隐私!