DNS on aloneowo's blog

有关GFW阻断的个人观察总结

Thu, 11 Jun 2026 00:00:00 +0000

有关GFW阻断的个人观察

前言

本文是对GFW的个人观测结果，受限于个人测试环境和信息获取渠道，仅作为个人观点

作为一个计算机学生，对于科学上网是既必须又无奈的需求。不得不承认国外的资料确实多且全。最近看到了 XTLS BBS 里面提到了有关使用 ECH + DoH 的讨论，以及由于这个帖子启发而自己手搓的worker的DoH涉及到了大量对GFW策略的试探。本文不对绕过GFW做叙述，只分享一些GFW常用的阻断策略。

当前 GFW 使用的阻断方式总的可以归于 3 类：DNS 污染、SNI 阻断以及 IP 黑洞。其中，使用 ECH + DoH 可以有效避免前两者的影响，但不能对后者抗干扰。据我所知，IP 黑洞应该是无解的。

声明

这个算是一个比较敏感的话题，所以我先声明一下几点内容：在这篇文章里，我不会提及任何关于突破内容审查机制的关键词，不介绍、传播、扩散任何关于突破内容审查机制的工具。任何技术探究均在个人的局域网中完成，使用的信道均为国家网络运营商提供的合法有效的信道。

友情提示：GFW在2021年11月中国国家互联网信息办公室发布的《网络数据安全管理条例（征求意见稿）》中被称为跨境安全网关，用于阻断访问境外反动网站和有害信息、防止来自境外的网络攻击、管控跨境网络数据传输、防范侦查打击跨境网络犯罪。擅自使用、搭建国际信道涉嫌违法，并有因此而被逮捕的事例，请各位慎重行事。

DNS 污染

我们在访问网站的时候，多数使用的是域名访问（我至少没看到谁闲的无聊用 IP 访问网站的）。在计算机网络中，计算机与计算机之间只能使用 IP 相互访问，域名的设计是为了让人类好记。人类是好记了，那机器怎么办？

于是就出现了 DNS 这个东西。DNS 负责将域名转换为 IP 返回给计算机，再让计算机访问那个 IP。比如说我要访问 baidu.com，那么会先在 DNS 上查询 baidu.com 的 A / AAAA 解析的 IP，然后计算机访问这个归属于百度的 IP。

那么假如说某一个用户尝试访问 google.com，按照 DNS 的标准理应返回 google.com 的 A / AAAA 解析，但是由于众所周知的原因，google 配不上东大。于是 GFW 搞了个 DNS 污染：当用户访问不被允许的网站的时候，DNS 直接返回一个错误的 IP，比如某个 DNS 非常的喜欢返回 localhost（感兴趣的可以查查）。由于客户端没有识别机制，那么计算机就会尝试去访问那个错误的 IP，很明显并不会有返回，那么这样最简单的 DNS 污染就实现了。

那么就有人要问了：换一个没有被污染的 DNS 不就可以了吗。早期确实是这样的，但是现在 1.1.1.1、8.8.8.8 还有 9.9.9.9 会被劫持到运营商的 DNS 上，同 IP 的 DoH 倒是没有被劫持，可能与 GFW 的逻辑有关。

SNI 阻断（RST阻断）

如果你能成功解决 DNS 污染的问题（比如用 DoH），恭喜你，你来到了第二关：SNI 阻断。现在大部分网站都上了 HTTPS，而 HTTPS 依赖于 TLS 握手。在 TLS 握手的第一个包——ClientHello 中，客户端会告诉服务器自己要访问哪个域名。这个字段就叫 SNI（Server Name Indication）。问题在于，TLS 1.2 及以下的 ClientHello 是明文传输的。也就是说，GFW 不需要解密你的流量，只需要读取 ClientHello 里的 SNI 字段，就知道你要访问哪个网站。

一个 IP 上可能托管了几百个网站（比如 Cloudflare 的 CDN），SNI 就是用来告诉服务器「我要访问的是你托管的那几百个网站里的哪一个」。（一部分 CDN 厂商的策略如 cf 导致了其优化解析会非常简单，由于篇幅原因暂且不表）

如果说你尝试访问 google.com，那么你的数据包会经历那么几个环节：

客户端发送 ClientHello，其中 SNI = google.com
GFW 的 DPI（深度包检测）设备看到这个 SNI
匹配到黑名单 → GFW 向客户端和服务器同时发送伪造的 TCP RST 包
连接被重置，浏览器显示 ERR_CONNECTION_RESET

这个过程非常快，通常在 TLS 握手完成之前就结束了。而且由于是双向 RST，即使客户端忽略 RST 继续发包，服务器那边也已经断开了。

为什么 SNI 阻断比 DNS 污染更难搞

DNS 污染好歹可以通过用 DoH / DoT 来解决——毕竟只是换了个地图。但 SNI 阻断不同，它是直接在你和服务器之间的路上设卡，你不管问谁的路，最后走到这条路上都会被拦并接受检查。

不过有个细节值得注意：GFW 目前主要检查的是 TLS 1.2 及以下的 ClientHello。如果你用 TLS 1.3，情况会稍有不同，因为 TLS 1.3 支持 ECH（Encrypted ClientHello）。

ECH 的全称是 Encrypted ClientHello，由 Cloudflare、AWS 几个互联网厂商制定的 DNS 规则。它的核心思路很简单：既然 GFW 是通过明文的 SNI 来判断你要访问哪个网站的，那把 SNI 加密了不就完了？

ECH 会把真正的 ClientHello（含 SNI）用服务器提前公布的公钥加密，外面再套一层明文的掩护 SNI——一般是 CDN 的泛域名，比如 cloudflare-ech.com。GFW 看到的就是一个去 Cloudflare 的普通握手包，真正的目标域名藏在加密层里，它无从得知。

以 X 为例，当向 X 发送 ClientHello 时，GFW 会收到一个发往 cloudflare-ech.com 的握手包，目标 IP 是 Cloudflare 的节点。此时对于 GFW 来说并不能判断出数据包是发往 X。而 X 的边缘节点正好有部署在 Cloudflare，所以此时 Cloudflare 的节点就会解包并转发到 X 的服务器。

但是 ECH 有几个现实问题：

需要服务器支持：服务器必须提前公布 ECH 公钥（通常通过 DNS HTTPS 记录发布），客户端才能加密 ClientHello。目前支持 ECH 的网站还不算多，但是目前已知 Cloudflare 和 Meta 已开启 ECH 的支持。
需要客户端支持：浏览器要开启 ECH。Chrome、Firefox 都支持，但需要手动开启或者等默认启用。
GFW 可能直接封 IP：如果你访问的 IP 本身就在黑名单里，即使 SNI 加密了也没用，比如说访问 Facebook 时不小心解析到了被墙的 IP——这就是下面要说的 IP 黑洞。

ECH + DoH 的组合

DoH 解决 DNS 层面的污染，ECH 解决 SNI 层面的阻断。两者结合，理论上可以绕过 GFW 的前两道防线。这也是开头提到的那个 XTLS BBS 帖子的核心思路。

但这里有个坑：DoH 的域名本身可能被 SNI 阻断。如果你用 dns.google 作为 DoH 服务器，那客户端在连接 Google DNS 的时候发的 ClientHello 里 SNI 就是 dns.google——这不又被拦了？所以实际操作中需要选一个没被墙的 DoH 域名，或者在 Cloudflare Workers 上自建 DoH。

aloneowo0 / Workers-DoH

正在读取仓库简介...

-- --

我设计 DoH 思路就是将支持 ECH 的网站，使用各种方式获取对应网站 ECH 字段并植入到返回的 DoH 请求中，从而实现对大部分网站的 ECH 支持。

当然这个方案也有问题，从流量特征的角度来说，其由于把 ECH 和外层 SNI 放到同一个包中，MTU 会变得巨大以至于可以轻松地检测出其是否使用了 ECH。~~人家GFW只是懒得管不是看不见~~，该工具为学习使用，请勿滥用

IP 黑洞

即使你完美解决了 DNS 污染和 SNI 阻断，你还有一个绕不开的问题：你总得和服务器建立连接。而建立连接就需要知道对方的 IP 地址，并且向这个 IP 发包。

GFW 维护了一个庞大的 IP 黑名单。当你的数据包的目的 IP 在黑名单里时，GFW 的边界路由器会直接丢弃这些包——不给你任何回应，不发 RST，什么都不发。从你的视角看，就是连接超时。

这比 SNI 阻断更底层、更暴力，因为它不依赖协议层面的特征，只看 IP。

SNI 阻断可以用 ECH 加密，DNS 污染可以用 DoH 绕过。但 IP 黑洞不同——IP 地址是网络层的寻址基础，你没法「隐藏」目的 IP。就好像你寄信总得写收件人地址，不可能把地址也加密了。

据我所知，目前在单机层面没有直接绕过 IP 黑洞的办法。你不可能让 GFW 的路由器不检查你的目的 IP。

据不可靠渠道所说，IPv6 的阻拦会比 IPv4 小不少，具体原因未知，但是似乎确实有这个情况。

以上均为个人观察总结，受限于测试环境与信息渠道，部分细节可能与实际情况存在偏差。技术本身是中立的，本文仅讨论技术原理，不构成任何操作建议，请遵守中国大陆法律。

一些个人的话（26.7.11）

ECH这个东西跟WG有点像，属于是~~比较的安全~~但是特征及其明显，~~我也是无语了~~RFC给的流量隐藏标准竟然是让所有流量都带上ECH？！

属实是嫌GFW不知道你是ECH的重度用户了😂

“The client offers ECH if it is in possession of a compatible ECH configuration and sends GREASE ECH otherwise.”

“客户端持有兼容的 ECH 配置时发送真实 ECH；否则发送 GREASE ECH。”

而且通过DoH+ECH的方法有很大的弊端，就是你先要有一个可以直接使用的DoH端点然后才能获取ECH密钥。

那么如果说DoH被污染了呢？

先不说比较困难的SNI阻断（RST阻断），光光DNS污染就够喝一壶的了。如果你要使用这个DoH端点，首先客户端会去53端口上的明文DNS上查询这个DoH端点，假如说这一步就被拿下那连连接都没建立就死了。

如果要抗这个DNS污染那么你就要换一个干净的DNS或者在本地写好DoH的初始ip。前者需要用一个干净的DNS去访问另一个DoH的端点，~~我都有干净的DNS了我用什么DoH啊？~~，后者需要改host，配置比较麻烦倒也不是不行。

如果DoH端点还上了SNI阻断那更完蛋：要么上ECH，要么上sni前置伪装。前者跟之前一样是套娃，后者还要为这个东西开tun接管流量，专门搞一个客户端，感觉相当麻烦。

整个流程下来问题还是很多的。把这个做好直面GFW我只能说~~还是代理方便~~

SuperDoH：基于 Cloudflare Workers 的多上游 DNS over HTTPS 代理，支持ECH和路由注入

Thu, 28 May 2026 00:00:00 +0000

先推销一下自己的项目（手动 doge）

aloneowo0 / SuperDoH

正在读取仓库简介...

-- --

搭建一个个人 DoH 服务

Cloudflare 免费计划有每日额度限制，请不要随便公开自己的 DoH 端点。

前言

随便讲一下 DNS 的作用，和主题关系不大

我们访问互联网时，通常会在浏览器里输入一个网址。但计算机真正用来连接网络资源的是 IP 地址，而不是域名。因为 IP 地址不好记，所以才有了 DNS：它负责把 baidu.com 这样的域名转换成对应的 IP 地址。

能硬背 32 位 IPv6 地址的也是个狠人

传统 DNS 通常运行在 UDP 53 上，默认不加密，因此安全性和抗劫持能力都比较差。在早期 HTTP 环境下，DNS 劫持并不少见。为了解决这些问题，后来出现了几种加密 DNS 协议，比如 DoT、DoH 和 DoQ。

DoH 有什么用

DoH 全称是 DNS over HTTPS。简单来说，它会把 DNS 查询封装进 HTTPS 请求里，并通过 SSL/TLS 证书来保证传输过程的安全性。这里引用两段来自 Wiki 的数字身份认证说明：

“若注册者认定一个人的身份，是通过注册者信任的另外一个人来进行的。注册者信任的那个人就是身份认证机构（可以是一个自然人）。把数字身份比喻成一个证件，那么数字证书就是身份认证机构盖在数字身份证上的一个章或印（或者说加在数字身份证上的一个签名），这一行为表示身份认证机构已认定这个人。”

“身份认证机构是人们注册公钥的机构。注册之后，身份认证机构就向注册者发一数字证书，也就是说在注册者的数字身份证上加签。服务有免费，也有收费。身份认证机构也可以是一个自然人，就如 PGP 和 GPG 系统所倡导的。”

简单来说，因为 DoH 使用 HTTPS 作为传输层，我们可以降低 DNS 查询被监听或篡改的风险。比如某些喜欢往 DNS 结果里“投毒”、把域名解析到 localhost 的情况，DoH 就能在一定程度上缓解。

项目实现的功能（推销）

这个项目主要实现了下面几个功能：

通过 cf-forward-ip 实现 ECS 的手动注入。翻译成人话就是：解析结果会尽量根据用户所在地区进行优化。
使用并发请求加速解析，并返回最快的上游结果。
为cloudflare，Meta提供了完整的ECH注入
带有简单过滤逻辑，可以识别错误的 DNS 返回；返回 localhost 的结果也会被过滤。
为google解析的内容引用了Sheas Cealing的规则使其可以在国内访问

部署

搭建这个服务需要准备：

一个 Cloudflare 账号
一个托管到 Cloudflare 的域名
一个 GitHub 账号

部署步骤如下：

Fork 我的项目。

aloneowo0 / Workers-DoH

正在读取仓库简介...

-- --

2. 修改 .env 文件里的内容并保存。如果没有特殊需求，保持默认配置即可。 3. 登录 Cloudflare，进入 Workers 和 Pages，点击创建应用程序。 4. 选择连接到 GitHub，并选择刚刚 Fork 的项目。保持默认配置，直接部署。 5. 绑定一个域名。

设置的域名或子域名尽量不要出现敏感词汇，否则容易被阻断。

等待部署完成后，就可以开始使用了。

使用

目前我确认 Chrome、Firefox 浏览器和 Windows 11 系统都支持配置 DoH。其他客户端是否支持，建议自行测试。

ECH实现的原理

cloudflare的ECH其实是公开的，而且很离谱的是全部ECH的密钥是同一个，更离谱的是cf关闭ECH的方式是把DNS上HTTPS字段的解析里面的ECH给删掉，所以说如果我们通过构建一个带有正确ECH的DNS解析结果就可以实现通过ECH与网站链接

Meta的情况会特殊一点。Meta本身是支持ECH的，但是由于不明的原因ECH没有公布在DNS中，跟cloudflare那些没有公布ECH的网站类似都是不公开ECH。问题是Meta的ECH是独立的，获取会比较麻烦。我在github的一个帖子中看到一个获取的方法，使用的是retry来实现ECH的获取。简单点说是如果你发送一个错误的ECH给服务器，如果服务器收到了会返回一个retry_config让你的浏览器重试，这个retry里面就包含正确的ECH字段，从而获取到正确的ECH。

然后对上述网站进行dns结果重写并注入ECH就可以使用ECH访问了

DNS on aloneowo's blog

有关GFW阻断的个人观察总结

有关GFW阻断的个人观察

前言

声明

DNS 污染

SNI 阻断（RST阻断）

为什么 SNI 阻断比 DNS 污染更难搞

ECH + DoH 的组合

IP 黑洞

一些个人的话（26.7.11）

SuperDoH：基于 Cloudflare Workers 的多上游 DNS over HTTPS 代理，支持ECH和路由注入

搭建一个个人 DoH 服务

前言

DoH 有什么用

项目实现的功能 （推销）

部署

使用

ECH实现的原理

项目实现的功能（推销）