我已经等了3天才看看这些问题是否会自行修复，但我会继续解释已经发生的事情，因为看起来你们很多人实际上可以在没有逃避的情况下摄取信息墙它！
tl; dr（just incase）
我在浏览多个网站时遇到了超时问题，并且想知道问题是什么。我能够连接到网站，但随机我收到连接错误，然后在显示错误的5秒内刷新页面/连接。
话虽如此，我们走了：
我们正在进行跟踪的域名是（www.ezkratom.com） 我已经对其他域进行了其他测试，我将在下面发布。
我在编辑网站后端时首先注意到这些问题，因为我们刚刚使用GoDaddy Wordpress Hosting软件包将所有信息从Shopify迁移到Wordpress / WooCommerce。
无论如何，在我们来到GoDaddy之前，我们没有开始注意到这些问题。
我们周五晚上打电话给GoDaddy，他们说他们刚刚结束修复Wordpress托管问题，并且没有任何已知问题。
所以今天早上凌晨2点左右我回电话。 （星期日，17/17/17）
这家伙让我向他发送了一些tracert副本给我，我们在网站上做了。
这家伙并没有要求我对任何其他网站进行追踪，而只是对这个网站。哈利没有真正想到它，因为我已经睡了一个多小时才睡着了，哈哈。
无论如何，他说从Tracert的外观来看，它似乎是一个三级通信问题。
他继续告诉我，如果问题仍然存在，我应该在一两天内给我的ISP打电话，看看他们是否能以不同的方式路由我的连接，因为他们认为与3级协议表明他们有义务将他们的客户连接到互联网。
虽然我与互联网“连接”，但我通过网站随机发现连接问题。
我知道我可以连接到该网站。这个问题不是一个长期存在的问题。它发生在我每隔30-45分钟，无论是在我通过前端，还是在我的后端。
当我尝试从后端加载到前端时（例如，在更新页面之前按“预览更改”，或者甚至只是单击顶部的“查看站点”），似乎最常发生这种情况Wordpress适用于那些熟悉的人，但我们有一些客户告诉我们他们在尝试加载页面时收到了同样的问题。
我今天和ISP谈过，当然，在呼叫中心内两次转移失败后，他们无法对此做任何事情。他们说，如果它“在他们的最后”，电话会爆炸。
据我所知，技术上并不是最终的，但是如果他们与3级达成协议，3级正在搞乱，那么为什么他们暂时不能将我的连接重新路由到不同的服务器或不同的连接通过3级？也许我正在以完全错误的方式思考这个问题，因为我不太熟悉，但我让我的业务合作伙伴对同一个域运行了一个跟踪，并且他没有经历任何时间。 （这张贴在下面，第四条跟踪下来）
ISP的那个人在我做的同样的跳跃中经历了超时，他们在这里：
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Windows\system32>tracert www.ezkratom.com
Tracing route to ezkratom.com [198.71.233.21]
over a maximum of 30 hops:
1 11 ms 7 ms 4 ms 192.168.0.1
2 18 ms 13 ms 14 ms 10.205.240.1
3 18 ms 19 ms 12 ms ten0-0-1-2.tamp84-ser1.bhn.net [72.31.92.12]
4 20 ms 18 ms 17 ms ten0-1-0-8-4.tamp20-car1.bhn.net [72.31.211.42]
5 19 ms 20 ms 21 ms 71-44-17-115.net.bhntampa.com [71.44.17.115]
6 26 ms 29 ms 29 ms 10.bu-ether15.tamsflde20w-bcr00.tbone.rr.com [66
.109.6.96]
7 26 ms 21 ms 15 ms ae-9.bar1.Tampa1.Level3.net [4.68.72.205]
8 * * * Request timed out.
9 59 ms 51 ms 47 ms 4.14.98.38
10 44 ms 45 ms 43 ms ip-184-168-6-81.ip.secureserver.net [184.168.6.8
1]
11 48 ms 57 ms 48 ms ip-184-168-6-81.ip.secureserver.net [184.168.6.8
1]
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 49 ms 52 ms 43 ms ip-198-71-233-21.ip.secureserver.net [198.71.233
.21]
Trace complete.
C:\Windows\system32>
这是www.google.com的另一个跟踪
C:\Windows\system32>tracert www.google.com
Tracing route to www.google.com [64.233.176.147]
over a maximum of 30 hops:
1 11 ms 7 ms 9 ms 192.168.0.1
2 25 ms 12 ms 19 ms 10.205.240.1
3 16 ms 16 ms 21 ms ten0-0-1-2.tamp84-ser1.bhn.net [72.31.92.12]
4 20 ms 21 ms 18 ms ten0-0-0-8-5.tamp20-car1.bhn.net [72.31.211.36]
5 140 ms 56 ms 25 ms ten0-8-0-0.orld71-CAR1.bhn.net [71.44.1.211]
6 22 ms 23 ms 27 ms 72-31-188-170.net.bhntampa.com [72.31.188.170]
7 29 ms 32 ms 29 ms 10.bu-ether15.orldfljo00w-bcr00.tbone.rr.com [66
.109.6.98]
8 31 ms 39 ms 38 ms bu-ether18.atlngamq47w-bcr01.tbone.rr.com [66.10
9.1.72]
9 34 ms 33 ms 34 ms 205.197.180.41
10 40 ms * 39 ms 205.197.180.54
11 36 ms 31 ms 37 ms 216.239.51.53
12 39 ms 35 ms 34 ms 209.85.142.138
13 47 ms 33 ms 33 ms 209.85.142.153
14 * * * Request timed out.
15 47 ms 41 ms 41 ms yw-in-f147.1e100.net [64.233.176.147]
Trace complete.
通常情况下，www.google.com会给我8次以上的超时请求，而这次它只做了一次。
这是我与之合作的网站的另一个跟踪：
C:\Windows\system32>tracert www.vapershero.com
Tracing route to vapershero.com [174.136.29.198]
over a maximum of 30 hops:
1 5 ms 4 ms 6 ms 192.168.0.1
2 18 ms 19 ms 19 ms 10.205.240.1
3 18 ms 20 ms 31 ms ten0-0-1-2.tamp84-ser1.bhn.net [72.31.92.12]
4 31 ms 29 ms 22 ms ten0-0-0-8-5.tamp20-car1.bhn.net [72.31.211.36]
5 31 ms 34 ms 24 ms 71-44-17-117.net.bhntampa.com [71.44.17.117]
6 21 ms 28 ms 26 ms 10.bu-ether15.tamsflde20w-bcr00.tbone.rr.com [66
.109.6.96]
7 25 ms 19 ms 21 ms ae-9.bar1.Tampa1.Level3.net [4.68.72.205]
8 * 1444 ms 1729 ms ae-8-0.ear3.Dallas1.Level3.net [4.69.210.145]
9 43 ms 47 ms 43 ms 4.79.182.238
10 122 ms 41 ms 41 ms 174.136.57.235
11 41 ms 43 ms 47 ms 173.237.185.65
12 52 ms 49 ms 58 ms server.hostleef.com [174.136.29.198]
Trace complete.
最后，这是来自我的商业伙伴的追踪，他离我约45分钟路程。他更接近坦帕湾地区然后我不是，但我不明白为什么会产生巨大的差异。
他也在使用WOW（曾经被称为Knology或其他东西）用于他的家庭互联网，他在他的办公室使用FiOS。这个tracert是通过WOW完成的：
MacBook-Pro-210:~ user$ traceroute ezkratom.com
traceroute to ezkratom.com (198.71.233.21), 64 hops max, 52 byte packets
1 192.168.0.1 (192.168.0.1) 5.487 ms 2.821 ms 4.302 ms
2 * * *
3 user-69-73-108-93.knology.net (69.73.108.93) 22.632 ms 22.729 ms 40.298 ms
4 user-69-73-1-240.knology.net (69.73.1.240) 26.141 ms 22.281 ms 27.545 ms
5 dynamic-75-76-35-33.knology.net (75.76.35.33) 22.517 ms 29.430 ms 29.968 ms
6 user-24-214-2-221.knology.net (24.214.2.221) 37.570 ms 29.553 ms 23.668 ms
7 user-75-76-127-175.knology.net (75.76.127.175) 29.958 ms 29.759 ms 40.223 ms
8 user-69-73-1-165.knology.net (69.73.1.165) 49.772 ms 39.398 ms 50.663 ms
9 dynamic-75-76-35-14.knology.net (75.76.35.14) 35.758 ms 48.323 ms 42.154 ms
10 dynamic-75-76-35-13.knology.net (75.76.35.13) 59.747 ms 46.226 ms 50.368 ms
11 eqix.dc.godaddy.com (206.126.236.43) 45.125 ms 49.554 ms 50.165 ms
12 ip-184-168-6-81.ip.secureserver.net (184.168.6.81) 49.811 ms
ip-184-168-6-83.ip.secureserver.net (184.168.6.83) 49.884 ms
ip-184-168-6-81.ip.secureserver.net (184.168.6.81) 49.766 ms
13 ip-184-168-6-83.ip.secureserver.net (184.168.6.83) 59.391 ms
ip-184-168-6-81.ip.secureserver.net (184.168.6.81) 49.890 ms
ip-184-168-6-83.ip.secureserver.net (184.168.6.83) 44.943 ms
希望有足够的信息来解读某些类型的问题，但我会尽可能地密切监视这个帖子，这样我就可以回复任何有信息的人。
提前感谢，因为我正在努力弄清楚这里发生了什么。