macOS DNS-over-HTTPS（DoH）安全配置探讨

macOS 的 DNS-over-HTTPS（DoH）支持自 macOS 12.3 起通过配置描述文件引入，13 版本起支持图形化配置，但仅限兼容端点如 cloudflare-dns.com 或 dns.google；它仅作用于系统框架层（Safari、Mail 等），不影响 dig、curl 等命令行工具，需本地转发器（如 dnscrypt-proxy）才能统一加密终端 DNS 请求。

macOS 对 DNS-over-HTTPS（DoH）的支持不是“开个开关就生效”的简单操作，而是分版本、分路径、分作用域的系统级行为。它不改变终端命令（如 dig 或 curl）的解析逻辑，也不统一接管所有应用的 DNS 请求——只影响系统框架层（如 Safari、Mail、Finder 中的网络访问），这点必须先厘清。

macOS 原生 DoH 支持的真实情况

从 macOS 12.3（Monterey）起，Apple 通过配置描述文件（.mobileconfig）引入 DoH 支持；macOS 13（Ventura）开始，在「系统设置 > 网络 > DNS」中提供图形化添加 HTTPS 地址的入口，但仅限于明确兼容的 DoH 服务端点。

• 系统设置里填入 https://cloudflare-dns.com/dns-query 或 https://dns.google/dns-query 才会生效，填错格式（如带查询参数、用 HTTP、证书不合法）将静默失败
• 旧版本（macOS 12.2 及更早）完全不识别 DoH 配置，即使手动写入配置文件也不会启用
• 成功配置后，「DNS」列表中对应条目旁会出现小锁图标，但协议类型（DoH）不会显示——这是正常设计，不代表未加密

终端与命令行工具为何不走 DoH

macOS 的 DoH 配置只作用于 CFHost 和 NWEndpoint 这类系统网络框架，而 dig 直连 UDP 53，curl 默认调用 libc 的 getaddrinfo()，绕过了系统 DNS 解析器。

• 想让终端命令也走加密 DNS，需额外部署本地转发器（如 dnscrypt-proxy 或 stubby），并把系统 DNS 指向 127.0.0.1
• 验证是否生效不能只看图形界面，应结合 scutil --dns 查看 resolver 配置，并用 curl -v https://1.1.1.1/help 观察响应头中是否含 via: cloudflare 等特征
• Wireshark 抓包时，若看到大量 TLS 流量发往 443 端口且 Host 为 cloudflare-dns.com，说明 DoH 正在工作

DoH 与 DoT 的选择逻辑

DoH 和 DoT 都加密 DNS，但设计目标不同：DoH 走 443 端口，流量混同 HTTPS，抗审查能力强；DoT 走 853 端口，协议更轻量，但易被防火墙识别和拦截。

• 日常家用或公共 Wi-Fi 场景，优先选 DoH——Cloudflare、Google、Quad9 均提供稳定服务，无需额外客户端
• 若需自定义过滤（如广告屏蔽）、日志审计或国内/海外域名分流，dnscrypt-proxy 是更合适的选择，它同时支持 DoH 和 DoT，并可通过 server_names 字段精确指定上游
• 用 stubby 实现 DoT 时，务必关闭系统 IPv6 自动 DNS 获取，否则可能干扰本地监听，导致解析失败

验证与排错的关键动作

配置完成后，别只信界面图标。真实有效性需三层交叉验证：

• 运行 scutil --dns | grep 'DNS Server' -A 5，确认输出中出现 Encrypted: YES 字样
• 访问 https://1.1.1.1/help，页面应显示 “You are using 1.1.1.1 with DNS over HTTPS” 并注明加密状态
• 执行 sudo tcpdump -i any port 443 and host cloudflare-dns.com -c 5，抓到请求即证明流量已加密发出