DNS Over HTTPS 详解：隐私保护与公共 WiFi 过滤
DNS over HTTPS 会对端口 443 流量中的查询进行加密。了解它隐藏了哪些内容、为何能绕过 WiFi 过滤，以及网络如何保持控制。
Published 2026年10月26日
DNS over HTTPS 将 DNS 查询嵌入端口 443 的普通 HTTPS 流量中进行传输，在设备与解析器之间实现加密。该技术于 2018 年成为 IETF 标准。
您已经在宾客 WiFi 上启用了内容过滤，但宾客的浏览器仍然打开了您认为已经拦截的类别。防火墙正在运行，网络设置看起来正常，而另一台设备接收到了预期的拦截页面。这里的差异可能在于浏览器请求的是哪个解析器，而不是您的过滤器是否工作正常。
对于场所运营方和 IT 负责人来说，这就是 DoH 的核心问题。它在传输过程中保护查询，但浏览器对目的地的选择也可能将该查询移出您网络的过滤策略之外。
目录
- 通俗解释什么是 DNS over HTTPS
- DoH 查询如何从设备传输到解析器
- 开启 DoH 时谁能看到您的查询
- 为什么 DoH 会削弱共享 WiFi 上的 DNS 过滤
- DoH 的速度成本以及过滤仍能发挥的作用
- 在常见设备上检查并更改 DoH
- 选择并分层配置您的 DoH 控制策略
通俗解释 DNS over HTTPS 的含义
DNS over HTTPS（通常缩写为 DoH）通过加密的网络连接传输 DNS 查询和响应。DNS 解析器是设备用于请求将域名转换为网络地址的服务。
不妨将 DNS 想象成一本电话簿。在建立连接之前，应用程序需要一个地址，尽管它的缓存中可能已经有可用的答案。传统 DNS 通常以可读的形式发送该查询。
明信片是一个生动的比喻：任何经手的人都可以读取上面的信息。DoH 则将查询内容装入密封信封，并使用与普通安全网络流量相同的传输管道进行递送。
比较传输方式，而不仅仅是加密方式
DNS over TLS（即 DoT）同样对信封进行了密封，但使用的是单独标识的交付入口。这使得网络运营商更容易通过其目标端口识别其流量。
IETF 的 RFC 8484 于 2018 年 10 月发布，定义了 DoH 的 HTTPS 交互规范。与传统 DNS 使用的 端口 53 不同，DoH 通常使用 端口 443。
传统 DNS、DNS over TLS 和 DNS over HTTPS 的对比
| 特性 | 传统 DNS | DNS over TLS (DoT) | DNS over HTTPS (DoH) |
|---|---|---|---|
| 传输协议 | UDP 或 TCP | TLS | HTTPS |
| 常用端口 | 53 | 853 | 443 |
| 本地网络是否可读 | 是 | 否 | 否 |
| 按端口是否易于识别 | 是 | 是 | 否，与 Web 流量共享端口 443 |
| 按端口是否易于封锁 | 是 | 是 | 否，无法仅凭端口进行选择性封锁 |
| 标准定义于 | 原始 DNS 规范 | DNS over TLS 规范 | RFC 8484 |
封禁专用的 DNS 端口非常简单。但如果封禁安全网站所使用的端口，则会切断合法的网络流量，因此 DoH 需要更具选择性的控制机制。
加密并不决定什么会被过滤。解析器可以解密传入的 DoH 请求，应用内容或威胁策略，并安全地返回其答案。关键问题在于谁在运营该解析器，以及它遵循的是谁的策略。
在审查安全控制措施时，请随时参考此对比。能够处理传统 DNS 或 DoT 的规则，并不代表会自动生效于 DoH。
DoH 查询如何从设备传输到解析器
快递员在派送包裹前需要具体的地址。同样，除非浏览器本地缓存中已有答案，否则在连接到酒店预订页面之前，它也需要获取目标地址。
此图展示了从浏览器到解析器再返回的完整查询过程。
跟踪请求与响应
浏览器需要一个地址。它会检查自己是否已拥有预订网站的可用答案。如果缓存命中，完全可以避免新的查找，因此本地网络不会看到该操作的 DNS 交互。
构建 DNS 提问。如果需要最新的答案，浏览器会准备一个包含域名信息的查询。此时，问题仍然保存在设备内部，并未在 WiFi 上传输。
选择 DoH 解析器。浏览器为其配置的解析器准备一个 HTTPS 请求。本地网络可以观察到目标地址和连接元数据，但无法直接读取加密 DNS 消息内部的域名。
建立或复用安全连接。如果需要，设备会在发送受保护的请求之前完成 TLS 握手。借助持久 HTTP 连接，后续查询可以复用该连接；网络只能看到加密流量，包括其时间和传输大小。
解析器返回答案。解析器处理该问题并将 DNS 答复放置在加密的 HTTP 响应中。网络可以看到从解析器返回的流量，但看不到答案的可读内容。
浏览器连接到网站。它使用返回的地址开始建立网站连接。本地网络可以观察到这个新的目的地，这与读取之前的 DNS 问题是分开的。
有关缓存和解析的更多详细信息，关于 DNS 查询的作用 的相关解释将寻址过程与网站连接本身分离开来。
确定过滤点
对于需要 DNS 解析的新连接，查找会在页面内容加载之前发生。这使受信任的解析器有机会在浏览器建立连接之前拒绝已被拦截的目标地址。
独立配置的浏览器可以将该决定发送到其他地方。这样场所的解析器就接收不到任何需要评估的请求。
随附的视频提供了另一种了解该流程的方式。
开启 DoH 时谁能看到您的查询
DoH 并不能向所有人隐藏浏览记录。它仅能保护设备与所选解析器之间的普通观察者无法获取 DNS 交互内容，但该解析器必须读取问题才能给出回答。
这种区别在共享 WiFi 上至关重要。访客有理由希望防范本地拦截，而医院或学校则需要确保其安全防护和威胁控制措施依然有效。
DoH 只是改变了你信任谁来处理 DNS 活动；它并没有消除信任某个主体的需求。
将 DNS 可见性与浏览可见性区分开来
该表描述了在没有附加隐私中继、VPN 或拦截系统情况下的普通 DoH 使用方式。读取 DNS 消息与通过其他网络活动推断目的地是不同的能力。
在使用 DoH 时谁可以看到 DNS 查找
| 观察者 | 查看域名 | 查看是否正在使用 DoH | 为什么重要 |
|---|---|---|---|
| 同一 WiFi 上的其他设备 | 否，无法从加密查询中查看 | 极少能通过常规对等访问查看 | DNS 消息的被动读取已被阻止 |
| 场馆或 ISP 网络 | 否，无法在 DoH 交互内部查看 | 通常可以通过发送至已知解析器地址的流量查看 | 本地 DNS 控制无法评估发送到其他地方的查询 |
| 您访问的网站 | 仅限您连接的网站 | 无法仅凭网站连接查看 | 网站不会收到您无关的 DNS 查询 |
| DoH 解析器运营商 | 是，其收到的每个查询 | 是 | 直接连接会将这些查询与您的源地址一并暴露 |
| 浏览器或操作系统厂商 | 仅当其运营解析器或接收相关遥测数据时 | 软件了解其配置模式；厂商报告需要遥测数据 | 软件配置并不等同于自动的厂商可见性 |
解析器并不一定能看到设备发出的每一次查找。另一个应用程序可能会使用不同的解析器，而已缓存的答案可能根本不需要发出查询。它只能看到发送给它的请求。
同样，浏览器厂商并不会仅仅因为提供了浏览器就自动获取 DNS 历史记录。解析器运营、软件设置和遥测数据收集是各自独立的职责。
明确信任决策
对于托管的 Firefox 安装，Mozilla 的 DNS over HTTPS 策略文档 提供了对解析器配置以及用户是否可以更改该配置的控制。这是使浏览器的行为与组织的 DNS 管理要求保持一致的实用方法。
场所或 ISP 仍可能观察到目的地址、连接时间和流量。其他协议元数据也可能有助于识别网站，因此加密的 DNS 查询并不意味着可以匿名浏览。
在批准解析器之前，请先进行简短的信任评估：
- 明确运营商名称。 确定具体由哪家机构接收查询，而不是依赖浏览器的默认标签。
- 阅读保留条款。 检查存储了哪些查询和连接信息、保留多久以及出于什么目的。
- 检查管辖权和访问权限。 了解运营商在何处处理信息以及谁可以获取这些信息。
- 将可见性与责任相匹配。 确定您的 IT 团队需要调查哪些安全事件，以及不应保留哪些浏览细节。
有价值的问题并不是抽象地讨论隐私还是可管理性更重要，而是您所选择的 DNS 路径是否在向用户提供适当保密性的同时，仍能让组织履行其既定的管理职责。
为什么 DoH 会削弱共享 WiFi 上的 DNS 过滤效果
酒店向客人提供前台电话，以便协助寻找本地服务。大多数客人会致电前台，但也有客人使用黄页应用。前台可以控制自己的推荐内容，但无法控制该应用提供的答案。
网络 DNS 的工作原理类似。您的网络提供一个解析器，但如果浏览器配置了自身的 DoH，则可能会向外部服务发起请求。
该插图展示了绕过网络 DNS 服务器的替代路径。
绕过行为与路由路径相关
问题不在于加密查询无法被过滤，而在于如果过滤系统从未接收到该查询，就无法对其应用策略。
在家庭游乐场所的访客网络上，这可能意味着成人内容拦截不适用于特定的浏览器。在员工网络上，恶意应用程序可能会通过未批准的解析器解析指挥与控制（C2）域名。
其后果取决于哪些控制项依赖于 DNS：
- 特定于网络的策略。 分配给 SSID 或 VLAN 的规则不会管辖发送到经批准的解析器路径之外的请求。
- 搜索限制。 基于 DNS 的安全搜索强制执行可能会被绕过，但账户级别或端点限制可能仍然有效。
- 威胁拦截。 DNS 过滤器无法拒绝未看到的查询，即使其威胁列表中包含请求的域名。
一项 加密 DNS 部署的测量研究 报告了 Firefox 的遥测数据，其中在 2025 年期间，9.54 万亿次桌面握手中约有 13.91% 使用了 DoH。它还描述了一个测量数据集，其中 DoH 的普及率约为 DoT 的 6.4 倍。
这些观察结果并不能说明绕过您场所过滤器的设备比例。浏览器默认设置、区域推广、解析器兼容性和管理员策略都会影响 DoH 是否处于激活状态。
测试覆盖率，而非盲目假设
在员工笔记本电脑上成功拦截，并不代表访客的个人手机也能获得同等覆盖。不同设备可能使用不同的浏览器、DNS 设置或加密隧道。
请将您的 WiFi 内容过滤器 视为具有明确流量路径的控制措施。使用访客随身携带的设备和应用程序来测试该路径。
仅依赖网络层提供的解析器进行过滤，默认情况下已无法实现完整覆盖。 这需要补充控制手段，并坦诚评估有哪些流量依然超出策略管辖范围。
DoH 在速度上的代价以及过滤仍能发挥的作用
加密会增加计算负担，但实际问题在于用户是否会察觉到会话变慢。初始连接建立和重复查找的成本不同，因此仅测试单个全新请求可能会产生误导。
一项 DNS 传输协议的实证对比 指出，在其无延迟的本地基准测试中，UDP 和 TLS 的响应时间低于 1 毫秒，而 HTTP/2 始终保持在 10 毫秒以下；下述结果保留了该研究的实验背景，并非用于预测特定场所的网络性能。
引用研究中按协议划分的 DNS 查询延迟
| 协议 | 报告结果 | 上下文 |
|---|---|---|
| UDP | 低于 1 ms | 无延迟的本地基线 |
| TLS | 低于 1 ms | 无延迟的本地基线 |
| HTTP/2 | 持续低于 10 ms | 连接复用和多路复用有助于减少开销 |
| HTTP/1.1 | 波动较大 | 归因于流水线限制 |
| 公共 DoH 与传统 DNS 对比 | 单个名称更慢 | 未观察到整体页面加载时间明显增加 |
评估整个会话，而不仅仅是握手阶段
持久连接允许客户端将建立连接的开销平摊到后续的查询中。多路复用则使其能够处理多个交互，而无需为每个查询单独建立安全连接。
只要请求到达过滤解析器，DNS 过滤仍然可以在新连接开始前拒绝某个域名。广告和追踪器拦截可能会减少后续请求，但仅凭加密本身并不能消除广告或加快页面加载速度。
跟踪能够揭示真实问题的运行信号：
- 握手失败。 查看连接建立错误和重试情况。
- 缓存命中率。 将缓存的响应与全新的解析区分开来。
- 解析程序响应时间。 测量访客会话繁忙期间的表现。
- 回退行为。 检查失败是否会导致设备停止解析或在无通知的情况下切换到另一条路径。
实用规则：将浏览测试、策略实施和故障恢复作为一个整体进行测试，而不是分成独立的验收检查。
相比仅凭延迟假设来选择协议，部署距离近、具备高可用能力的解析器端点是更好的起点。请在真实负载下测试并确认网络性能。
在常见设备上检查并更改 DoH
浏览器设置的不同可以解释为何同一 WiFi 下的设备会有不同表现。菜单名称可能随版本更新而变化，如果未看到下方路径，请使用设置中的搜索功能。
检查浏览器和操作系统
- Chrome: 打开设置 -> 隐私和安全性 -> 安全性，然后找到使用安全 DNS。检查它是跟随当前提供商还是指定了其他服务。
- Firefox: 打开设置 -> 隐私与安全，然后找到 DNS over HTTPS。查看保护模式（包括关闭、默认保护或最大保护）以及选定的解析程序。
- Edge: 打开设置 -> 隐私、搜索和服务 -> 安全性，然后找到使用安全 DNS。管理策略可能会锁定此设置。
- Android: 打开设置 -> 网络和互联网，然后找到私人 DNS。此设置使用 DoT 而非 DoH；浏览器级别的安全 DNS 需要单独检查。
- iOS 和 macOS: 检查已安装的配置文件、设备管理设置和与 DNS 相关的应用。加密的 DNS 配置文件可能会独立于浏览器运行。
验证有效路径
无论浏览器如何设置，系统 VPN 都可以通过自己的隧道传输 DNS。此外，还需检查应用程序是否提供了独立的加密 DNS 服务。
确认实际浏览器或应用发出的新测试查询由哪个解析器接收。使用浏览器诊断或解析器识别测试，配合已批准解析器的日志，而不是仅仅信任设置界面。
选择并分层配置您的 DoH 控制措施
根据设备所有权和策略需求进行分层控制。受管理的员工笔记本电脑可以遵循强制配置；而私人的宾客手机通常无法做到这一点。对这两类群体应用相同的限制，要么会产生可以避免的安全漏洞，要么会导致不必要的网络中断。
您可以允许外部 DoH 并接受本地 DNS 可视性的降低，也可以限制它并承担兼容性风险，或者将托管设备策略与选择性宾客网络控制结合起来。这种分层方法可以让您更清晰地了解哪些内容受到了保护，哪些没有。
将每个控制措施与其实际范围相匹配
网络控制措施非常有用，但它们并不能让每个加密解析器都可被识别。私有解析器、变化的地址或 VPN 隧道可能会打破基于已知服务列表所建立的假设。
共享网络和托管网络上的 DoH 控制项
| 控制措施 | 拦截对象 | 适用位置 | 权衡利弊 |
|---|---|---|---|
| 封锁出站端口 853 | 标准端口 DNS over TLS | 防火墙或网关 | 对普通 HTTPS 上的 DoH 无效 |
| 强制将端口 53 定向至网络解析器 | 明文 DNS 绕过 | 网关强制执行，配合 DHCP 配置支持 | 完全忽略 DoH；仅靠 DHCP 无法强制合规 |
| 封锁已知公共 DoH 解析器地址 | 与已列出解析器的连接 | 防火墙或具备相应能力的网关 | 列表会过期，新的解析器不断出现，部分应用可能会中断 |
| 通过托管策略禁用浏览器 DoH | 受控浏览器中的浏览器层绕过 | 托管笔记本电脑和员工设备 | 无法覆盖访客 WiFi 上的个人手机 |
| 通过 MDM 强制执行网络解析器 | 设备策略所覆盖的未授权 DNS 更改 | 已注册的员工和企业设备 | 需要设备注册和平台支持；访客设备无法覆盖 |
| 接受 DoH 并进行端点过滤 | 网络端无任何拦截 | 仅限托管端点 | 访客设备仍然不受端点策略约束 |
封禁某个解析器的地址可能会误伤托管在该地址上的其他无关服务。请勿将防火墙的加密 DNS 分类库视为永久、详尽的拦截清单。
如果您需要超越域名解析的控制能力，请在评估端点和网络策略的同时评估 安全 Web 网关。请仔细检查部署要求，特别是当设备并非组织所有时。
构建可测试的运营策略
首先明确您需要交付的服务。员工管理网络、公共图书馆连接和儿童活动场所可能合理地需要不同的限制和对不同的用户说明。
请使用此部署清单：
- 列出所需的策略。 确定需要进行内容控制或威胁过滤的 SSID、VLAN 和设备组，并为每个项目指定负责人。
- 将托管设备与访客 BYOD 区分开。 记录哪些位置可以强制执行浏览器策略或 MDM，哪些位置仅提供网络控制。
- 关闭常规 DNS 绕过途径。 在策略需要的地方，阻止出站 DoT 并将传统 DNS 限制为经批准的解析器。覆盖两种受支持的网络地址族。
- 应用托管浏览器策略。 配置经批准的 DNS 路径，并防止在员工设备上发生不受支持的用户重写。
- 维护访客网络解析器限制。 定期审查已阻止的解析器地址，测试例外情况，并删除会导致无法接受的附带拦截的规则。
- 发布通俗易懂的访客须知。 说明已过滤哪些类别、记录了哪些网络信息以及对加密 DNS 或 VPN 使用的任何限制。
- 在每个网络上测试真实设备。 检查允许的网站、拦截的类别、批准的安全测试目的地、解析器故障和 VPN 行为。
上线前须知： 显示拦截页面仅证明特定请求已被过滤，并不代表设备上的所有应用程序都遵循相同的路由规则。
将加密 DNS 纳入验收测试的一部分
要使用 Shield，您需要将网络的 DNS 指向 Shield。我们会为受保护网络上的每台设备回答每一次 DNS 查询，设备上没有任何可以关闭的设置；因此，外部解析器和隧道路径必须包含在网络的保护设计中。
在您试用 Purple Shield 之前，我们的专家会向您展示您的网络如何处理 VPN 和加密 DNS。利用该讨论来确定哪些请求会到达受保护的 DNS 路径，哪些控制措施会强制执行该路径，以及当设备尝试其他路由时会发生什么。
在更改访客接入前请先设定验收标准。相比于假设已启用的过滤器能看到所有内容，拥有经批准的解析器、记录在案的异常处理流程以及可重复的设备测试能提供更坚实的基础。
Purple Shield 提供防护性 DNS、内容过滤、威胁防御和广告拦截功能，无需在宾客设备上安装代理软件。请访问 Purple Shield 安排试用前讨论，以了解您的 SSID、过滤策略以及您的网络如何处理加密 DNS 和 VPN。