3

Just in the past day, I have started to have a network issue where any page from Google takes an extremely long time (>10 seconds) to load. Other websites are fine; this issue only seems to happen with Google. I initially encountered this on a Windows 8.1 machine running Chrome. Ping times for www.google.com were about 20ms and there didn't seem to be any dropped packets. I thought it might be an issue with my router or my Comcast internet access, so I had tried rebooting my machine to Ubuntu, where I found that I could not reproduce the issue, Google was perfectly fast there. I also have an Android phone connected to my Wi-Fi network, and connections to Google are perfectly fine there as well. I thought it could be some malware or network or firewall configuration issue, but I have a second machine machine running Windows 7 that started having the same issue at exactly the same time, so I'm not sure what would have affected us both. BTW, I do not have a proxy set up. I verified through Internet settings that there is no proxy configures and proxy auto-detection is turned off. Both of these Windows machines are connected to my router through CAT6 cables, one directly, one through another switch.

I was originally running Chrome 61.0.3163.100, and I thought it might be an issue with Chrome, but I also ran into the same problem running Internet Explorer 11 and Firefox 46.0.1 on the same machine. I also downloaded Chrome Canary, and that also had the same problem. To take a typical example, here is the network console from a query in Chrome Canary:

Slow Google query from network console in Chrome Canary

Looking at the timing for that 18s query, I get this:

Timing for 18s query to Google

In other words, almost all of that time is spent with the query being stalled. If I look at the event log in chrome://net-internals for this, this is what I see:

Log dump from Chrome Canary

It looks like in this case it has made a request that the server just ignores until the connection times out, and then it works fine on a reattempt. There is also a related HTTP2_SESSION log for this query:

HTTP2_SESSION log dump from above query

This looks like it ends in a socket error, but I am finding very little information online on error 101. In another attempt, I got this:

Second log dump from Chrome Canary

In this case, it seems like it just opens the connection and doesn't do anything until it times out. Am I misreading this? Incidentally my download of Chrome Canary paused for a very long time after downloading 500k of it, before finishing the rest of the way. Here are the logs for that (from Chrome 61):

Chrome Canary download logs

I also have some related HTTP2_SESSION logs for that download:

HTTP2_SESSION logs for Chrome Canary download

It looks like here the download just stopped until Chrome had to ping the connection and then send another request. I have quite a few similar HTTP2_SESSION logs that show connections going idle for a long time until pings fail, but they usually end with an error 101. I am not sure what the issue is here. So you know this is not a Chrome issue, I also have a similar timeline from F12 Developer Tools in IE 11:

IE 11 also being slow

Here it seems to spend quite a lot of time in the "Start" stage of the query. It seems to be a bit more intermittent in IE 11. Sometimes queries run fine, sometimes they time out. I thought this might be an issue with HTTP/2 under Windows, since all of the sessions with issues are HTTP/2 sessions, but I have tried other HTTP/2 sites that work fine.

One other thing I tried was setting the user agent on Chrome on Ubuntu to the same one Chrome on Windows was using, which was Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3259.0 Safari/537.36. That did not change anything. Google under Ubuntu works fine.

My DNS is set up to use Comcast's IPv6 DNS server of 2001:558:feed::1, which resolves www.google.com to 2607:f8b0:4007:80a::2004 or 172.217.4.164. I also tried using Google's DNS server of 8.8.8.8, which resolves www.google.com to 2607:f8b0:4005:806::2004 or 172.217.5.100. Setting 8.8.8.8 as my default DNS and then flushing Chrome's DNS cache also did not fix the issue.

After trying the IPv6 address for Google's DNS and having that completely fail, I disabled IPv6 in my network adapter, and now everything is working fine again. Oddly, my Android phone also is using IPv6 via Wifi and is not having the same problems. I also tested this on my Ubuntu install, which is set up to use IPv6, and tried with the Google DNS IPv6 addresses, and it worked fine. This could be because a poor IPv6 implementation in either my Arris TG862G router or my local Comcast internet, but that doesn't explain why it only affects Windows machines. If it is at all relevant, the IPv6 on my router is set up for stateless, not DHCP. The only change I have made to my network recently was that I updated the DD-WRT version of a secondary access point/switch (originally a Netgear router) that my Windows 8.1 machine does not use but the Windows 7 machine does. The Netgear router is strictly IPv4.

I switched out my cable modem/router for a newer one, and that seemed to fix the issue for a day, but now, 24 hours later, it is happening again. Still have to disable IPv6 on my Windows machines. Now running a fresh Windows 10 install, and still having the same problem.

  • 1
    Please don’t post comments like the above; we prefer that you edit your question to incorporate any information that clarifies, completes, or enhances the question.  Don’t use big EDIT headings, and don’t put the new information at the end.  Just work it into the narrative where it belongs and/or makes sense.  I did the first one for you already. – Scott Nov 6 '17 at 0:22
  • Does the behavior exhibit itself if you don’t use a proxy? What about a different proxy? How about a different DNS provider? Update your question. Don’t reply as a comment. – Ramhound Nov 6 '17 at 0:37
  • How are the machines connected to the internet? Wireless or wired? I appreciate all the investigation you did here, but even after that this looks like a simple case of a bad internet connection. We can try to explain that away with other details without being sure or we can try to support the most obvious thing - that these machines have a less than perfect connection to the internet until we are positive that is not the case. There could also be another factor, like a similar internet security product on the Windows machines - something that could interfere with that “perfect” connection. – Appleoddity Nov 6 '17 at 1:03
  • Try another browser. Try a complete junk file cleanup of the OS and browser. – Overmind Nov 6 '17 at 12:39
0

It sounds to me like the problem is at Google's end. One of their cloud instances, the one that the algorithm that assigns a cloud instance to serve a request has chosen for your IP and operating system (Windows) combination, is malfunctioning. After the timeout it switches you to another one which works.

At least, the last time I saw this kind of behavior (not from Google, from a webservice I was involved in testing) that was the cause.

If you do another Google request immediately after the 10 second + one, within 2 seconds of that one completing, does it still take 10 seconds? Or does that one work faster? In our case additional ones immediately after the slow one resolved faster as it sent the request to the working one till it forgot about the failure.

The good news is, if I'm right, this should correct itself fairly soon as Google figures out one instance is messed up and reboots it...

  • The logs I showed above do show that when a connection fails, it reconnects, and then one works fine, so that is a possibility. But I also tried setting the user agent on my Chrome on Ubuntu to say it was Windows Chrome. I didn't see the problem then. The issue also only seems to affect IPv6 hosts. I was able to fix it by disabling IPv6 on my Windows machine, but IPv6 works fine on non Windows machines. – Joel Croteau Nov 6 '17 at 13:47
  • If this was a temporary network misconfiguration, it doesn't seem very temporary. It's still happening a month later, and it now seems to be affecting my Android phone, which doesn't have a way to disable IPv6 without rooting it. – Joel Croteau Dec 19 '17 at 23:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.