加密DNS实战：DoH/DoT多平台配置、验证与避坑

上周在一家咖啡馆连着公共 Wi-Fi 改稿，浏览器突然开始往我打开的每一个页面里塞弹窗广告，连一个纯静态的文档站都没能幸免。第一反应是浏览器被装了插件，翻了一遍扩展列表干干净净；第二反应才想起来，那台笔记本的 DNS 查询当时是明文的。也就是说，我访问了哪些域名、查了哪些子域，全都清楚地摆在链路上每一个转发节点面前，只要有人愿意，随时能看，也随时能改。这就是所谓的"裸奔"——不是你的网页内容没加密，而是你在开口问路的那一刻，就已经把目的地报给了所有人。

这件事之后我花了一个周末，把手上四台设备全部换成了加密 DNS：Windows 笔记本、MacBook、iPhone、安卓主力机。DoH（DNS over HTTPS）和 DoT（DNS over TLS）这两个词听着唬人，本质就一件事——把原本明文传输的域名查询请求，塞进一条加密通道里发出去。它解决的问题很具体：查询内容不被旁路看到，返回结果不被中途篡改。它解决不了的问题同样具体，后面会单独拿一节讲清楚，免得有人配完之后产生不切实际的期待。

下面这套流程是我自己跑通并且长期在用的：Windows 11 的原生开关加命令行、macOS 和 iOS 的描述文件下发、安卓的一行主机名。刚听说这两个词的新手照着抄能跑起来；已经配过但总觉得哪里不对劲的，中间关于 ECS 和强制门户的那几段大概能解释你的困惑。

1. 把 DoH 和 DoT 拆开看：加密的到底是哪一段

1.1 一次普通的域名查询，路上经过了谁

很多人以为上网是"浏览器直接连网站"，实际上中间隔着一层问路的过程。你在地址栏敲下一个域名，操作系统先查本地缓存，没有就发给配置好的 DNS 服务器；这个服务器如果也没缓存，就一层层往上问，直到拿到最终的 IP 地址返回给你。整个过程中，查询报文走的是 UDP 53 端口，内容是纯文本，没有任何加密。

问题就出在这。这段明文查询要经过你家的路由器、楼道里的交换机、运营商的大小节点，最后才到递归服务器。链路上任何一个环节，都能看到"这台设备在查这个域名"，也都能把这个查询的返回结果替换成别的 IP。公共 Wi-Fi 是最典型的场景——网关设备完全可以对所有经过的 DNS 查询做统一改写，把你导向一个挂满广告的镜像页，而你从浏览器地址栏上看不出任何异常。

我在那次咖啡馆事件之后做过一次简单复现：在自己搭的测试环境里，把局域网网关的 DNS 响应做了一层改写，结果所有设备的浏览器都被引导到了指定页面，而设备本身没有任何报错提示。这就是明文 DNS 最要命的地方——它不仅是"能被看见"，更是"能被悄悄改掉且不留痕迹"。

1.2 DoT 和 DoH 的封装差异，以及我为什么日常优先用 DoH

两种协议的目标一致，实现路径不同。

DoT 走的是独立的 TCP 853 端口，在 TCP 之上套一层 TLS，然后把原来的 DNS 报文原封不动塞进去，只在前面加一个两字节的长度前缀。因为它保留了 DNS 原生的报文结构，所以行为最接近传统 DNS，改造量最小，服务端实现也最简单。

DoH 则把 DNS 查询包装成一个标准的 HTTPS 请求，走 443 端口。查询报文经过 base64url 编码后放在 URL 的?dns=参数里，或者直接作为 POST 的请求体。对网络设备来说，这看起来就是一次普通的网页访问。

两者的取舍我用一张表说清楚：

我自己的习惯是：桌面端优先 DoH，因为 Windows 原生只认 DoH，而且 443 端口在各种网络环境里通过率最高；移动端优先 DoT，因为安卓的私人 DNS 只支持 DoT，一行主机名填完就完事，不需要装任何东西。Apple 设备两者都支持，我在描述文件里通常写 DoH，理由是它和系统里其他 HTTPS 流量共用连接池，切换网络后的重连更快。

还有一个常被忽略的细节：DoT 的主机名必须走 SNI 扩展，而按照 TLS 的规范，SNI 里不允许填 IP 地址。所以你在配 DoT 的时候，填的必须是服务商提供的域名，不能图省事直接写 IP。DoH 相对宽松一些，端点里写 IP 也能工作，但前提是服务端证书的 SAN 列表里包含了这个 IP，否则证书校验会直接失败。

1.3 加密 DNS 管不到的三件事，别抱错期待

第一，它不隐藏你要访问的目标。TLS 握手阶段的 SNI 字段默认是明文的，链路中间照样能看到你在连哪个域名，除非对方启用了更进一步的加密扩展。加密 DNS 保护的是"问路"这个动作，不是"走路"这个动作。

第二，它不加密后续的应用流量。你访问一个 HTTP 站点，页面内容依然是明文；你访问 HTTPS 站点，内容加密靠的是 TLS，跟 DNS 加不加密没有关系。这两件事经常被混为一谈。

第三，它不是网络管理策略的对手。在一些有明确管理规定的网络环境里硬上，只会让后续排查变得更麻烦，还可能被安全审计系统标记成异常行为。加密 DNS 的定位是隐私保护和防篡改，不是用来跟网络管理员捉迷藏的。这一点我在下面讲企业内网那一段还会再提一次。

2. 服务端怎么挑：三个维度加一份能直接用的地址清单

2.1 我挑上游服务的三个真实标准

选加密 DNS 服务商这件事，很多人只看"哪个名气大"，实际上真正影响体验的是三个维度。

延迟。加密 DNS 相比明文的第一个代价就是首包变慢，因为要先完成 TCP 和 TLS 握手。所以物理距离和网络路径直接决定了你打开网页时那零点几秒的体感。我的做法是先 ping 一遍候选地址，挑 RTT 最低的两三个，再实际配置跑一天看看。

日志策略。加密 DNS 解决的是"链路上被人看"，但服务商本身是能看到你所有查询的。所以选的时候要看对方公开的日志留存说明：记录不记录、记录多久、是否做聚合脱敏。这一点没有技术手段能帮你验证，只能看对方的公开承诺，所以我的建议是不要把全部信任押在单一服务商上。

ECS 支持。这是最容易被忽略但又最影响实际体验的一项。ECS 指的是 EDNS Client Subnet，简单说就是查询请求里带上你的大致网段信息，让 CDN 的权威服务器能把你调度到最近的内容节点。大多数加密 DNS 服务商为了隐私，默认不带 ECS。好处是你的网段信息不外泄，坏处是 CDN 只能按递归服务器的位置来调度，你可能会被分到一个物理上很远的节点，视频加载和静态资源下载就会明显变慢。

2.2 常用公共解析地址速查表

下面这张表是我自己整理的，IP 和端点都是实际可用的形式。DoH 端点统一写成 IP 形式，方便直接填进系统设置；DoT 因为前面说的 SNI 限制，需要填主机名，具体主机名到服务商的帮助页查一下就有，通常和它的 DoH 域名同域。

A 到 D 是国际服务，延迟看你的出口线路，优势是国外站点解析准确；E 和 F 是国内服务，访问国内站点延迟低，但它们对国外域名的解析结果未必最优；G 是传统明文服务，放在这里只是让你知道它没有加密能力，别白费劲去配。

我自己的常用组合是：日常主用 E 或 F 里的一个，因为大部分访问都在国内；遇到需要访问国外资源时，不切 DNS，而是接受那一点点绕路。切来切去反而容易出问题，而且切换过程中缓存全部失效，头几分钟体验极差。

2.3 端口和证书这两道硬门槛，配之前先确认

853 端口能不能通。DoT 用独立端口，这是它的优点也是它的软肋。一些网络环境会限制非标准端口的外连，表现就是配置填完之后一直显示"无法连接"。这个在移动网络下比在家庭宽带上更常见。判断方法很简单，用任意支持 DoT 的客户端试一下，或者直接 telnet 到目标的 853 端口看能不能建连。

证书 SAN 里有没有你填的那个名字。DoH 端点如果写的是域名，证书校验通常没问题；如果写的是 IP，就必须确认证书的 SAN 列表里包含这个 IP。1.1.1.1、8.8.8.8、9.9.9.9 这类地址的证书都是带 IP SAN 的，可以放心填。但有些服务商的 DoH 端点只支持域名形式，填 IP 会直接报证书错误，这种情况就得换成域名写法，同时还得保证系统能先解析出这个域名——这就是典型的先有鸡还是先有蛋，所以描述文件里通常要同时写ServerAddresses。

系统时间。这一条听起来很基础，但真的有人栽在上面。证书有效期校验依赖系统时间，设备时间偏差过大，所有 TLS 握手都会失败，表现就是配了加密 DNS 之后全网络瘫痪。配之前顺手看一眼时间对不对，能省掉半小时的排查。

3. Windows 和 macOS：两条完全不同风格的实现路径

3.1 Windows 11 的原生 DoH，图形界面和命令行各有一套

Windows 11 从 21H2 开始把 DoH 做进了系统，这是桌面端最省事的方案，不需要装任何第三方软件。

图形界面的路径是：设置 > 网络和 Internet > 以太网（或 Wi-Fi）> 硬件属性里的 DNS 服务器分配 > 编辑 > 改成手动 > 打开 IPv4 > 填首选 DNS > 在下面那个"通过 HTTPS 的 DNS"下拉框里选"开（手动模板）"，然后填入端点地址。填完之后保存，重新连一下网络。

命令行我更推荐，因为可以批量、可以记录、可以回滚。管理员权限的 CMD 里执行：

netsh dns add encryption server=1.1.1.1 dohtemplate=https://1.1.1.1/dns-query autoupgrade=yes udpfallback=no

参数解释一下：autoupgrade=yes表示当系统发现这个服务器支持 DoH 时自动升级为加密查询；udpfallback=no表示加密失败时不要偷偷降级回明文——这个参数很关键，如果你要的是"要么加密要么断"，就设成 no，如果你更在意"能用就行"，就设成 yes。我个人的选择是 no，因为我需要知道加密到底有没有生效，悄悄降级回明文等于白配。

查一下配好没有：

netsh dns show encryption server=1.1.1.1

PowerShell 里也有一套等价的命令，功能更全：

Add-DnsClientDohServerAddress -ServerAddress 1.1.1.1 -DohTemplate https://1.1.1.1/dns-query -AllowFallbackToUdp $false -AutoUpgrade $true Get-DnsClientDohServerAddress

Get-DnsClientDohServerAddress会列出系统里所有已知的 DoH 服务器配置，包括内置模板和你手动加的那些。想删掉就用Remove-DnsClientDohServerAddress -ServerAddress 1.1.1.1。

注意一点：netsh dns这套命令和Add-DnsClientDohServerAddress这套 cmdlet 只在 Windows 11 和对应的服务器版本上存在。Windows 10 上敲这两条命令会直接报"命令不存在"，不是你拼错了，是系统真没有。

3.2 Windows 10 缺这个开关，只能绕道

Windows 10 的情况比较尴尬。系统层面没有开放 DoH 的配置入口，虽然底层组件在某个版本之后其实已经具备能力，但官方没给用户开关。这时候有三条路。

第一条是浏览器内置的安全 DNS。Chrome、Edge、Firefox 都有这个选项，打开之后浏览器自己的域名查询会走加密通道。缺点是只管浏览器，系统更新、其他应用、命令行工具全都还是明文，属于半吊子方案。但对大部分人来说，浏览器是主要的上网入口，这个方案的性价比其实不低。

第二条是在路由器上统一做。只要路由器固件支持自定义上游 DoH/DoT，配置一次，全家所有设备全部生效，包括那些你根本没法改设置的智能家居设备。这是我最推荐的方案，前提是你的路由器支持。

第三条是装第三方系统级客户端，把本地 53 端口的查询接住再转发到加密通道。这个方案能覆盖全系统，但多了一层常驻进程，出问题时排查链路变长，我不太喜欢在主力机上用。

3.3 macOS 用描述文件下发，比在界面上找按钮可靠

macOS 的系统设置里没有 DoH 的图形开关，想配置只能靠描述文件。听起来麻烦，实际上一旦写好模板，后面换机器、换服务商都只是改两行的事。

描述文件本质是一个 XML 格式的 plist，核心字段是DNSSettings这一段。完整示例如下，保存成doh.mobileconfig：

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>PayloadContent</key> <array> <dict> <key>PayloadType</key> <string>com.apple.dnsSettings.managed</string> <key>PayloadIdentifier</key> <string>local.encrypteddns.dns</string> <key>PayloadUUID</key> <string>6F1C2A84-3B7D-4E19-9C55-2D8A0E7B1F30</string> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadDisplayName</key> <string>Encrypted DNS</string> <key>DNSSettings</key> <dict> <key>DNSProtocol</key> <string>HTTPS</string> <key>ServerURL</key> <string>https://1.1.1.1/dns-query</string> <key>ServerAddresses</key> <array> <string>1.1.1.1</string> <string>1.0.0.1</string> </array> </dict> </dict> </array> <key>PayloadType</key> <string>Configuration</string> <key>PayloadIdentifier</key> <string>local.encrypteddns.profile</string> <key>PayloadUUID</key> <string>9A3E7C11-58B2-4F60-8D0E-1C4B6A92D753</string> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadDisplayName</key> <string>Encrypted DNS Profile</string> <key>PayloadOrganization</key> <string>Local</string> </dict> </plist>

几个容易出错的地方值得单独拎出来说。

DNSProtocol这个字段，DoH 就写HTTPS，DoT 就写TLS。写 DoT 的时候不需要ServerURL，改成ServerName字段填主机名。

ServerAddresses这一组是必需的，不能省。它的作用是让系统在还没建立起加密连接的时候，知道该往哪个 IP 发包去做初始握手。如果只写ServerURL而不写ServerAddresses，系统得先解析ServerURL里的域名，这就绕回去了。

PayloadUUID在整个设备上必须唯一。手工写的时候最容易犯的错就是复制模板时忘了改，两个描述文件的 UUID 撞了，安装会直接失败，报错还特别含糊。我的做法是每次生成都用uuidgen重新出一组。

安装走命令行最干脆：

sudo profiles install -path ./doh.mobileconfig

装完验证一下：

profiles show -type configuration

这条命令会列出当前生效的所有配置描述文件。想撤掉就sudo profiles remove -identifier local.encrypteddns.profile。macOS 11 及以上都支持这套机制，更早的版本不认com.apple.dnsSettings.managed这个 payload 类型，会静默忽略。

4. iOS 和安卓：一个描述文件，一行主机名

4.1 iOS 描述文件和 macOS 是同一份东西

前面那段 XML 原封不动就能用在 iOS 上，前提是系统版本在 iOS 14 及以上。区别只在安装方式：macOS 上你可以直接命令行装，iOS 上得把文件传到手机上。

传输渠道有三个：隔空投送、邮件附件、本地起一个临时 HTTP 服务让手机访问下载。我平时用隔空投送，最快。传过去之后手机会提示"已下载描述文件"，回到设置首页顶部就能看到那个入口，点进去、安装、输锁屏密码，两分钟搞定。

安装完成后不会有任何弹窗告诉你"DNS 已加密"，这是最容易被误判成没成功的地方。验证方法我放在第五节详细讲。

撤销同理：设置 > 通用，往下找到描述文件相关的管理入口，选中那个描述文件移除。移除的瞬间 DNS 就回到系统默认，所以不用担心留下什么残留。

一个实际踩过的坑：如果你在 iOS 上同时装了多个com.apple.dnsSettings.managed类型的描述文件，系统只会生效其中一个，具体生效哪个没有明确的优先级文档，表现就是"配了但好像没完全生效"。装之前先看一眼设备上是不是还留着以前测试留下的旧描述文件。

4.2 安卓的私人 DNS，一行主机名背后跑的是 DoT

安卓这条路最简单，从安卓 9 开始系统就内置了支持，不需要装任何东西、不需要装证书、不需要描述文件。

路径是：设置 > 网络和互联网 > 私人 DNS（有些定制系统叫"私人 DNS 提供商主机名"），选"指定提供商主机名"，然后填一个主机名。

填的时候有两个细节：第一，不要带tls://前缀，也不要带端口号，直接填域名本身，系统会自动用 853 端口建立 DoT 连接；第二，这里只能填主机名不能填 IP，原因前面讲过，SNI 不允许是 IP。

填完之后系统会立刻尝试建立连接并做一次测试查询。成功的话状态会显示为已连接，失败的话会直接提示"私人 DNS 服务器无法访问"。

这里有个必须提前知道的事：私人 DNS 一旦配错，表现不是"加密没生效"，而是整台手机完全无法上网——因为所有域名都解析不了。我第一次配的时候填错了一位字符，手机连着 Wi-Fi 但所有 App 都转圈，排查了十分钟才想起来是自己刚改的设置。所以配之前先把设置路径记住，出问题立刻改回"自动"。

安卓的"自动"模式值得单独说一句。这个模式下，系统会在网络支持时自动尝试用 DoT，不支持就退回明文。听起来很美好，但实测下来它的行为不太可预测——同一个网络下不同时间可能表现不一样。我一般直接选"指定提供商主机名"，行为明确，出问题也容易定位。

4.3 移动端切网和休眠后的三个典型状态问题

移动设备和桌面最大的差别在于网络状态一直在变，加密 DNS 的长连接维护因此麻烦得多。

切换网络后的重连延迟。从 Wi-Fi 切到蜂窝网络，原来那条加密连接就断了，新的连接要重新握手。这个过程中前几个域名查询会有明显延迟，表现就是你切完网络立刻打开浏览器，会白屏一小会儿。这是正常现象，不是配置错误。

息屏休眠后长连接被回收。系统为了省电会把后台连接断掉，唤醒后第一次查询又要重新握手。有些系统版本上这个重建过程不够快，会导致推送延迟或者首次打开 App 时网络请求超时。这个我没找到特别好的解法，只能接受。

强制门户页面出不来。这是最影响实际使用的一个问题。酒店、机场、连锁咖啡店的 Wi-Fi，连上之后要靠一个认证页面让你点同意，而这个页面能不能弹出来，依赖系统对特定域名的明文探测。你开了加密 DNS 之后，探测请求走了加密通道，网关的设备可能识别不了，认证页面就弹不出来，结果就是你连上了 Wi-Fi 但上不了网。我的处理方式是：到这类场所先把私人 DNS 改成"自动"或关掉，认证完再改回来。

5. 怎么确认它真生效了，以及出问题怎么退回来

5.1 三条不用装额外软件的验证手段

第一条，直接用 curl 打 DoH 端点。这条能验证端点本身可不可达、证书对不对、返回格式对不对：

curl -s -H 'accept: application/dns-json' 'https://1.1.1.1/dns-query?name=example.com&type=A'

正常返回是一段 JSON，里面有Status、Answer这些字段。如果返回的是证书错误，说明端点 IP 不在证书 SAN 里；如果超时，说明 443 被拦了。

第二条，抓包看还有没有明文查询。这是最直观的验证方式，比任何界面提示都可信：

sudo tcpdump -ni any 'udp port 53' -c 20

执行完这条命令之后去浏览器里打开几个新网站，如果终端里一个包都没抓到，说明明文查询确实停了；如果还在哗哗地往外发，那就是加密没生效，或者只有部分应用走了加密。

Windows 上可以用pktmon或者直接装个抓包工具，思路一样。

第三条，看系统的状态输出。Windows 上用Get-DnsClientDohServerAddress看配置有没有落下，再去事件查看器里翻 DNS Client 的操作日志，看看有没有连接失败的记录。macOS 上可以log stream --predicate 'process == "mDNSResponder"'观察解析器行为。iOS 上没有公开的查看手段，只能靠抓包间接判断。

需要提醒的是，nslookup和dig这类工具在很多系统上会自己做解析或者走 TCP 直连，它们的结果不能作为"系统 DNS 是否加密"的依据。我见过有人在终端里敲nslookup看返回正常就以为配好了，实际上那次查询根本是命令行工具自己发的明文包。

5.2 故障对照表：这些现象分别对应什么问题

5.3 我的固定操作顺序：先留退路再动手

这套顺序是我踩过几次坑之后固定下来的，看起来啰嗦，但真出事的时候能省下大量时间。

第一步，把当前正在用的 DNS 地址记下来，最好是截图。恢复的时候你会需要它。

第二步，确认自己有权限改回去。桌面端要求你有管理员权限，移动端要求你知道锁屏密码，安卓要求你能进设置。这些前提不成立的时候千万别动手。

第三步，优先用描述文件而不是手工点选。描述文件的好处是移除即恢复，不会留下一堆散落在各处的配置项；手工点选最容易出现的是改了一半忘了改回去，最后自己都说不清当前是什么状态。

第四步，一次只改一台设备。四台机器同时改，出问题的时候你连用哪台去查资料都不知道。我现在的习惯是先改一台备用机，跑两天没问题再推到主力设备上。

6. 跑起来之后才发现的几件事：性能、兼容和边界

6.1 首包慢、后续快，连接复用才是性能关键

加密 DNS 的性能账要分开算。首次查询的耗时构成是：TCP 三次握手 + TLS 握手 + HTTP 请求 + DNS 查询，加起来通常比明文 UDP 查询多出一百到两百毫秒。这个延迟在打开一个新网站时能感觉到，尤其是那种要连续解析十几个域名的页面。

但连接一旦建立起来，后续查询就可以复用这条连接，延迟会降到个位数毫秒，和明文几乎没有差别。所以真正影响体验的是"连接能不能保持住"，而不是"加密本身有多慢"。这也是为什么我前面说移动端切网后的重连延迟是值得关注的问题——它破坏的正是连接复用。

如果你的使用场景是频繁开关网络、频繁切换 Wi-Fi，那加密 DNS 带来的体感损失会比固定网络下明显。这种情况下我会建议在路由器上统一配置，让路由器去维护那条长连接，终端设备完全无感。

6.2 ECS 缺失导致的 CDN 绕路，我是这么验证的

前面提过 ECS 这个事，这里说具体怎么判断自己有没有被绕路。

方法是对比同一条查询带不带网段信息时返回的 IP 是否落在同一个网段。dig支持直接指定：

dig @1.1.1.1 你要测的域名 A +subnet=0.0.0.0/0

+subnet=0.0.0.0/0相当于告诉服务端"不要带我的网段信息"，服务端会按自己的位置来调度。然后去掉这个参数再查一次，对比两次返回的 IP。如果两次的 IP 分别属于不同地区，说明 ECS 确实在起作用；如果两次完全一样，说明这个服务商压根不看 ECS。

拿到 IP 之后，用mtr或者traceroute看一下实际路径，跳数和延迟差距一目了然。我测过一次，同一个视频站的静态资源，不带 ECS 的时候被调度到了跨洋节点，首屏加载时间差了三倍多。这种时候要么换一个支持 ECS 的服务商，要么就接受这个代价——毕竟隐私和速度本来就是要权衡的。

6.3 家庭网络和企业网络，处理方式完全不同

家庭网络里，我最推荐的做法是在路由器上统一配置。配置一次，全家所有设备全部生效，包括那些根本没法改设置的设备。而且路由器常年在线，长连接维护得比手机好得多，性能损失最小。

企业网络里则是另一套逻辑。内网通常有自己的一套域名体系，很多内部系统的域名只能由内网 DNS 解析。你把设备的 DNS 全局切到外部加密服务，这些内部域名全部解析失败，表现就是 OA、内部代码仓库、打印服务统统打不开。这种环境下正确的做法不是硬上，而是走内部 DNS 转发——让内网的解析服务器自己去对接加密上游，终端设备保持原样。

我个人在受管网络里的原则是：不绕过管理规定，只在自己的设备和个人网络环境里做隐私加固。加密 DNS 是用来防止查询被随意窥探和篡改的，不是用来对抗网络管理的手段。这个边界想清楚了，很多纠结就不存在了。

6.4 浏览器内置的安全 DNS 和系统级配置会打架

Chrome、Edge、Firefox 都自带"使用安全 DNS"的开关，这个开关的优先级高于系统设置。也就是说，你在 Windows 上配好了系统级 DoH，浏览器里如果也开了它自己的安全 DNS，实际生效的是浏览器那一套，两者各走各的。

这种情况下的典型症状是：抓包看不到明文的 53 端口流量，但你在系统日志里也找不到任何 DoH 连接记录，两边的状态对不上，排查起来非常迷惑。

我的处理原则是只开一个。桌面端如果系统支持原生 DoH，就把浏览器那个开关关掉，让流量统一走系统解析器；如果系统不支持（比如 Windows 10），那就反过来，只开浏览器的，别去折腾第三方客户端。两套同时开着，除了增加排错难度没有任何好处。

顺带说一个浏览器内置方案的好处：它通常会自己维护一条到 DoH 端点的长连接，对连接复用的处理比系统解析器更积极，实际体验往往更流畅。缺点是覆盖面窄，只管浏览器自己的流量。所以这个选择本质上是"覆盖面"和"体验"之间的取舍。

配完这一圈下来，我最大的体会是：加密 DNS 这件事，技术门槛其实很低，难的是搞清楚它到底能给你带来什么、不能带来什么。它挡得住公共 Wi-Fi 下那种随手的 DNS 改写，挡不住精心设计的中间人；它让你的查询记录不再明晃晃地摆在链路上，但服务商那边该看到的还是能看到。把它当成一层基础加固，而不是万能护盾，心态就对了。

我现在四台设备全都开着，日常用的是国内那个低延迟的地址，描述文件存在本地一个目录里，换机器的时候改两行 UUID 重新装一遍。唯一还会手动切回"自动"的场景，就是进酒店连 Wi-Fi 的那几分钟。