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，抓到请求即证明流量已加密发出
