在连接build立之前，连接到我的VPS上的帐户最多挂起20秒

我有一个VPS服务器运行WHM 11.36.0（版本14）和CENTOS 6.4 x86_64 xenpv – 控制

我在我的服务器上有多个帐户，每当我向其中一个请求时，请求都需要几秒钟才能build立。当转账已经连接时，速度很快，但是最初的20秒“没有任何事情发生”让我担心。

我们在我的组织中大量使用了我们的VPS，而且我真的不能承受减速。

有谁知道为什么会发生这种情况？
我对服务器的技术不太了解（我是一个软件人），所以我不知道如何正确configuration服务器，对我来说，它看起来像一个DNS错误，但我不知道如何debugging或修复这些问题！谁能帮忙？

这里有两个网站目前正在经历这个“悬挂” –

http://directhealthcareservices.co.uk/
http://sparebrainmanagementsupport.com/

更新：

我已经跟我的VPS主机说过了，官方的说法是这个挂起是由我的本地DNS造成的，而不是由服务器的DNS造成的 – 但是显然，这个问题只发生在试图访问我们自己的服务器上的帐户时，networking上没有其他地方。

为了testing这个，我把我的本地DNS改为8.8.8.8和8.8.4.4，然后在我们的路由器上重复这个改变。行为似乎没有任何改变。

我不顾一切地得到这个解决，但迄今为止，无济于事！

要检查是否是DNS或TCP连接问题，我会在服务器上安装tcpdump ，在客户端上安装Wireshark ，并自己运行一些测量。这需要一些控制台技能，但是值得一试。

我们将捕获您的networking接口的原始stream量，并查看电线的肠子，以查明是否是DNS或TCP问题。但是，这并不能解决你的问题的根源，只会给你指点一下。

这整个发布是基于这样的假设，它是一个DNS反向查询超时问题或networking上的更深层的问题。

安装tcpdump ，找出HTTP请求到达您的服务器的物理networking接口。接下来，请指出您正在使用的机器的公共IP地址 – 如果您运行连接testing，则需要此filter来滤除不必要的噪音。

让我们打电话给你的服务器的IP地址A和你的客户的IP地址B

假设保存这个虚拟主机的IP地址的接口名为eth0 ，你应该像这样以root用户身份运行tcpdump ：

# tcpdump -n -s 1500 -w /tmp/tcpdump.pcap -i eth0 \(host A and host B and tcp port 80\) or udp port 53

（用您的IP地址replaceA和B ;如果您使用https而不是httpreplacetcp port 80与tcp port 443 ）

该程序将启动并捕获您的客户端机器和服务器之间的所有stream量，以及DNS数据包（几乎所有这些都是我害怕的，但我们稍后回来），并将内容存储到文件/tmp/tcpdump.pcap 。

然后，启动您的请求。在您观察问题后，请返回到控制台并按CTRL+C停止tcpdump 。

现在我build议你在你的客户端机器上安装Wireshark程序进行更深入的分析。

安装完成后，将文件从服务器上下载到客户机上，并通过File -> Open在Wireshark中加载文件。

要检查TCP握手是否正常，请查找前三个数据包。如果捕获networking通信正常，请查找设置了TCP SYN标志的第一个数据包。用鼠标标记这个，然后selectAnalyze -> Follow TCP Stream来过滤掉这个单一的TCP连接（我们这样做是因为通常你会有很多TCP连接从一个请求到一个web服务器，但是我们只想看到现在为止）。

窗户将打开，只需再次closures，我们不需要。现在突出显示第一个数据包，然后selectEdit -> Set time reference (Toggle) 。这将使整个窗口中的所有时间戳相对于您标记的第一个数据包，以便我们可以看看时间是否正确。如果不是默认值，也可以设置View -> Time Display Format -> Seconds since previous displayed packet 。

看看前四个数据包。你会注意到，他们将有一些TCP标志设置：

从客户端到服务器的第一个数据包设置了SYN标志。
从服务器到客户端的第二个数据包设置了SYN和ACK标志。
从客户端到服务器的第三个数据包仅设置了ACK标志。
现在第四个数据包将有您的第一个HTTP GET请求。
第五个数据包是服务器确认已收到HTTP GET
sixt包是第一个到达的数据
而这是更多的数据; 如果你看看Wireshark的下半部分，你会看到内容。

看看这七个数据包的时间戳。他们都应该非常非常接近，它应该看起来像这样：

Wireshark截图1

你可以看到所有这些数据包都非常紧密地相互关联，它们之间的距离只有几百毫秒。如果是这种情况，TCP连接本身就是可行的，而我们更多地关注DNS。但是，如果这对你不好，如果你看到长时间的延迟，甚至TCP重传或者有关“重复ACK”等信息，那么你需要研究一个更深层的networking问题。然后回到你的VPS提供者。

但是，如果事实certificate确实如此，我们会考虑DNS。为此，我们要检查以下事实：

DNS服务器是否及时回答问题？
究竟是什么导致问题的DNS问题？

我将遵循以下假设：

服务器看到你的客户的IP地址，并想知道它的DNS名称
为此，它将向名称服务器发送一个所谓的IN PTR问题
我可以想象，这个所谓的“reverese lookup”要么失败，要么名称服务器缓慢地回答。

所以，现在你必须做一些小数目的shuffeling。假设你的客户的IP地址是1.2.3.4 。现在反转数字（ 4.3.2.1 ）并添加后缀.in-addr.arpa给它。你现在已经为Wiresharkbuild立了正确的查询。在Filter ，说：

dns.qry.name ==“4.3.2.1.in-addr.arpa”

在下面的例子中，我要求在78.47.204.196我的服务器的完整限定名，所以我的filter是dns.qry.name == "196.204.47.78.in-addr.arpa" ：

Wireshark截图2

就我而言，你会看到一个有趣的效果。我的名字服务器192.168.1.1没有足够响应我的客户的口味，所以它发出了另一个请求，虽然这次使用IPv6。但是，这并不重要，如果您没有IPv6，它只会再次发出相同的请求。你看到真正的答案 – yalla.hackers-r-us.org – 请求后2.96秒。这很慢，但答案就在那里。

你知道需要检查以下内容：