开启 3 天免费试用
注册即可免费体验全部高级功能。
*仅限新用户;每位用户只能获得一次试用。


加密 DNS 流量保护设备与解析器之间的查询交换。DNS 帮助把主机名转换成地址,DoH 和 DoT 则为这个过程加入加密传输。它们不会隐藏浏览活动的所有痕迹,也不能消除对解析器的信任要求。[1][2][3]
关键要点
- DNS 加密保护特定连接,不代表所有活动信息都不可见。
- DoH 使用 HTTPS;DoT 使用 TLS,默认端口为 853。
- iOS 警告描述隐私限制,不能单凭提示断定存在特定攻击者。
调整 DNS 时,也应结合账号、设备与网络安全检查清单。
明文 DNS 可能向查询路径上的观察者暴露所请求的域名。加密能减少这种暴露;防范主动攻击时,验证解析器身份同样重要。解析器自身仍然接收查询,IP 地址和其他连接信息也可能在别处可见。[2][3]
DNS 传输保护与网页本身的 HTTPS 加密是不同层面。不能因为出现 DNS 警告,就断言所有网页正文或密码都在被读取。
| 项目 | DoH | DoT |
|---|---|---|
| 规范 | 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]
DoH 或 DoT 没有附带默认拦截策略。解析器可能过滤特定名称,也可能不做过滤、返回普通答案。这是叠加在传输上的服务政策。加密解析器不一定拦广告,过滤解析器也不一定加密客户端连接。[2][3]
本地过滤器只能看到到达它的查询。浏览器使用独立 DoH 提供商时,改路由器 DNS 地址未必影响该浏览器。反过来,本地过滤器也可以把获准查询转发给加密上游,同时保留自己在路径中的位置。先核对真实客户端、过滤点与上游服务,再解释广告变化,不能把它直接当作加密证据。
域名过滤也不能选择性删除与正常内容共用主机名的广告。解析器策略可能阻断整个名称,但 HTTPS 页面内容属于另一层。广告有没有出现、空广告位有没有消失,都不能判断传输保护是否生效。
记录被检查的应用、其解析器策略、系统解析器配置,以及 VPN 路由规则。区分配置偏好与观察到的行为:应用可能使用另一解析器,缓存答案也可能省去新查询。比较设置时,在同一应用里重复同一个无害查询;同时换应用和网络,就失去了这项对照。[6]
DNS 测试页可以识别联系其测试基础设施的递归服务。但仅凭解析器名称,不能看出设备到解析器使用了明文、DoH、DoT 还是 VPN 隧道。解析器变了,不证明其他应用都变了;解析器没变,也不证明加密失败。要判断传输,应将结果与客户端的公开配置说明结合,并在获得授权时核对相关连接或路由证据。
| 观察 | 可以支持的结论 | 还需检查什么 |
|---|---|---|
| 一个浏览器显示不同解析器 | 该测试查询到达另一递归服务 | 系统和其他应用的覆盖 |
| 解析器名称没有变化 | 测试仍观察到同一服务 | 传输与 VPN 路由 |
| 改设置后页面能打开 | 这次请求成功 | 缓存、路径和隐私政策 |
| 内部主机名无法解析 | 新路径可能缺少私有 DNS 数据 | 预期分流 DNS 与所有者配置 |
测试自己有权修改的设置前,保存原值,每次只改一个变量。所需内部名称失效时,通过所属工具恢复原值,并向管理员确认支持的路径。不要仅为消除警告,就用公共提供商替代组织 DNS 策略。
Apple 说明,DNS 解析仍可能正常工作,但查询的名称未经加密,因此可能被网络中的观察者看到。警告本身不能定位原因,也不证明正在发生恶意监控。更改设置前,先确认受影响的是哪个网络,以及由谁管理。[4]
使用多人共享的公共 Wi-Fi时,应区分场所登录门户与隐私设置。不要为了消除提示就安装不明描述文件或证书。
以下检查按所列协议与 Apple 文档整理,未进行完整端到端设备实测。只修改自己拥有或获准管理的设置。
记录网络名称、提示原文,以及换到另一条可信连接后是否仍然出现。比较结果有助于区分特定网络问题与设备层面的配置问题。
Apple 建议检查软件更新和路由器安全设置、重启设备与路由器,并忽略后重新加入 Wi-Fi。只重启自己有权管理的路由器,忽略网络前确认能够重新连接。这些是排查动作,不是必定有效的修复。[4]
自己的路由器应按厂商说明操作,并先保存原有配置。受管理网络应向管理员确认 DNS 策略。不要仅凭未经证实的“内存错乱”说法,就关闭安全控制或重置全部网络设置。
VPN 可以在隧道内承载 DNS,但应用自带解析器和路由仍需分别检查。如果网络政策允许,AethoVPN 可为这项对照提供加密转发。iPhone 或 iPad 应通过官网设置向导取得客户端配置,需要 Pro 或 Premium。
连接前后用同一浏览器重复同一测试,再核对该客户端的 DNS 与路由配置。单凭连接图标或运营商解析器名称,都不能证明每条查询进入隧道,也不能证明查询绕过隧道。这不修复路由器,也不保证受限网络可用。新用户可以用邮箱注册并开始 3 天 Pro 试用。
不能。它保护加密路径上的 DNS 交换,但其他连接信息仍可能可见。解析器自身也仍然接收你要求解析的名称。[2][3]
Smart DNS 这个名称不能证明传输已加密。应检查服务实际使用的解析器协议和配置,不要把路由功能当作 DNS 隐私保护的证据。
连接还能使用,不代表 Apple 所说的隐私限制已经消失。应检查网络情况;若这种暴露不适合当前任务,可考虑改用可信的连接。[4]
不能直接这样推断。应分别检查浏览器、系统和其他应用的设置范围;某个应用选择了加密解析器,不证明整个设备都受保护。
DoT 通常使用 853 端口,防火墙可以单独控制这类连接。使用其他端口需要客户端与服务器共同配置,可用性仍取决于网络策略。[3]
不会。DoH 和 DoT 规定受保护的传输,不规定拦截列表。应检查解析器独立的过滤政策,以及应用查询是否真正到达该服务。
不是。DNSSEC 验证签名 DNS 数据;DoH 或 DoT 保护传输连接。两者可以配合,但不会自动开启对方,也不保证页面内容安全。[5]
**免责声明:**本文提供一般技术信息,使用时应遵守所在网络与设备的管理政策。
来源:
Sources checked 2026 年 10 月 9 日。
延伸阅读:
注册即可免费体验全部高级功能。
*仅限新用户;每位用户只能获得一次试用。