VPN 的 DNS 过滤让一个网站无法加载：读懂这个应答
隧道正常工作时，过滤型解析器仍可能拦下某一个域名。读懂应答的类型，查清解析器归谁所有，只改你真正能控制的部分。
隧道是通的，却有一个域名解析失败，浏览器把它叫作网络错误，而真正的原因是解析器返回的 DNS 应答。过滤型解析器可以对单个域名进行扣留、拒绝或改写，同时让其他所有查询照常工作。隧道只负责运送查询，决定应答的是解析器。在改动加密设置之前，先看清这个应答。
隧道是通的，所以加密不是嫌疑对象
连接状态只说明数据包是否在流动，并不说明域名能否解析。解析是一次发往客户端所配置服务器的查询，那里的策略可以只对某一个域名给出不同的应答。从浏览器这一侧看，这些应答全都塌缩成一个笼统的失败，所以状态灯能证明的东西非常有限。
先记录三件事：客户端使用的解析器、失败域名的应答代码，以及对一个本应正常的域名做同样的查询。用 dig example.com @10.20.0.1 直接询问解析器，读状态行，而不是浏览器的提示。如果对照域名能解析、失败域名返回策略性应答，证据就完整了。如果两者都失败，过滤器还没有参与进来。
四种应答，四种不同的归属
过滤型解析器拒绝的方式不止一种，而拒绝的形态指向不同的下一步。把应答代码记下来，因为浏览器会把四种情况统统改写成听起来像连接中断的提示。
| Answer | What it points at |
|---|---|
| NXDOMAIN | The name is withheld: a policy entry or a zone decision removed it |
| Refused | The resolver declines to answer; usually an access or policy rule |
| Replacement address | A redirect to a block page or sinkhole you can query and inspect |
| No answer at all | Weakest evidence: reachability, load or routing, not necessarily policy |
在把问题归给隧道之前，先把应答与表格对上。拒绝和扣留都意味着解析器做了决定，而 沉默意味着这次查询从未得到应答。这一差别决定你要去找策略的所有者，还是去查网络路径。
两个浏览器可能遵循两套策略
自带加密解析器的浏览器不必使用操作系统下发的服务器，因此它可以忽略隧道本来要施加的策略。同一台机器上的两个浏览器于是对同一个主机名各执一词，而两者都没有坏。 先查清每个应用绑定的是哪个解析器，再断定过滤器前后不一致。
当两个应用都走隧道的解析器、而只有一个失败时，差别在应用，不在 DNS。按应用分别记下解析器地址，因为窗口一关这个细节就消失了。
改你能改的，把改不了的往上提交
下一步取决于你指向的解析器归谁所有。自己运行的解析器是可以读、可以配置的功能：查一下有文档的过滤选项及其例外，然后放行那一个域名。雇主或服务商运行的解析器，则需要一张带着域名、确切应答和时间的工单。
绝不要换成公共解析器来强行打开站点，因为私有域名会解析不了，刻意设置的策略也不再生效。小范围的改动还能保住证据完整，所有者可以拿你的报告与自己的记录对照。改完之后，重跑原来的应用测试，而不是在命令行里查一次。
拦截页面不是可信证书
一个自带证书的替换页面会触发 HTTPS 身份警告，重定向并不会让那张证书变得有效。不要因为隧道是通的就点过去；这条警告是另一项信任判断，仍然必须正确。
当失败域名返回策略性应答、对照域名经同一个解析器返回正常应答时，诊断就闭合了。到这一步，修复是改策略而不是改隧道，报告里要引用的是 RFC 1035 的应答代码。把两个域名和对应答放在一起，整个案子就是这些。