服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 等待3天后，无法访问服务器上的IP地址
Intereting Posts
Postfix + Dovecot与MySQL后端：MD5哈希密码和CRAM-MD5validation 我的硬盘即将死亡吗？ KeePass（在Ubuntu上）在HTTP IIS WebDAV Share上得到401 Unauthenticated “爆炸账户”这个词的起源和/或标准是什么？ 哪里得到正确的`地区名称`和输出格式的AWSconfiguration？ Windows Server 2003：在企业CA中使用根和中间CA的离线导致失败 为什么snmp.exe会使用1.2GB的内存？ 适用于elasticloadbalancing的AWS IAM策略：DescribeTargetHealth Google云默认networking未find错误 亚马逊：如何知道我是否需要预置IOPS？ 使用DFS根作为共享文件夹 SSL自签名证书 – 它们如何显示在客户端以及如何configuration？ 如何通过postfix将邮件发送回发件人 跳入memcached – 知道任何好的指南？ 寻找生产服务器的强大监控工具

等待3天后，无法访问服务器上的IP地址

我的一位客户在三天前向Hurricane Electric托pipe了他们的网站，并在他们的帐户中添加了一个专用的IP地址。

但是，我无法在他们的网站上工作，因为专用的IP地址不会为我加载任何东西; 它只是超时。 然而，更糟糕的是，我曾经在全国各地的朋友尝试加载在他们的浏览器的IP地址，并加载他们的罚款。 似乎任何连接到家庭networking的计算机或电话都无法访问专用IP地址。

其中之一是http://65.49.51.227/

有人能告诉我，我能做些什么来解决这个噩梦？ 我将要失业了，因为已经有将近4天了，我甚至无法开始工作了！

首先，你运行一个traceroute。 

 $ traceroute 65.49.51.227 traceroute to 65.49.51.227 (65.49.51.227), 30 hops max, 60 byte packets 1 172.25.50.1 (172.25.50.1) 0.364 ms 0.473 ms 0.609 ms 2 172.25.49.1 (172.25.49.1) 3.722 ms 3.828 ms 4.962 ms 3 73.195.236.1 (73.195.236.1) 33.326 ms 34.256 ms 34.357 ms 4 te-4-4-ur01.manchester.nh.boston.comcast.net (68.87.156.25) 35.028 ms 35.562 ms 35.665 ms 5 be-65-ar01.needham.ma.boston.comcast.net (68.85.69.165) 37.216 ms 38.148 ms 38.549 ms 6 he-2-6-0-0-cr01.newyork.ny.ibone.comcast.net (68.86.93.33) 46.651 ms 45.528 ms 44.266 ms 7 he-0-13-0-0-pe03.111eighthave.ny.ibone.comcast.net (68.86.85.182) 41.303 ms 40.190 ms 40.961 ms 8 66.110.96.137 (66.110.96.137) 41.660 ms 66.110.96.141 (66.110.96.141) 103.340 ms 66.110.96.133 (66.110.96.133) 198.579 ms 9 63.243.128.121 (63.243.128.121) 200.059 ms 200.147 ms 200.685 ms 10 nyk-b5-link.telia.net (213.248.100.177) 199.866 ms 199.359 ms 199.231 ms 11 nyk-bb1-link.telia.net (213.155.135.18) 218.178 ms 217.146 ms 218.260 ms 12 sjo-bb1-link.telia.net (213.155.130.129) 270.667 ms 275.737 ms 274.602 ms 13 hurricane-ic-138359-sjo-bb1.c.telia.net (213.248.67.106) 283.243 ms 281.890 ms 96.572 ms 14 10ge1-1.core1.fmt1.he.net (72.52.92.109) 126.793 ms 92.453 ms 96.489 ms 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 *^C

嗯，有趣。 也许你有这个防火墙。

如何ping？ 

 $ ping 65.49.51.227 PING 65.49.51.227 (65.49.51.227) 56(84) bytes of data. 64 bytes from 65.49.51.227: icmp_seq=1 ttl=49 time=97.5 ms 64 bytes from 65.49.51.227: icmp_seq=2 ttl=49 time=95.0 ms ^C --- 65.49.51.227 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 95.052/96.318/97.584/1.266 ms

很好用。 所以你的服务器正在运行。

但你的服务在哪里？ 

 $ telnet 65.49.51.227 http Trying 65.49.51.227... Connected to 65.49.51.227. Escape character is '^]'. GET / HTTP/1.1 HTTP/1.1 400 Bad Request Date: Thu, 10 Jul 2014 00:43:18 GMT Server: Apache Vary: Accept-Encoding Content-Length: 226 Connection: close Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>400 Bad Request</title> </head><body> <h1>Bad Request</h1> <p>Your browser sent a request that this server could not understand.<br /> </p> </body></html> Connection closed by foreign host.

您的Web服务器似乎正在运行。

所以，你至less应该做这些testing，以确定你的连接失败的地方。

ping和tracert的问题在于它们不是服务诊断工具。 如果你知道目标应该做出反应，Ping和tracert只能作为一般的连通性testing。 可以ping告诉我为什么我的网站不可用？ 不，它不能。 我的ISP，路由器或Web服务器可能会阻止ICMP，但很高兴为HTTP服务。 Tracert是检测一般networking路由问题的一个更好的工具，但不能告诉我为什么我不能访问一个网站，再次因为ICMP可能被阻塞在path的某处。

ping和tracert在你的networking工具包中有一席之地吗？ 是。 他们都可以成为一个红鲱鱼，并导致你错误的故障排除path？ 是的，我认为他们经常为那些不明白ping和tracert实际上告诉我们什么时候适合用作连接性诊断工具的人。

正如@迈克尔汉普顿所说，traceroute是你最好的朋友。 我能够解决和访问该网站就好了。

你至less能ping通吗？ 如果你不能ping它，那么你可能会被阻塞。 该服务器上是否运行了防火墙？ 你可以使用另一个IP来达到它？

Pingplotter Traceroute

飓风的虚拟主机服务器不响应traceroute。 许多ISP的许多中间路由器也是如此。 当提交像这样的问题时，总是运行ping以及traceroute，并包含两个结果。 Pathping，mtr和WinMTR也是有用的工具。