另一方面，如果某条防火墙规则阻断了端口80，那么输出结果则应如下所示：
$ sudo /sbin/iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 reject-with(
icmp-port-unreachable
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination

　　在后一种情况下，我们显然需要修改防火墙规则，以允许服务器接收来自端口80的主机数据流量。

　　网络缓慢状况的故障排查

　　从某种角度来说，网络无法工作的问题更容易解决。当一台主机无法访问，我们可以执行前面讨论过的故障排查步骤直到一切恢复正常。但如果仅仅是网络缓慢，追查其根本原因往往变得更为棘手。本章节将讨论一些相关技巧，帮助大家追踪导致网络速度缓慢的各种原因。

　　DNS问题

　　虽然DNS在网络出现问题时常常蒙冤受责，但在导致网络性能不佳方面，DNS倒真该被优先检查一番。举例来说，如果我们为某个域名配置了两台DNS服务器，那么在第一台出现问题时，我们发出的DNS请求会等待30秒之后才传输至第二台DNS服务器。虽然当我们使用像dig或nslookup这样的工具时此类情况显得一目了然，但对于日常使用来说，DNS故障往往会以令人意外的方式造成网络缓慢；这是因为有太多服务需要借助DNS实现将主机名称解析为IP地址的工作。这些问题甚至有可能影响到我们的网络故障诊断工具。

　　Ping、tracerouter、oute、netstat甚至包括iptables在内的多款网络故障排查工具都会受到DNS问题的牵连而导致速度缓慢。在默认情况下，上述所有工具都会尽可能尝试将IP地址解析为主机名称。一旦DNS服务器有了毛病，这些命令会在查找IP地址的过程中停滞不前并终导致执行失效。在ping或traceroute方面，问题表现为整个ping应答周期耗时相当长，但终的请求往返时间却比较短。而在netstat与iptables方面，其请求结果可能会拖延很久才输出到屏幕上，这是因为系统一直在等待已经超时的DNS请求。

　　在前面提到的各种情况中，我们都能很容易地绕过DNS来保证故障排查结果的准确性。所有列举的命令都可以通过添加-n参数来禁止其将IP地址解析为主机名称。我也是刚刚养成在所有命令后加-n的好习惯--正如第一章提到的那样--除非我确定自己想解析IP地址。

　　注意：DNS解析还可能以其它一些意想不到的方式影响我们的web服务器性能。某些web服务器会根据配置对访问的第一个IP地址进行解析，并将得到的主机名称记录下来。虽然这会让记录信息更具可读性，但同时也会在出现问题时大大降低web服务器的速度--例如存在大量访问者时。这时web服务器会忙着解决这些IP地址的解析工作，而选择将服务流量搁置在一边。

　　利用traceroute解决网络缓慢问题

　　当处于不同网络中的服务器与主机间的连接发生拖慢状况时，我们可能很难追查到真正的罪魁祸首。尤其是在拖慢以延迟形式（即响应所消耗的时间）出现而不涉及全局带宽的情况下，真正能力挽狂澜的只有traceroute了。正如前文所说，tracerout是一种在远程网络中测试客户机与服务器间全局连接的有效方式，但它同时也能有效诊断出导致网络缓慢的潜在根源。由于traceroute会输出当前与目标设备之间每次数据转发所消耗的时间，因此我们可以利用它追踪由地域相距过大或网关问题所引发的过载及网络缓慢原因。举例来说，我们利用traceroute检查美国与中国两边的雅虎服务器，输出结果如下所示：

$ traceroute yahoo.cn
traceroute to yahoo.cn (202.165.102.205)， 30 hops max， 60 byte packets
1 64-142-56-169.static.sonic.net (64.142.56.169) 1.666 ms 2.351 ms 3.038 ms
2 2.ge-1-1-0.gw.sr.sonic.net (209.204.191.36) 1.241 ms 1.243 ms 1.229 ms
3 265.ge-7-1-0.gw.pao1.sonic.net (64.142.0.198) 3.388 ms 3.612 ms 3.592 ms
4 xe-1-0-6.ar1.pao1.us.nlayer.net (69.22.130.85) 6.464 ms 6.607 ms 6.642 ms
5 ae0-80g.cr1.pao1.us.nlayer.net (69.22.153.18) 3.320 ms 3.404 ms 3.496 ms
6 ae1-50g.cr1.sjc1.us.nlayer.net (69.22.143.165) 4.335 ms 3.955 ms 3.957 ms
7 ae1-40g.ar2.sjc1.us.nlayer.net (69.22.143.118) 8.748 ms 5.500 ms 7.657 ms
8 as4837.xe-4-0-2.ar2.sjc1.us.nlayer.net (69.22.153.146) 3.864 ms 3.863 ms 3.865 ms
9 219.158.30.177 (219.158.30.177) 275.648 ms 275.702 ms 275.687 ms
10 219.158.97.117 (219.158.97.117) 284.506 ms 284.552 ms 262.416 ms
11 219.158.97.93 (219.158.97.93) 263.538 ms 270.178 ms 270.121 ms
12 219.158.4.65 (219.158.4.65) 303.441 ms * 303.465 ms
13 202.96.12.190 (202.96.12.190) 306.968 ms 306.971 ms 307.052 ms
14 61.148.143.10 (61.148.143.10) 295.916 ms 295.780 ms 295.860 ms
...

　　既然不了解有关网络的更多细节信息，我们也能够单纯通过往返时间把握数据包的动向。从第九次跳转开始，IP地址变成了219.158.30.177，这意味着数据包已经离开美国抵达中国，而跳转的往返时间也从3毫秒提高到275毫秒。