什么是加密 DNS 流量?DoH、DoT 与网络拦截警告

什么是加密 DNS 流量?DoH、DoT 与网络拦截警告

Marcus Reid
2026年4月6日· 更新于 2026年10月9日· 7 分钟阅读

加密 DNS 流量保护设备与解析器之间的查询交换。DNS 帮助把主机名转换成地址,DoH 和 DoT 则为这个过程加入加密传输。它们不会隐藏浏览活动的所有痕迹,也不能消除对解析器的信任要求。[1][2][3]

关键要点

  • DNS 加密保护特定连接,不代表所有活动信息都不可见。
  • DoH 使用 HTTPS;DoT 使用 TLS,默认端口为 853。
  • iOS 警告描述隐私限制,不能单凭提示断定存在特定攻击者。

调整 DNS 时,也应结合账号、设备与网络安全检查清单。

加密 DNS 流量保护什么?

明文 DNS 可能向查询路径上的观察者暴露所请求的域名。加密能减少这种暴露;防范主动攻击时,验证解析器身份同样重要。解析器自身仍然接收查询,IP 地址和其他连接信息也可能在别处可见。[2][3]

DNS 传输保护与网页本身的 HTTPS 加密是不同层面。不能因为出现 DNS 警告,就断言所有网页正文或密码都在被读取。

DoH 与 DoT 有什么区别?

项目DoHDoT
规范RFC 8484 [2]RFC 7858 [3]
传输方式通过 HTTPS 承载 DNS通过 TLS 承载 DNS
常用端口HTTPS 默认端口 443默认端口 853
部署时检查哪个应用使用哪个解析器解析器、身份验证模式与网络策略

DoH 可以共享 HTTPS 基础设施,但这不是无法被过滤的保证。DoT 的专用默认端口则便于单独实施端口策略。两份标准都不能证明某个协议始终更快:连接复用、具体实现和解析器位置都会影响结果。

即使 DNS 已加密,本地网络仍可能看到解析器连接的 IP 地址、交换时间和流量大小。随后连接网站时,目标 IP 也可能可见;共用 IP 不足以还原确切的页面 URL。DoH 与 DoT 不加密全部应用流量,因此 DNS 隐私与后续连接隐私需要分别判断。[6]

解析器信任还存在于哪里?

应用可能询问操作系统的解析器,也可能直接联系自己的解析器。所选递归服务可以从缓存回答、转发请求,或查询权威 DNS 层级。加密设备到解析器这一段,不会自动加密之后的每次交换。描述观察者能看到什么之前,要先确定加密连接在哪里终止。[6]

图中分开三次交换:客户端通过 DoH 或 DoT 询问递归解析器,解析器按需要取得 DNS 数据,客户端随后通过 HTTPS 连接网站。缓存答案可能省去新的上游查询。这是协议模型,不是这台设备的测量结果,也不表示所有解析器都会加密上游交换。

递归解析器能看到提交给它的名称,并可能将请求与可取得的客户端信息关联。加密传输转移信任边界,不消除它。检查运营方的保留与处理政策,以及服务是否把查询转发给其他提供商。熟悉的供应商名称或一次成功的 TLS 连接,本身不能证明没有保存记录。[6]

DNSSEC 回答另一个问题:签名 DNS 数据能否按信任链通过验证。它提供来源认证与完整性,不提供查询保密。执行验证的解析器可以同时使用 DNSSEC 和 DoH 或 DoT,但连接加密不代表验证已开启,未签名域名也不会因请求使用 HTTPS 就变成已签名。两种机制都不认证网站安全。[5]

加密 DNS 包含广告拦截吗?

DoH 或 DoT 没有附带默认拦截策略。解析器可能过滤特定名称,也可能不做过滤、返回普通答案。这是叠加在传输上的服务政策。加密解析器不一定拦广告,过滤解析器也不一定加密客户端连接。[2][3]

本地过滤器只能看到到达它的查询。浏览器使用独立 DoH 提供商时,改路由器 DNS 地址未必影响该浏览器。反过来,本地过滤器也可以把获准查询转发给加密上游,同时保留自己在路径中的位置。先核对真实客户端、过滤点与上游服务,再解释广告变化,不能把它直接当作加密证据。

域名过滤也不能选择性删除与正常内容共用主机名的广告。解析器策略可能阻断整个名称,但 HTTPS 页面内容属于另一层。广告有没有出现、空广告位有没有消失,都不能判断传输保护是否生效。

哪些证据说明使用了预期路径?

记录被检查的应用、其解析器策略、系统解析器配置,以及 VPN 路由规则。区分配置偏好与观察到的行为:应用可能使用另一解析器,缓存答案也可能省去新查询。比较设置时,在同一应用里重复同一个无害查询;同时换应用和网络,就失去了这项对照。[6]

DNS 测试页可以识别联系其测试基础设施的递归服务。但仅凭解析器名称,不能看出设备到解析器使用了明文、DoH、DoT 还是 VPN 隧道。解析器变了,不证明其他应用都变了;解析器没变,也不证明加密失败。要判断传输,应将结果与客户端的公开配置说明结合,并在获得授权时核对相关连接或路由证据。

观察可以支持的结论还需检查什么
一个浏览器显示不同解析器该测试查询到达另一递归服务系统和其他应用的覆盖
解析器名称没有变化测试仍观察到同一服务传输与 VPN 路由
改设置后页面能打开这次请求成功缓存、路径和隐私政策
内部主机名无法解析新路径可能缺少私有 DNS 数据预期分流 DNS 与所有者配置

测试自己有权修改的设置前,保存原值,每次只改一个变量。所需内部名称失效时,通过所属工具恢复原值,并向管理员确认支持的路径。不要仅为消除警告,就用公共提供商替代组织 DNS 策略。

iOS 的加密 DNS 警告意味着什么?

Apple 说明,DNS 解析仍可能正常工作,但查询的名称未经加密,因此可能被网络中的观察者看到。警告本身不能定位原因,也不证明正在发生恶意监控。更改设置前,先确认受影响的是哪个网络,以及由谁管理。[4]

使用多人共享的公共 Wi-Fi时,应区分场所登录门户与隐私设置。不要为了消除提示就安装不明描述文件或证书。

排查 iOS 警告的四项检查

以下检查按所列协议与 Apple 文档整理,未进行完整端到端设备实测。只修改自己拥有或获准管理的设置。

1. 记录受影响的连接

记录网络名称、提示原文,以及换到另一条可信连接后是否仍然出现。比较结果有助于区分特定网络问题与设备层面的配置问题。

2. 从官方支持的维护操作开始

Apple 建议检查软件更新和路由器安全设置、重启设备与路由器,并忽略后重新加入 Wi-Fi。只重启自己有权管理的路由器,忽略网络前确认能够重新连接。这些是排查动作,不是必定有效的修复。[4]

3. 核对网络所有者的设置

自己的路由器应按厂商说明操作,并先保存原有配置。受管理网络应向管理员确认 DNS 策略。不要仅凭未经证实的“内存错乱”说法,就关闭安全控制或重置全部网络设置。

4. 验证实际受保护的路径

VPN 可以在隧道内承载 DNS,但应用自带解析器和路由仍需分别检查。如果网络政策允许,AethoVPN 可为这项对照提供加密转发。iPhone 或 iPad 应通过官网设置向导取得客户端配置,需要 Pro 或 Premium。

连接前后用同一浏览器重复同一测试,再核对该客户端的 DNS 与路由配置。单凭连接图标或运营商解析器名称,都不能证明每条查询进入隧道,也不能证明查询绕过隧道。这不修复路由器,也不保证受限网络可用。新用户可以用邮箱注册并开始 3 天 Pro 试用。

总结

  • 分清 DNS 传输保护、解析器信任和网页内容加密。
  • 按实际配置比较 DoH 与 DoT,不依赖笼统的速度或隐蔽性保证。
  • 结合网络所有者的信息和官方设备指引排查 iOS 警告。

常见问题(FAQ)

加密 DNS 能向 ISP 隐藏所有活动吗?

不能。它保护加密路径上的 DNS 交换,但其他连接信息仍可能可见。解析器自身也仍然接收你要求解析的名称。[2][3]

Smart DNS 能代替 DoH 或 DoT 吗?

Smart DNS 这个名称不能证明传输已加密。应检查服务实际使用的解析器协议和配置,不要把路由功能当作 DNS 隐私保护的证据。

可以忽略 iOS 警告吗?

连接还能使用,不代表 Apple 所说的隐私限制已经消失。应检查网络情况;若这种暴露不适合当前任务,可考虑改用可信的连接。[4]

浏览器里的 DoH 设置会覆盖所有应用吗?

不能直接这样推断。应分别检查浏览器、系统和其他应用的设置范围;某个应用选择了加密解析器,不证明整个设备都受保护。

为什么 DoT 可以按端口被过滤?

DoT 通常使用 853 端口,防火墙可以单独控制这类连接。使用其他端口需要客户端与服务器共同配置,可用性仍取决于网络策略。[3]

加密 DNS 会自动拦广告吗?

不会。DoH 和 DoT 规定受保护的传输,不规定拦截列表。应检查解析器独立的过滤政策,以及应用查询是否真正到达该服务。

DNSSEC 与加密 DNS 是同一回事吗?

不是。DNSSEC 验证签名 DNS 数据;DoH 或 DoT 保护传输连接。两者可以配合,但不会自动开启对方,也不保证页面内容安全。[5]

**免责声明:**本文提供一般技术信息,使用时应遵守所在网络与设备的管理政策。

来源:

  1. Cloudflare: What is DNS?
  2. IETF: RFC 8484 - DNS Queries over HTTPS (DoH)
  3. IETF: RFC 7858 - Specification for DNS over Transport Layer Security (TLS)
  4. Apple Support: Recommended settings for Wi-Fi routers and access points
  5. IETF: RFC 4033 - DNS Security Introduction and Requirements
  6. IETF: RFC 9076 - DNS Privacy Considerations

Sources checked 2026 年 10 月 9 日。


延伸阅读:

开启 3 天免费试用

注册即可免费体验全部高级功能。

*仅限新用户;每位用户只能获得一次试用。

什么是加密 DNS 流量?DoH、DoT 与网络拦截警告 | AethoVPN