很长一段时间以来，我在家用Wi-Finetworking时遇到了一个非常奇怪的问题。 我有一个BT Voyager 2100 ADSL调制解调器和一个iMac，老化的PowerBook和一台连接到它的无线电。 问题是，我永远不能访问less数的某些网站，因为他们总是超时。
没有什么明显的以任何方式连接这些网站。 我遇到的一些例子是www.adobe.com ， www.microsoft.com ， www.portsmouthguildhall.co.uk （本地场所）和subtraction.com （一个博客）。 我可以ping一些没有问题的网站; 没有超时。 事实上，我曾经能够访问subtraction.com，仍然可以得到它的RSS源。 我只是无法再在networking浏览器中查看网站。 这是一个非常孤立的问题 – 对于我的大多数互联网使用一切正常。
这显然不是个人电脑的问题，因为他们都有这个问题，所以它必须是我的路由器甚至ISP下游的问题。 我已经升级了路由器到最新的固件，并尝试重置它，但它没有解决问题。
我怎样才能诊断问题出在哪里？ 我不知道从哪里开始 有没有我可以使用的任何UNIXnetworking命令（我有Mac OS X）？
谢谢你的帮助。
编辑：遵循Alnitak的build议，我尝试了traceroute和ping adobe.com。 正如你所看到的，traceroute永远不会到达那里：
$ traceroute adobe.com traceroute to adobe.com (192.150.18.117), 64 hops max, 40 byte packets 1 voyager.home (192.168.1.1) 1.975 ms 1.505 ms 1.574 ms 2 lo0-plusnet.ptn-ag2.plus.net (195.166.128.53) 28.476 ms 47.139 ms 28.036 ms 3 ge0-0-0-204.ptn-gw02.plus.net (84.92.3.93) 28.520 ms 37.297 ms 33.186 ms 4 te2-2.pte-gw2.plus.net (212.159.1.106) 35.670 ms 36.262 ms 34.995 ms 5 80.239.193.141 (80.239.193.141) 33.932 ms 28.600 ms 28.764 ms 6 ldn-bb1-link.telia.net (80.91.248.90) 29.649 ms 28.149 ms 30.857 ms 7 ldn-b5-link.telia.net (80.91.249.178) 27.991 ms 28.014 ms 28.490 ms 8 verio-129583-ldn-b5.telia.net (213.248.100.50) 28.468 ms 29.286 ms 31.702 ms 9 ae-1.r23.londen03.uk.bb.gin.ntt.net (129.250.5.237) 30.871 ms 29.295 ms ae-1.r22.londen03.uk.bb.gin.ntt.net (129.250.5.233) 28.614 ms 10 ae-0.r22.londen03.uk.bb.gin.ntt.net (129.250.4.85) 29.732 ms as-0.r20.nycmny01.us.bb.gin.ntt.net (129.250.3.254) 108.909 ms ae-0.r22.londen03.uk.bb.gin.ntt.net (129.250.4.85) 28.505 ms 11 ae-0.r21.nycmny01.us.bb.gin.ntt.net (129.250.2.26) 109.164 ms as-0.r20.nycmny01.us.bb.gin.ntt.net (129.250.3.254) 104.860 ms ae-0.r21.nycmny01.us.bb.gin.ntt.net (129.250.2.26) 111.253 ms 12 as-0.r20.asbnva02.us.bb.gin.ntt.net (129.250.2.9) 104.777 ms ae-0.r21.nycmny01.us.bb.gin.ntt.net (129.250.2.26) 109.973 ms as-0.r20.asbnva02.us.bb.gin.ntt.net (129.250.2.9) 108.774 ms 13 as-0.r20.asbnva02.us.bb.gin.ntt.net (129.250.2.9) 103.691 ms ae-3.r21.asbnva01.us.bb.gin.ntt.net (129.250.2.128) 104.958 ms as-0.r20.asbnva02.us.bb.gin.ntt.net (129.250.2.9) 104.455 ms 14 as-3.r20.snjsca04.us.bb.gin.ntt.net (129.250.2.167) 197.595 ms ae-3.r21.asbnva01.us.bb.gin.ntt.net (129.250.2.128) 105.027 ms 106.565 ms 15 * as-3.r20.snjsca04.us.bb.gin.ntt.net (129.250.2.167) 179.946 ms * 16 * te-5-3.r02.snjsca04.us.ce.gin.ntt.net (128.241.219.86) 176.374 ms * 17 * * te-5-3.r02.snjsca04.us.ce.gin.ntt.net (128.241.219.86) 189.724 ms 18 * * * 19 * * * 20 * * * ^C 现在从第14跳开始尝试ping。 正如你所看到的，最后一个ping有20％的丢包率：
$ ping -s 1492 as-3.r20.snjsca04.us.bb.gin.ntt.net PING as-3.r20.snjsca04.us.bb.gin.ntt.net (129.250.2.167): 1492 data bytes 1500 bytes from 129.250.2.167: icmp_seq=0 ttl=55 time=214.555 ms 1500 bytes from 129.250.2.167: icmp_seq=1 ttl=55 time=215.339 ms 1500 bytes from 129.250.2.167: icmp_seq=2 ttl=55 time=221.211 ms 1500 bytes from 129.250.2.167: icmp_seq=3 ttl=55 time=224.296 ms ^C --- as-3.r20.snjsca04.us.bb.gin.ntt.net ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 214.555/218.850/224.296/4.062 ms $ ping -s 1492 as-3.r20.snjsca04.us.bb.gin.ntt.net PING as-3.r20.snjsca04.us.bb.gin.ntt.net (129.250.2.167): 1492 data bytes 1500 bytes from 129.250.2.167: icmp_seq=0 ttl=55 time=299.852 ms 1500 bytes from 129.250.2.167: icmp_seq=1 ttl=55 time=326.598 ms 1500 bytes from 129.250.2.167: icmp_seq=2 ttl=55 time=243.278 ms 1500 bytes from 129.250.2.167: icmp_seq=3 ttl=55 time=214.610 ms 1500 bytes from 129.250.2.167: icmp_seq=4 ttl=55 time=232.900 ms ^C --- as-3.r20.snjsca04.us.bb.gin.ntt.net ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 214.610/263.448/326.598/42.517 ms $ ping -s 1492 te-5-3.r02.snjsca04.us.ce.gin.ntt.net PING te-5-3.r02.snjsca04.us.ce.gin.ntt.net (128.241.219.86): 1492 data bytes 1500 bytes from 128.241.219.86: icmp_seq=0 ttl=245 time=349.851 ms 1500 bytes from 128.241.219.86: icmp_seq=1 ttl=245 time=270.748 ms 1500 bytes from 128.241.219.86: icmp_seq=2 ttl=245 time=334.406 ms 1500 bytes from 128.241.219.86: icmp_seq=3 ttl=245 time=220.046 ms ^C --- te-5-3.r02.snjsca04.us.ce.gin.ntt.net ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 220.046/293.763/349.851/51.869 ms $ ping -s 1492 te-5-3.r02.snjsca04.us.ce.gin.ntt.net PING te-5-3.r02.snjsca04.us.ce.gin.ntt.net (128.241.219.86): 1492 data bytes 1500 bytes from 128.241.219.86: icmp_seq=0 ttl=245 time=472.908 ms 1500 bytes from 128.241.219.86: icmp_seq=1 ttl=245 time=228.290 ms 1500 bytes from 128.241.219.86: icmp_seq=2 ttl=245 time=231.048 ms 1500 bytes from 128.241.219.86: icmp_seq=3 ttl=245 time=229.906 ms ^C --- te-5-3.r02.snjsca04.us.ce.gin.ntt.net ping statistics --- 5 packets transmitted, 4 packets received, 20% packet loss round-trip min/avg/max/stddev = 228.290/290.538/472.908/105.296 ms
这听起来像是一个MTU问题。
您和那些不支持典型的1500字节MTU的站点之间可能存在一些问题，除此之外可能还有一个阻止用于“pathMTU发现”的ICMP数据包的防火墙，因此您的结尾无法分辨正常的MTU不能使用。
尝试一个traceroute，然后为每个跳转，尝试发送一个大的ping数据包（1492字节），看看是否有任何这些跃点拒绝返回数据包。
编辑 – 你的tcpdump输出显示你的端仍然试图启动TCP的“三次握手”，因为SYN位是从你的数据包发送的。 但是，从Adobe返回的数据包似乎被截断或格式不正确。 这很奇怪，因为在数据包中不应该有任何有效载荷，只是远端的SYN响应。 我需要看到一个完整的转储（包括-X选项）的前4个左右的数据包了解更多。
编辑2 – 基于您的详细tcpdumps我相信你的路由器是腐败的一些网站的TCP响应。 testing这个最好的方法是借用另一个品牌的路由器。
将其中一台电脑直接插入互联网连接，并让它从您的ISP那里获取所有的networking设置。 如果你不能访问网站，那么这是一个ISP问题，如果你可以，那么这是一个路由器的问题，你可以从那里去。
你可以尝试traceroute ，看看你的数据包有多远。 如果他们停在路由器上，那可能是个问题。 如果他们走得更远，您可能需要联系您的ISP。
再次读你的问题，你说你可以ping服务器成功，所以你可能没有看到任何tracerouteexception…
我绝对同意这个问题的基本症状听起来像是与PATH MTU问题有关。 还有其他的可能性，但这是最有可能开始的地方。
考虑到你提到的网站的重要性，可能是这种情况已经发生了很长一段时间，似乎不太可能是ISPnetworking中的问题……虽然给出了问题中所示的跟踪路由结果，path深度和总延迟在您的ISP上不会很好地发挥。 一般来说，任何体面的互联网服务提供商都应该在120ms以内的时间内将您带到任何主要/突出的networking资产（在美国境内）……但是我离题了。
使用traceroute和ping来诊断问题是非常有帮助的，但是鉴于在不同位置的ICMP阻塞/过滤的可能性/可能性，它远非一个明确的工具解决scheme。 而且，由于这个原因，除了在熟练的分析师手中，很难区分与ICMP相关的具体问题和防火墙之间的区别。
排除MTU问题的最好方法是从一个有问题的计算机中减less以太网接口的MTU开始。 因为你提到你有一台MAC电脑，请参阅这里介绍的MAC系统的程序。
如果你开始降低你的接口MTU，因为这个过程一次描述的步长是100字节，而检查function是从1400下降到500字节…..如果问题在其中一个步骤突然消失，那么你肯定有一个path的MTU问题。 如果降到500，至less不能解决问题，那么这不是一个pathMTU问题，你可以继续研究其他的可能性（在你把MTU切换回开始的地方……这可能是1500字节）。
我现在已经解决了这个问题，最后修复起来非常简单。 我用ISP（PlusNet）login了一个支持电话，他们给我发了一个论坛post的链接，说明这个问题是我路由器固件中的一个错误。 解决方法是简单地将路由器的Internet连接MTU设置为1500（默认值为1400），以使其与路由器的LAN侧MTU相匹配。
感谢所有提供帮助和build议的人。 我会接受Alnitak的回答，仅仅是因为他/她在这个问题上一直坚持下来，不断回来提供更多的build议和事情来尝试。
你没有提到你是否正在通过代理服务器。 看看你的ISP是否可能透明地代理你可能会很有趣，我认为这种做法非常邪恶，但我认为它很常见。 也许你可以尝试http://tracetcp.sourceforge.net/usage_proxy.html，并对不工作的主机执行tcp跟踪，这可能很有趣。
同时通过代理服务器应该允许您访问这些站点，所以您至less有一个解决方法。
你有没有试过联系你的ISP有关这个问题？
对我来说，你的traceroute和ping结果是完全正常的。 最后缺less回复是正常的，也就是说最后一次发送ICMP的HOP跳到达应答。 tracepath是一个实用工具，可以用来诊断可能帮助你的mtu问题。
我同意这听起来是pathMTU发现的失败。
对于我来说（在Linux上）解决这个问题的方法是在内核中启用高级路由器支持，在内核configuration的netfilter / core netfilter部分中启用TCPMSS目标支持。 然后告诉iptables强制最大分段大小：
iptables -t nat -A PREROUTING -p tcp –tcp-flags SYN，RST SYN -j TCPMSS –clamp-mss-to-pmtu
另一种方法是select一个非常小的mtu（可能从那里向上），而这可能会带来自己的问题，它应该使这些网站可达。
我现在已经从本地机器向www.adobe.com发送了一个类似的TCP连接请求数据包（唯一的区别是源IP地址），并将我得到的响应数据包与最新的tcpdump中的响应数据包进行了比较。
我在IP / TCP头文件中发现了3个不同之处：
我的猜测是你的路由器试图通过添加一个MSS TCP选项来变聪明，但在某些情况下会弄乱TCP报头。 你的路由器是否有任何“MSS夹紧”设置 – 如果是这样，我会尝试禁用这些设置。 否则，我会build议询问PlusNet支持（向他们展示tcpdump输出）。
在访问某些stream媒体audio/video资源时，我的路由器出现类似的问题。 更新WMPnetworking设置可解决特定问题; 不知道在你的情况下是否有关。
会出现一个肢体，并说这是一个子网掩码问题，无论是与您的本地局域网（应该是255.255.255.0）或与您的WAN端。
我build议这样做，因为如果子网掩码被错误地设置为255.254.255.0之类的东西，最终可能会出现奇怪的结果 – 对于大网站（具有多个Alogging）看起来是随机可达性。