# 当防火墙开始读你的 SNI：一份对抗 SNI 阻断的实战指南 > "它没有封你的 IP，也没有污染你的 DNS，你的域名解

“它没有封你的 IP，也没有污染你的 DNS，你的域名解析一切正常——但你就是连不上。”

如果你遇到过上面这种情况，大概率是撞上了 SNI 阻断（SNI-based blocking）。这是近年来深度包检测（DPI）系统最常用的封锁手段之一，比 IP 封锁更精准，比 DNS 污染更隐蔽，也让很多人第一次意识到：TLS 握手并不是你以为的那么"加密"。

这篇文章会从原理讲到实战，帮你彻底搞懂 SNI 阻断是怎么回事，以及目前有哪些行之有效的对抗方案。

一、先搞懂：SNI 是什么，为什么它是明文的？

TLS 握手的简化版

当你用浏览器访问 https://example.com 时，在建立加密通道之前，客户端和服务器要先"握手"。简化过程如下：

Client                          Server
  |                               |
  |  ---- ClientHello ----------> |   ← 关键！SNI 就在这一步
  |                               |
  |  <--- ServerHello ----------  |
  |  <--- Certificate ----------  |
  |                               |
  |  ==== 加密通道建立 =========  |
  |                               |

ClientHello 是整个 TLS 握手中客户端发送的第一个消息，里面包含了很多字段，其中有一个叫 SNI（Server Name Indication）。

SNI 存在的意义

一台服务器上可能同时托管了 a.com、b.com、c.com 三个网站（共享同一个 IP）。服务器在收到 ClientHello 时，还没建立加密通道，它需要知道客户端到底想访问哪个域名，才能返回对应的数字证书。

所以 SNI 字段里会明文写入目标域名：

ClientHello:
  ...
  server_name: "example.com"   ← 明文！任何人都能读到
  ...

问题来了

加密通道还没建立，SNI 就已经发出去了。这意味着：

• 你和服务器之间的中间设备（路由器、防火墙、运营商 DPI 系统）都能看到你正在访问哪个域名。
• 防火墙不需要解密后续的通信内容，只需要瞄一眼 ClientHello 里的 SNI 字段，就能决定是否丢弃这个连接。

这就是 SNI 阻断：防火墙在 TLS 握手的第一步就拦下你，比看 IP 更精准（一个 IP 上可能有几十个域名，只封其中一个），比 DNS 污染更难绕过（你换了 DNS 也没用，因为封锁发生在握手阶段）。

二、SNI 阻断的表现

怎么判断自己是不是被 SNI 阻断了？几个典型特征：

1. DNS 解析正常：nslookup 或 dig 能返回正确的 IP，没有被污染。
2. IP 本身能通：ping 或 traceroute 到目标 IP 没问题，ICMP 不受影响。
3. TLS 握手失败：curl -v https://blocked-domain.com 卡在 ClientHello 之后，连接被 reset 或超时。
4. 换 DNS 没用：即使配置了 DoH/DoT，解析结果正确，连接依然被阻断。
5. 同 IP 其他域名正常：同一台服务器上的其他域名可以正常访问，只有特定域名被阻断。

一个快速验证的小技巧：

# 用 openssl 手动握手，观察是否在 ClientHello 后被 reset
openssl s_client -connect <target-ip>:443 -servername <blocked-domain>

# 对比：不发送 SNI（或发送一个不被阻断的域名）
openssl s_client -connect <target-ip>:443 -servername <unblocked-domain>

如果第一种情况连接被 reset，第二种正常完成握手，那基本可以确认是 SNI 阻断。

三、对抗方案总览

下面逐一展开。

四、方案一：ECH — 加密 ClientHello（正道）

ECH（Encrypted Client Hello）是 ESNI 的演进版本，目前是 IETF 草案标准。它的核心思想很简单：把 ClientHello 里的敏感信息（包括 SNI）加密掉。

工作原理

Client                          Server
  |                               |
  |  ---- Outer ClientHello ----> |   ← SNI 写一个公开的"掩护域名"
  |       (内含加密的 Inner       |      （比如 cloudflare-ech.com）
  |        ClientHello)           |
  |                               |
  |  <--- ServerHello ----------  |
  |  <--- Certificate ----------  |   ← 返回的是真实域名的证书
  |                               |
  |  ==== 加密通道建立 =========  |

客户端用一个公开的公钥（从 DNS HTTPS 记录中获取）把真实的 SNI 加密，放进 ClientHello 的扩展字段里。外层只暴露一个无害的掩护域名。服务器解密后才知道你真正要访问的是哪个域名。

怎么用

客户端（Firefox）：

1. 在地址栏输入 about:config
2. 搜索 network.dns.ech
3. 设置 network.dns.ech.enabled = true
4. 设置 network.dns.use_https_rr_as_altsvc = true

客户端（Chrome/Edge）：

Chrome 从较新版本开始已默认支持 ECH，前提是系统 DNS 使用了 DoH（DNS over HTTPS）。确保：

1. 设置 → 隐私和安全 → 安全 → 使用安全 DNS：开启
2. 选择一个支持 ECH 的 DoH 提供商（如 Cloudflare 的 1.1.1.1）

服务端：

需要 CDN 或服务器支持 ECH。目前 Cloudflare 已全面支持 ECH，如果你的域名托管在 Cloudflare 后面，客户端配置好 ECH 后就能自动生效。

局限性

• ECH 依赖从 DNS HTTPS 记录获取公钥，如果 DNS 查询本身被拦截/污染，ECH 的公钥获取也会受影响（所以通常需要配合 DoH 使用）。
• 并非所有服务器和 CDN 都支持 ECH。
• 部分网络环境可能连外层掩护域名也一并封锁。

但这是最正统的方向。 随着 TLS 1.3 的普及和 ECH 标准的推进，这应该成为长期首选方案。

五、方案二：域前置（Domain Fronting）

域前置是一个经典的"偷梁换柱"技巧。核心思路：SNI 写一个不被阻断的域名，真正的目标域名放在 HTTP 层的 Host 头里。

原理

TLS 层:
  SNI = "front-domain.com"     ← 防火墙看到的是这个，放行

HTTP 层（加密后，防火墙看不到）:
  Host: "real-target-domain.com"  ← CDN 根据这个转发到真正的后端

防火墙只能看到 TLS 层的 SNI，HTTP 层的 Host 头在加密通道内，防火墙看不到。CDN 收到请求后，根据 Host 头将请求转发到对应的后端。

实战示例

假设 real-target.com 被 SNI 阻断，但 harmless.com 和 real-target.com 托管在同一个 CDN 上：

curl -v https://harmless.com \
  -H "Host: real-target.com" \
  --resolve "harmless.com:443:<cdn-edge-ip>"

• --resolve 确保连接到 CDN 的边缘节点
• SNI 自动设为 harmless.com（因为 URL 是它）
• Host 头设为 real-target.com，CDN 据此路由

局限性

• 依赖 CDN 的配合：CDN 必须接受"SNI 域名和 Host 头域名不一致"的请求。一些大型 CDN（如 Google、Amazon CloudFront）出于反审查压力，已经陆续关闭了对域前置的支持。
• TLS 1.3 的影响：在 TLS 1.3 中，HTTP Host 头确实在加密层内，但部分 CDN 实现可能在解密后仍然检查 SNI 和 Host 的一致性。
• 不是所有 CDN 都适用：需要两个域名在同一个 CDN 的同一个边缘节点上有配置。

域前置是一个"能用多久不确定"的方案，但在某些场景下仍然有效，值得作为备选手段了解。

六、方案三：代理转发

如果你有一个在防火墙之外的代理服务器，最直接的思路是：让代理替你发起 TLS 连接，本地的 ClientHello 根本不经过那个会做 SNI 检查的防火墙。

方案变体

1. 正向 HTTPS 代理

浏览器 → [本地网络/防火墙] → 代理服务器 → 目标网站

浏览器到代理之间是 CONNECT 隧道，防火墙只看到你在连接代理服务器，看不到后续的 TLS 握手。代理服务器到目标网站之间的 SNI 是在防火墙之外发送的，不受影响。

2. SOCKS5 代理 + TLS

同理，SOCKS5 代理在传输层转发流量，防火墙只看到到代理的连接。

3. 代理链 + 加密封装

如果到代理服务器本身的连接也被干扰，可以在代理外面再套一层加密：

浏览器 → [Shadowsocks/V2Ray/Trojan 等加密协议] → 代理服务器 → 目标网站

这类协议的设计目标就是把流量伪装成正常的 HTTPS 流量，使防火墙无法区分。

配置示例（以 SOCKS5 代理为例）

# 使用 curl 通过 SOCKS5 代理访问被阻断的域名
curl -v --socks5-hostname 127.0.0.1:1080 https://blocked-domain.com

--socks5-hostname 让域名解析在代理端进行，本地不暴露任何目标域名信息。

局限性

• 需要一台在防火墙外的服务器。
• 代理服务器本身的 IP 可能被封（但这属于另一个层面的对抗了）。
• 需要维护代理服务的可用性。

这是最通用、最可靠的方案，但成本在于需要额外的服务器资源。

七、方案四：TLS 1.3 Session Resumption

这个方案不是"解决" SNI 阻断，而是缩小暴露窗口。

原理

TLS 1.3 支持 0-RTT（零往返时间）会话恢复。如果客户端和服务器之前已经建立过连接，客户端可以用之前协商的密钥材料直接恢复会话，发送的第一个数据包里就包含加密的应用数据。

在会话恢复场景下，ClientHello 中的 SNI 仍然存在（用于服务器选择证书），但如果使用 PSK（Pre-Shared Key）模式，可以省略部分明文信息。

实际效果

• 首次连接仍然暴露 SNI，无法避免首次被阻断。
• 后续连接如果能复用会话，可以减少完整握手的次数。
• 单靠这个方案不足以对抗主动的 SNI 阻断，但作为辅助手段可以减少暴露次数。

建议作为其他方案的补充，而不是独立方案使用。

八、方案五：自定义协议封装

对于需要更高隐蔽性的场景，可以把 TLS 流量封装在其他协议的外壳里，让防火墙根本识别不出这是 TLS 流量。

思路

应用数据 → TLS 加密 → 再封装为 ICMP / DNS / WebSocket / 伪 HTTPS → 传输

常见实现：

• ICMP 隧道：把数据塞进 ping 包的数据部分。防火墙一般不会深度检查 ICMP。
• DNS 隧道：把数据编码进 DNS 查询的子域名里。需要一台控制了权威 DNS 的服务器。
• WebSocket 伪装：在正常的 HTTPS WebSocket 连接里传输数据。对防火墙来说看起来就是普通的 WSS 流量。

局限性

• 需要客户端和服务端都部署对应软件。
• 性能开销大（尤其 DNS 隧道，带宽极低）。
• 配置复杂，不适合普通用户。
• 高级 DPI 系统可能通过流量分析识别异常模式。

这个方案适合对隐蔽性要求极高的场景，普通用户一般不需要走到这一步。

九、实战决策树

面对 SNI 阻断，怎么选方案？一个简单的决策流程：

被 SNI 阻断了？
│
├─ 有可控的代理服务器吗？
│   ├─ 有 → 方案三（代理转发），最省心
│   └─ 没有 → 继续
│
├─ 目标域名在支持 ECH 的 CDN 后面吗？（如 Cloudflare）
│   ├─ 是 → 方案一（ECH），配置浏览器即可，零成本
│   └─ 否 → 继续
│
├─ 目标域名和某个无害域名在同一个 CDN 上吗？
│   ├─ 是 → 方案二（域前置），试试看
│   └─ 否 → 继续
│
└─ 需要极高隐蔽性？
    ├─ 是 → 方案五（自定义协议封装）
    └─ 否 → 考虑租一台海外小机器做代理（回到方案三）

十、一些常见误区

误区 1：“换了 DNS 就能解决”

不能。SNI 阻断发生在 TLS 握手阶段，和 DNS 解析无关。你用 DoH 拿到了正确的 IP，但 ClientHello 里的 SNI 仍然会被防火墙检查。DoH 解决的是 DNS 层面的问题，SNI 阻断是 TLS 层面的问题。

误区 2：“用 IP 直接访问就行”

不行。直接用 IP 访问 HTTPS 站点时，要么不发送 SNI（服务器不知道返回哪个证书），要么仍然要发送 SNI（同样被检查）。而且很多服务器配置了基于域名的虚拟主机，没有 SNI 根本无法正常响应。

误区 3：“TLS 1.3 解决了这个问题”

TLS 1.3 加密了更多的握手信息，但 SNI 在标准 TLS 1.3 中仍然是明文的。SNI 的加密需要 ECH 扩展，这不是 TLS 1.3 自带的功能。TLS 1.3 是 ECH 的基础（ECH 依赖 TLS 1.3 的加密机制），但两者不等价。

误区 4：“HTTP/2 或 HTTP/3 能绕过”

不能。HTTP/2 和 HTTP/3 是应用层协议，它们运行在 TLS 之上（HTTP/3 使用 QUIC，底层仍然是加密的）。SNI 暴露发生在 TLS 握手阶段，在 HTTP 层协议开始工作之前，换 HTTP 版本不影响 SNI 的暴露。

十一、写在最后

SNI 阻断的本质是：在一个加密协议的设计中，为了解决实际需求（共享 IP 的多域名证书选择），不得不在加密通道建立之前暴露了一个关键信息。 这是协议设计时的 trade-off，在当时是合理的，但随着深度包检测技术的普及，这个明文字段成了最容易被利用的弱点。

好在社区已经意识到了这个问题。ECH 正在推进标准化，主流浏览器陆续支持，CDN 也在逐步部署。长期来看，SNI 加密会成为 TLS 的默认行为。

但在那一天到来之前，了解这些对抗方案，在需要的时候能够选择合适的工具，仍然是有价值的。

技术的对抗不会停止，但方向始终是让通信更安全、更私密。