为什么有些网站只在开启 VPN 时才打不开？

只有一个站点失败、其他一切都能加载，这证明隧道本身在传输流量，因而把问题范围缩得比多数人预想的更小。三项观察可以理清其余部分：你是否收到了 HTTP 响应、主机名是否解析成了地址、小请求能否通过而大请求卡住。在这些答案之前就猜测 VPN，通常只是把故障挪个位置，而不是消除它。

按顺序处理这些观察，因为已经返回响应的站点不可能同时解析失败。如果什么都加载不了，你就在另一条分支上，应改用已连接但无网络的检查。

让错误信息来选择分支

拒绝、机器人验证或错误页面意味着服务已经回应，也就是数据包到达了某个应用并返回。这把问题转向站点的访问策略，它可能权衡出口地址、账号或未公开的请求模式。域名解析失败则根本没有到达站点，而地址是首先要检查的东西。超时介于两者之间：有东西被发出去了，却没有任何回应确认。

证书警告属于第四条分支。它意味着连接由某个浏览器无法验证身份的对象应答，可能是你这边的代理，也可能是你不该点击穿过的真实不匹配。把它当作信任问题，而不是路由问题。

能应答的站点并未证明隧道已坏

当回应是拦截页时，在浏览器和机器都不变的情况下，通过第二个出口访问同一页面作比较。如果结果随出口地址变化，说明站点对该地址另眼相待，任何客户端配置都改变不了它。如果拦截跟着你的浏览器走，原因就在扩展、保存的代理或解析器设置里。两次运行就能低成本地区分这些解释。

只发生在浏览器里的故障足够常见，值得尽早测试。一个页面在某个受支持的浏览器里能加载、在另一个里失败，指向配置文件状态、内容拦截器，或浏览器内部配置的加密 DNS。Chrome 的安全 DNS 指南说明了该设置在哪里，通过受支持的控件修改它，胜过重置设备。

只有大传输卡住时，检查数据包大小

页面渲染出页眉后卡住，与页面根本打不开是两种不同的特征。小响应可以通过，而整包大小的载荷却在某处被丢弃、又无法向发送方发出信号，这正是从浏览器看到的路径 MTU 故障。在讨论过滤之前，先向同一主机分别发一个小请求和一个大请求作比较。路径 MTU 发现本该学习路径上最小的链路尺寸，它依赖 ICMP 反馈，而经过过滤的网络常会丢弃这类反馈。

用尺寸扫描而不是单次 ping 来验证这个假设。在固定载荷大小处开始的故障是有力证据，而位置飘忽不定的故障则不是。

在真正失败的那个请求上确认修复

重测原始操作，而不是首页，因为缓存的页面外壳可能照常渲染，而登录背后的 API 调用仍然失败。下面的命令针对同一主机，分别检查域名解析、小请求和大请求。把主机名和路径换成真正出问题的那个请求里的值。

dig +short www.example.com
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://www.example.com/
curl -sS -o /dev/null -w '%{http_code} %{size_download}\n' https://www.example.com/assets/app.js
ping -M do -s 1400 -c 3 203.0.113.20

如果 dig 的答案与浏览器所用的不同，变量就是解析器，而值得检查的地方是浏览器自己的 DNS 设置。如果小请求返回状态而大请求卡住，就走数据包大小这条分支。如果两者都超时，出口路径以及站点对该地址的处理就重新回到桌面上。

保留让原始请求成功的那个改动，撤销其余改动。同时堆上一堆浏览器、解析器和客户端改动，你就再也说不清到底是哪一个起了作用。