很长一段时间以来，我家里的无线网络都遇到了一个非常奇怪的问题。我有一个BT Voyager 2100 ADSL 调制解调器和一个 iMac、老化的 PowerBook 和一台无线连接到它的 PC。问题是我永远无法访问少数特定网站，因为它们总是超时。
没有任何明显的东西可以以任何方式连接这些网站。我遇到的一些例子是www.adobe.com、www.microsoft.com、www.portsmouthguildhall.co.uk（当地场所）和subtraction.com（博客）。我可以毫无问题地ping某些站点；没有超时。事实上，我以前可以访问 subtraction.com 并且仍然可以获取它的 RSS 提要。我只是无法再在网络浏览器中查看该网站。这是一个非常孤立的问题——对于我的大多数 Internet 用户来说，一切正常。
这显然不是个别计算机的问题，因为它们都有这个问题，所以它一定是我的路由器甚至是 ISP 下游的问题。我已经将路由器升级到最新固件并尝试重置它，但它没有解决问题。
我什至如何诊断问题出在哪里？我不知道从哪里开始！有没有我可以使用的 UNIX 网络命令（我有 Mac OS X）？
谢谢你的帮助。
编辑：按照 Alnitak 的建议，我尝试了 traceroute 并使用 adobe.com ping。如您所见，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 的站点之间可能存在某些问题，除此之外，可能是防火墙阻止了用于“路径 MTU 发现”的 ICMP 数据包，因此您无法判断无法使用正常的 MTU。
尝试跟踪路由，然后依次为每个跃点发送一个大的 ping 数据包（1492 字节），看看是否有任何跃点拒绝返回数据包。
编辑 - 您的
tcpdump输出显示您的终端仍在尝试启动 TCP 的“三次握手”，因为该SYN位是在您终端的数据包中发送的。然而，从 Adobe 返回的数据包似乎被截断或格式错误。这很奇怪，因为数据包中不应该有任何有效载荷，只有远端的 SYN 响应。我需要查看前 4 个左右数据包的完整转储（包括 -X 选项）才能了解更多信息。EDIT2 - 根据您详细的 tcpdump，我相信您的路由器正在破坏某些站点的 TCP 响应。最好的测试方法是借用另一个品牌的路由器。
将您的一台计算机直接插入您的互联网连接，让它从您的 ISP 获取所有网络设置。如果您无法访问这些站点，那么这是一个 ISP 问题，如果可以，那么这是一个路由器问题，您可以从那里开始。
你可以试试traceroute，看看你的数据包有多远。如果他们停在您的路由器上，那可能是那里的问题。如果他们走得更远，您可能需要与您的 ISP 取得联系。
再次阅读您的问题，您说您可以成功 ping 服务器，因此您可能在 traceroute 上看不到任何异常...
我绝对同意这个问题的基本症状听起来与 PATH MTU 问题有关的概念。还有其他可能性，但这是最有可能开始的地方。
鉴于您提到的站点的重要性，并且可能已经发生了很长一段时间，这似乎不太可能是 ISP 网络中的问题......尽管考虑到问题中显示的 traceroute 结果，路径深度和总延迟在您的 ISP 上表现不佳。一般来说，任何体面的 ISP 都应该让你在 120 毫秒以下的时间内访问任何主要/著名的网络资产（美国境内）……但我离题了。
正如其他人提到的那样，使用traceroute和ping来诊断问题非常有帮助，但考虑到 ICMP 在各个位置阻塞/过滤的可能性/可能性，它远非一个明确的工具解决方案。而且，正因为如此，除非在熟练的分析师手中，否则很难区分特定问题和防火墙与 ICMP 之间的区别。
排除 MTU 问题的最佳方法是首先降低其中一台出现问题的计算机的以太网接口的 MTU。由于您提到您有一台 MAC 计算机，因此请参阅此处针对 MAC 系统的过程。
如果您开始按照流程描述的方式降低接口 MTU，例如每次 100 个字节，并检查从 1400 到 500 字节的功能.....如果问题在其中一个步骤突然消失，那么您肯定有路径MTU问题。如果至少下降到 500 不能解决它，那么这不是路径 MTU 问题，您可以继续研究其他可能性（在您将 MTU 切换回它开始的位置之后......这可能是 1500字节）。
我现在已经解决了这个问题，最后修复非常简单。我用我的 ISP (PlusNet) 记录了一个支持电话，他们给我发了一个论坛帖子的链接，解释这个问题是我路由器固件中的一个错误。解决方法是将路由器的 Internet 连接 MTU 设置为 1500（默认为 1400），以便它与路由器的 LAN 端 MTU 匹配。
感谢所有提供帮助和建议的人。我将接受 Alnitak 的回答，仅仅是因为他/她在这方面坚持我，并不断回来提供更多建议和尝试的事情。
您没有提到您是否正在通过代理服务器。看看你的 ISP 是否有可能透明地代理你可能会很有趣，我认为这种做法非常邪恶，但我认为它很常见。也许您可以尝试http://tracetcp.sourceforge.net/usage_proxy.html并对不工作的主机进行 tcp 跟踪，这可能很有趣。
同时，通过代理服务器应该允许您访问这些站点，因此您至少有一个解决方法。
您是否尝试就此问题联系您的 ISP？
对我来说，您的 traceroute 和 ping 结果是完全正常的。最后没有回复是正常的，即发送ICMP max hop达到回复的最后一个HOP。tracepath 是一个实用程序，可用于诊断可能对您有所帮助的 mtu 问题。
我同意这听起来是路径 MTU 发现的失败。
对我来说，这个问题的解决方案（在 linux 上）是在内核中启用高级路由器支持，并在内核配置的 netfilter/core netfilter 部分启用 TCPMSS 目标支持。然后告诉 iptables 强制减小最大段大小：
iptables -t nat -A PREROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
另一种方法可能是选择一个非常小的 mtu（并且可能从那里向上工作），虽然这可能会带来自己的问题，但它应该使这些站点可以访问。
我现在已经从我的本地计算机向 www.adobe.com 发送了一个类似的 TCP 连接请求数据包（唯一的区别是源 IP 地址），并将我收到的响应数据包与您最新的 tcpdump 中的响应数据包进行了比较。
我在 IP/TCP 标头中发现了 3 个不同之处：
我的猜测是您的路由器试图通过添加 MSS TCP 选项来变得聪明，但在某些情况下会弄乱 TCP 标头。您的路由器是否有任何“MSS 钳制”设置 - 如果有，我会尝试禁用这些设置。否则，我建议询问 PlusNet 支持（向他们展示 tcpdump 输出）。
在访问某些流媒体音频/视频资源时，我的路由器锁定了类似的问题。 更新 WMP 网络设置解决了该特定问题；不确定它是否与您的情况相关。
我会说这是一个子网掩码问题，无论是您的本地 LAN（应该是 255.255.255.0）还是您的 WAN 端。
我建议这样做是因为如果子网掩码被错误地设置为 255.254.255.0 之类的东西，您最终可能会得到奇怪的结果 - 对于大型站点（具有多个 A 记录）看似随机的可达性。