就在过去的一天，我开始遇到一个网络问题，任何来自 Google 的页面都需要很长时间（超过 10 秒）才能加载。其他网站都很好；这个问题似乎只发生在 Google 上。我最初在运行 Chrome 的 Windows 8.1 机器上遇到这个问题。www.google.com 的 Ping 时间约为 20 毫秒，似乎没有任何丢包。我认为这可能是我的路由器或康卡斯特互联网接入的问题，所以我尝试将我的机器重新启动到 Ubuntu，在那里我发现我无法重现这个问题，Google 在那里非常快。我还有一部连接到 Wi-Fi 网络的 Android 手机，那里与 Google 的连接也非常正常。我以为这可能是一些恶意软件或网络或防火墙配置问题，但我有另一台运行 Windows 7 的机器，它在同一时间开始出现同样的问题，所以我不确定是什么会影响我们两个。顺便说一句，我没有设置代理。我通过互联网设置验证了没有代理配置，并且代理自动检测已关闭。这两台 Windows 机器都通过 CAT6 电缆连接到我的路由器，一台直接连接，一台通过另一个交换机连接。
我最初运行的是 Chrome 61.0.3163.100，我以为这可能是 Chrome 的问题，但在同一台机器上运行 Internet Explorer 11 和 Firefox 46.0.1 时也遇到了同样的问题。我还下载了 Chrome Canary，也遇到了同样的问题。举一个典型的例子，这是来自 Chrome Canary 中的查询的网络控制台：
查看该 18 秒查询的时间，我得到了以下信息：
换句话说，几乎所有的时间都花在查询停滞上。如果我查看 chrome://net-internals 中的事件日志，我会看到以下内容：
在这种情况下，它似乎发出了一个请求，服务器只是忽略该请求，直到连接超时，然后它在重新尝试时工作正常。此查询还有一个相关的 HTTP2_SESSION 日志：
这看起来像是以套接字错误结束的，但是我在网上找到的有关错误 101 的信息很少。在另一次尝试中，我得到了以下信息：
在这种情况下，它似乎只是打开连接，直到超时才执行任何操作。我是不是看错了？顺便说一句，我的 Chrome Canary 下载在下载了 500k 后暂停了很长时间，然后才完成剩余部分。以下是相关日志（来自 Chrome 61）：
我还有一些与该下载相关的 HTTP2_SESSION 日志：
Chrome Canary 下载的 HTTP2_SESSION 日志
看起来下载在这里只是停止了，直到 Chrome 必须 ping 连接，然后发送另一个请求。我有不少类似的 HTTP2_SESSION 日志，显示连接长时间处于空闲状态，直到 ping 失败，但它们通常以错误 101 结束。我不确定这里的问题是什么。所以你知道这不是 Chrome 的问题，我在 IE 11 中的 F12 开发人员工具中也有类似的时间线：
这里似乎在查询的“开始”阶段花费了相当多的时间。在 IE 11 中，它似乎有点断断续续。有时查询运行良好，有时会超时。我认为这可能是 Windows 下 HTTP/2 的问题，因为所有有问题的会话都是 HTTP/2 会话，但我尝试过其他运行良好的 HTTP/2 站点。
我尝试的另一件事是将 Ubuntu 上的 Chrome 上的用户代理设置为与 Windows 上的 Chrome 相同的用户代理，即 Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML，如 Gecko) Chrome/64.0.3259.0 Safari/537.36。这并没有改变任何东西。Ubuntu 下的 Google 运行良好。
我的 DNS 设置为使用 Comcast 的 IPv6 DNS 服务器 2001:558:feed::1，它将 www.google.com 解析为 2607:f8b0:4007:80a::2004 或 172.217.4.164。我还尝试使用 Google 的 DNS 服务器 8.8.8.8，它将 www.google.com 解析为 2607:f8b0:4005:806::2004 或 172.217.5.100。将 8.8.8.8 设置为我的默认 DNS，然后刷新 Chrome 的 DNS 缓存也未能解决问题。
在尝试了 Google DNS 的 IPv6 地址并完全失败后，我在网络适配器中禁用了 IPv6，现在一切又恢复正常。奇怪的是，我的 Android 手机也在通过 Wifi 使用 IPv6，但没有遇到同样的问题。我还在设置为使用 IPv6 的 Ubuntu 安装上进行了测试，并尝试了 Google DNS IPv6 地址，它工作正常。这可能是因为我的 Arris TG862G 路由器或本地康卡斯特互联网的 IPv6 实现不佳，但这并不能解释为什么它只影响 Windows 机器。如果这完全相关，那么我路由器上的 IPv6 设置为无状态，而不是 DHCP。我最近对网络所做的唯一更改是我更新了辅助接入点/交换机（最初是 Netgear 路由器）的 DD-WRT 版本，我的 Windows 8.1 机器不使用它，但 Windows 7 机器使用它。Netgear 路由器严格使用 IPv4。
我把我的电缆调制解调器/路由器换成了新的，这似乎解决了一天的问题，但现在，24 小时后，它又出现了。仍然必须在我的 Windows 机器上禁用 IPv6。现在运行全新安装的 Windows 10，仍然有同样的问题。
答案1
在我看来，问题出在 Google 方面。他们的一个云实例（即为您的 IP 和操作系统 (Windows) 组合分配云实例以处理请求的算法选择的实例）出现故障。超时后，它会将您切换到另一个正常运行的实例。
至少，上次我看到这种行为（不是来自 Google，而是来自我参与测试的网络服务）时，这就是原因。
如果您在 10 秒后立即发出另一个 Google 请求，在该请求完成后的 2 秒内，它是否仍需要 10 秒？还是那个请求运行得更快？在我们的案例中，在慢速请求解决后立即发出的其他请求运行得更快，因为它将请求发送到正在运行的请求，直到它忘记了失败。
好消息是，如果我是对的，这个问题很快就会得到纠正，因为谷歌会发现一个实例搞砸了并重新启动它......