DNS over HTTPS 也被墙？2026 防火长城限速原理与突破方案
很多人以为"用了加密 DNS 就安全了"。2026 年的实际情况是：加密 DNS 本身也成了防火长城重点"照顾"的对象。DNS over HTTPS（DoH）和 DNS over TLS（DoT）在 2026 年都面临不同程度的干扰和限速。
这篇文章从技术角度讲清楚 GFW 的 DNS 封锁机制——三层递进策略分别做了什么、为什么 ECH 加密也没解决问题、以及现代代理协议如何从根本上绕开 DNS 封锁。
第一层：明文 DNS 污染（经典策略）
这是最基础的 DNS 封锁方式，从 2000 年代就开始运行了。原理很简单：
当你用明文 DNS（UDP 53 端口）查询一个被墙的域名时，DNS 请求在传输过程中是明文的。防火长城会在 DNS 响应到达你之前，抢先返回一个伪造的 DNS 响应，把你的查询指向一个错误的 IP（通常是 0.0.0.0 或一个无法访问的地址）。你的浏览器收到这个假响应直接显示"无法访问此网站"。
这种方法的局限：当你改用加密 DNS 时，GFW 看不懂你的 DNS 请求内容，明文污染自然就失效了。这也是为什么很多人推荐改用 DoH 或 DoT——但在 2026 年这招也不够用了。
第二层：DoT 端口封锁
DNS over TLS（DoT）使用固定的 853 端口。因为端口号是固定的，GFW 直接对所有发往 853 端口的流量进行深度包检测（DPI）。一旦识别出是 DNS 查询流量，直接阻断连接。
这意味着：即使你的 DNS 请求内容是加密的，但只要目标 IP 是已知的公共 DNS 服务器（如 Cloudflare 的 1.1.1.1、Google 的 8.8.8.8）且端口是 853，GFW 在握手阶段就可以识别并阻断。
结果是：2026 年 DoT 在国内基本不可用。越知名的 DNS 服务商被封锁得越彻底。
第三层：DoH 智能限速（2026 年升级重点）
DNS over HTTPS（DoH）比 DoT 更隐蔽——它使用标准的 443 端口，流量混在普通的 HTTPS 流量中，看起来就像正常的网页访问。按理说 GFW 很难区分 DoH 流量和普通 HTTPS 流量。
但 2026 年 GFW 升级了一个策略：智能限速。它不直接封 DoH，而是对发往已知 DoH 服务器的 IP 进行选择性限速。具体来说：
- 单个 DoH 查询请求 → 正常放行
- 短时间内多次 DoH 查询 → 对该 IP 地址启动临时限速
- 限速策略不是完全阻断，而是丢包 + 延迟增加，使 DoH 查询变得极慢
- 限速是动态的，持续一段时间后自动解除，但再次触发又会限速
这种策略的高明之处在于：它不破坏 HTTPS 协议本身，但让 DoH 的实际体验变得很差——一个 DNS 查询要等几秒钟才返回，这在日常使用中几乎不可接受。
为什么 ECH 也没解决问题
ECH（Encrypted Client Hello）是 TLS 协议的一个扩展，用于加密 HTTPS 握手阶段的 SNI（Server Name Indication），防止 GFW 通过 SNI 知道你在访问哪个网站。
ECH 理论上很好，但实践中有一个关键漏洞：ECH 的密钥分发依赖于 DNS。客户端要获取 ECH 密钥，需要进行一次 DNS 查询——而这个 DNS 查询本身如果是明文的，GFW 就可以在 DNS 层面做文章。这是一个先有鸡还是先有蛋的问题：你要加密通信需要 ECH，但获取 ECH 密钥的 DNS 查询又是未加密的。
即使你用 DoH 获取 ECH 密钥，DoH 面临的三层限速同样会影响 ECH 的部署效果。这就是为什么 ECH 被寄予厚望但始终没能普及的原因之一。
真正的突破方案：现代代理协议
加密 DNS 的所有方案（DoH、DoT、DNSCrypt）本质上都是在 DNS 层面做文章——这注定了它们处于劣势，因为 GFW 对 DNS 流量的监控已经深入到了协议级别的检测。
真正有效的方案是：不跟 GFW 在 DNS 层面纠缠，直接使用现代代理协议。
现代代理协议（如 VLESS、Trojan、Hysteria2）做了几件 DNS 协议做不到的事：
- 全流量加密 — 不只是 DNS 查询加密，而是你所有的网络流量都经过加密传输，GFW 根本不知道你在访问什么
- 流量伪装 — 代理流量伪装成普通的 HTTPS 流量，与正常网页访问在特征上无法区分
- DNS 由代理服务端解析 — 你的设备不需要直接向海外 DNS 服务器发起查询，DNS 解析交给代理服务端完成。这完全避开了 GFW 的 DNS 封锁体系
简单类比：DNS 层面的加密像是在信封上做手脚，而现代代理协议是把整封信装进一个谁也无法打开的保险箱里运输。
忍者云如何解决 DNS 封锁
忍者云使用现代代理协议，从三个层面消除 DNS 封锁的影响：
- 服务端 DNS 解析 — 所有 DNS 查询由代理服务端发起，你的设备无需直接连接被干扰的 DNS 服务器
- 协议混淆 — 代理流量伪装为正常 HTTPS 流量，GFW 无法通过流量特征识别和限速
- DNS 防泄漏 — 配置中内置 DNS 防泄漏规则，确保所有 DNS 查询都走代理通道，不会意外走系统默认 DNS 暴露查询内容
常见问题
在国内设置 DoH 还有用吗？
部分有用，但不完全可靠。对于没有被 GFW 重点封锁的域名（不涉及政治敏感或翻墙工具），DoH 基本正常。但对于被 GFW 直接封锁的域名（如 Google、YouTube、Twitter 等），即使用 DoH 正确解析了 IP，IP 本身被封锁了也一样无法访问。
用 1.1.1.1 和 8.8.8.8 现在还行吗？
2026 年，1.1.1.1 和 8.8.8.8 通过明文 DNS（UDP 53）已经基本不可用——响应被污染。通过 DoH（443 端口）偶尔能用但速度不稳定，高峰期经常超时。建议使用国内的公共 DNS（如阿里 223.5.5.5、腾讯 119.29.29.29）作为备用 DNS，然后通过代理通道实现海外访问。
代理协议会不会有一天也被识别？
技术对抗是一个动态过程。GFW 在不断升级，代理协议也在不断演进。2026 年主流协议通过 TLS 指纹伪装、流量混淆等技术已经很难被基于特征的 DPI 检测。更重要的是，代理协议的部署方式天然比 DNS 层面的方案更灵活——协议可以更新、端口可以调整、部署方式可以变化。