CLIENTS
先决定配在哪一层（这决定了覆盖面与冲突面），再照平台执行，最后用可复现的方法验证 —— 而不是只看那个开关有没有打开。
这一层的选择比选哪个协议影响更大。配错层会导致「看起来开了，实际只覆盖了一部分流量」。
| 层级 | 覆盖面 | 适合谁 | 要留意 |
|---|---|---|---|
| 路由器 / 网关 | 接在此网关下的所有设备，包括无法单独配置的 IoT | 家庭、小团队 | 需要网关本身支持 DoT/DoH；访客网络通常要单独配；离开该网络即失效 |
| 操作系统 | 该设备上的全部应用（含命令行、后台服务） | 个人主力设备、开发机 | 部分系统版本才有原生 DoH/DoT；企业 MDM 策略可能覆盖你的设置 |
| 浏览器 | 仅该浏览器的流量 | 临时试用、无法改系统的环境 | 最常见的误解：以为开了浏览器 DoH 就等于全局加密 —— 实际上是两条独立的解析路径 |
| 单个应用 | 只该应用 | 特定工具（如自建解析器客户端） | 覆盖最窄，排障时容易忘记它的存在 |
下面的命令与路径以「把系统层指向一个支持加密的解析器」为例。请把示例地址换成你自己的解析器。
新版本已原生支持 DoH，无需装软件。图形界面路径：
设置 → 网络和 Internet → 以太网（或 Wi-Fi）
→ 硬件属性 → DNS 服务器分配 → 编辑
→ 手动 → 打开 IPv4 → 首选 DNS 填解析器 IP
→ 「通过 HTTPS 的 DNS」选「开（自动模板）」命令行查看当前状态（确认是否真的启用了加密）：
netsh dns show encryption注意：Windows 10 早期版本没有这个界面，需要靠第三方客户端（如 dnscrypt-proxy）或升级系统。
命令行改 DNS 服务器（这一步只改地址，不启用加密）：
sudo networksetup -setdnsservers Wi-Fi 1.1.1.1启用 DoH/DoT 需要安装配置描述文件（.mobileconfig），由解析器提供方发布。系统级加密没有对应的命令行开关，这一点常被误解。
校验：scutil --dns 可以看到当前生效的解析器。
现代发行版多由 systemd-resolved 管理解析。编辑 /etc/systemd/resolved.conf：
[Resolve]
# 严格模式：地址后跟 #主机名，用于校验 TLS 证书
DNS=1.1.1.1#cloudflare-dns.com
DNSOverTLS=yes
DNSSEC=allow-downgradesudo systemctl restart systemd-resolved
resolvectl status | grep -A3 "DNS Servers"若把 DNSOverTLS 设为 yes 但 DNS= 只填 IP，证书校验会失败 —— 必须写成 IP#主机名 的形式。opportunistic 则不做校验，安全性弱一些。
Chrome：设置 → 隐私和安全 → 安全 → 使用安全 DNS，可填自定义解析器地址。
Firefox：设置 → 隐私与安全 → 启用基于 HTTPS 的 DNS，支持「最大保护 / 默认保护」两档。
务必记住覆盖面：只影响该浏览器。同机的 curl、系统更新、其它应用仍然走系统解析器。
Chrome 的「最大保护」模式会在解析器不可用时直接失败（不回退明文）；Firefox 的对应选项叫「最大保护」。这两档的区别在排障时很关键。
Android 9 起支持「私人 DNS」（即 DoT）：
设置 → 网络和互联网 → 私人 DNS
→ 填主机名（不是 IP），例如 dns.example.com注意这里要求主机名，因为它靠 TLS 证书校验身份。填 IP 会提示无效。DoH 在 Android 上需要 App 或最新版本的支持。
系统本身不提供图形界面的 DoH/DoT 开关，需要通过描述文件（由解析器提供方或 MDM 发布）安装。
安装后可在 设置 → 通用 → VPN 与设备管理 里看到该配置描述文件。
这是移动端最常见的能力限制：加密 DNS 在 iOS 上基本等同于「装一个描述文件」，无法像桌面端那样随手切换。
「开关打开了」不等于「流量真的走加密了」。下面三种方法由弱到强，建议至少做到第二种。
最弱的一层检查 —— 只能证明解析可用，证明不了加密。
dig example.com +short
resolvectl query example.com如果解析能通，说明基本链路没问题；但如果解析器同时监听明文 53，你看不出它到底用了哪条路径。
用管理员权限抓 DNS 相关端口，同时去访问一个网站：
sudo tcpdump -i any -n 'port 53 or port 853 or port 443'看结果：
这是唯一能直接证伪的方法。不要跳过 —— 前面说的「浏览器只覆盖浏览器」正是靠这一步发现的。
多数公共解析器提供「我看到的你是什么样」的页面，可用来确认协议与来源。例如 Cloudflare 的诊断页会显示是否通过 DoH/DoT 连接。
优点是快；缺点是只能反映该解析器视角，且需要信任它给出的结论。适合作为前两种方法的补充，不宜作为唯一依据。
port 53 的 v4 与 v6。都来自「配置看起来成功但行为不如预期」这一类问题，排障成本很高。
| 现象 | 原因 | 怎么确认 |
|---|---|---|
| 某些应用能加密，另一些仍是明文 | 只配了浏览器层，覆盖面本来就只到浏览器 | tcpdump 看是否有 53 端口流量 |
| 配置后打不开内网域名 | 加密解析器不认识你的内部域名，且没有回退 | dig 内网域名看返回是 NXDOMAIN 还是超时 |
| 解析明显变慢 | 严格模式下的证书校验、或解析器距离较远 | 对比切换前后的首次查询耗时（注意清缓存） |
| 切换网络后加密失效 | 配置绑定了特定网络适配器（Windows 常见） | 换网络后重跑一次抓包验证 |
其中「打不开内网域名」最常见，也最容易被误判为加密 DNS 本身有问题。 解决办法通常是让解析器支持条件转发：内网域名走内网 DNS、其余走加密解析器。 自建解析器（见部署实践）可以精确控制这个分流。
配好了，接着是「怎么长期维护」与「出问题怎么查」。