VPN 已连接但域名解析失败：DNS 真正断在哪里
绿色隧道加上失败的查询，指向解析器、它的路由或单个应用。动 VPN 协议之前，先测试一个公网域名和一个内网域名。
隧道已建立，图标是绿的，但每个浏览器标签页都在报域名解析失败。三种不同的机制都会造成这幅画面：解析器可能不可达，客户端可能在向一个你没想到的解析器发问，或者只有内网域名失败。在改动隧道协议之前先把它们分开，因为每一种的修法都不一样。下面的顺序从能把三者区分开的观察开始。
一次查询到底需要什么
一次查询需要三样东西：解析器地址、通往该地址的路由，以及与问题相符的答案。三样都可能各自出问题，而可见的症状都是同一个打不开的页面。所以在知道三者中哪一个断了之前，错误页几乎告诉不了你什么。
客户端从 VPN 配置文件、从隧道上的 DHCP，或从自身配置里获知解析器，而哪个来源胜出取决于平台。在 Windows 上，ipconfig /all 会按适配器列出 DNS 服务器，所以你能看到下发的值是否真的到达。一个从未到达操作系统的下发值，是安静而常见的故障。动配置文件之前，先读取实际生效的值。
Linux 和 macOS 用不同的命令回答同一个问题，答案同样值得一读：resolvectl status 和 scutil --dns 都会按接口列出服务器。把这份清单独与配置文件声称下发的地址对照。这里的差异能解释后面的一切，所以在测试域名之前先把它理清。
测试一个公网域名和一个内网域名
在同一台机器上查询一个普通公网主机名和文档中给出的内网主机名，并记录各自是哪个服务器回答的。如果两者都失败，是解析器或其路由坏了。如果只有内网域名失败，说明解析器答了，问题变成区域或路由。两次查询之间隔不到一分钟，这样路由变化就解释不了差异。
把内网域名挡在公开截图和公共解析器之外。超时和“域名不存在”是两种不同的观察：前者说没有任何回应，后者说权威服务器回答该域名不存在。把两者当成同一个错误会把你带到错误的层，而证书警告又是第三件事，不是 DNS 故障。
nslookup 会同时显示它询问的服务器和收到的回答，而这正是你需要的一对。在同一个 shell 里跑两次，并把应答地址写在每个回答旁边。
nslookup example.com
nslookup host.corp.example 10.20.30.53确认客户端真的能到达那个服务器
配置文件下发的内网解析器，只有在隧道建立期间客户端能到达它时才有用。地址看起来对却没有路由，结果就是超时，而隧道的已连接状态对这条路由什么也说明不了。检查是查通往解析器本身的路由，而不是通往 VPN 端点。
每个平台用一行回答这个问题，输出里点名的接口就是全部答案。如果解析器在隧道后面，这行却指向物理网卡，说明配置文件没有下发覆盖它的前缀。
ip route get 10.20.30.53 # Linux
route -n get 10.20.30.53 # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53 # Windows PowerShell在分离隧道配置里，解析器可能落在下发路由之外，这是配置问题而不是服务器问题。把解析器地址与下发的前缀对照，确认其中一条覆盖它。同一处不匹配也解释了为什么 DNS 在一个网络能用、在配置相同的另一个网络却失败。
记住浏览器可以绕过系统解析器
开启安全 DNS 的浏览器可以通过 HTTPS 把查询发给自己选定的服务商，完全无视操作系统的解析器。于是系统看起来正常而浏览器失败，或者反过来。那是浏览器层面的策略问题，不是隧道的问题。
检查浏览器的安全 DNS 设置以及任何管控它的托管策略，然后在隧道不变的情况下换第二个应用或浏览器。如果只有某个应用失败，修法就在那个应用里。隐私窗口不是干净的对照，因为它可能在一个浏览器里默认禁用扩展、在另一个里不禁用，而且它从不绕过托管策略。改用第二个浏览器配置文件或别的应用。
清除缓存并重新测试真实任务
改完设置后，清空本地解析器缓存，免得旧答案比修复活得更久。短暂恢复后又失败，说明原因还在，而不是清缓存失败。三条命令按你所在的系统选一条，因为三个缓存是分开的。
ipconfig /flushdns # Windows
resolvectl flush-caches # Linux
sudo killall -HUP mDNSResponder # macOS然后重做原来的任务，而不是合成查询，因为用户关心的是任务本身。也重连一次，这样复测才覆盖用户真实会处的状态。Microsoft 的 nslookup 参考 是值得留作查询参数备查的页面。
如果只有断开连接后才解析失败，说明客户端没有恢复先前的配置，这是应当上报的生命周期缺陷，而不是要更换 DNS 服务器。查询能用也不是泄漏测试，因为出口国家并不能告诉你哪个解析器回答了。