有一个外部网站可以在一些电脑上打开，但似乎超时（或超时的症状，但从来没有实际上）在其他人。
似乎只影响（部分）我们较新的HP Pro 3305 MT工作站 。 所有这些都运行Win7 32位SP1与所有更新。 较旧的PC（Win7 32bit SP1和WinXP）不受影响。
使用谷歌浏览器和Firefox并没有什么区别。 在IE9兼容模式下打开网站有完全相同的症状。
所有PC都位于同一个本地networking（工作组）上，使用同一个互联网连接上相同的DNS服务器和网关（内部），在同一个子网上。 没有代理服务器，没有内容过滤，没有负载平衡等。只有组策略（本地）是更新调度。 本地防火墙都是一样的（卡巴斯基WP4），我们的外部防火墙没有IP特定的设置。
我无法控制外部网站，traceroute在所有PC上显示相同的目的地。 这是一个相当受欢迎的网站在我们的行业（园艺），我不知道有任何其他人（即使我们的姊妹公司其他网站）也有同样的问题。
更新：使用Fiddler2来监视HTTP请求，似乎由于某种原因没有得到满足？！
发送的请求：
GET http://www.rhs.org.uk/ HTTP/1.1 Host: www.rhs.org.uk Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.47 Safari/536.11 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-GB,en-US;q=0.8,en;q=0.6 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 login请求的提琴手2：
This session is not yet complete. Press F5 to refresh when session is complete for updated statistics. Request Count: 1 Bytes Sent: 567 (headers:567; body:0) Bytes Received: 0 (headers:0; body:0) ACTUAL PERFORMANCE -------------- ClientConnected: 17:02:33.720 ClientBeginRequest: 17:02:39.118 GotRequestHeaders: 17:02:39.118 ClientDoneRequest: 17:02:39.118 Determine Gateway: 0ms DNS Lookup: 0ms TCP/IP Connect: 46ms HTTPS Handshake: 0ms ServerConnected: 17:02:39.165 FiddlerBeginRequest: 17:02:39.165 ServerGotRequest: 17:02:39.165 ServerBeginResponse: 00:00:00.000 GotResponseHeaders: 00:00:00.000 ServerDoneResponse: 00:00:00.000 ClientBeginResponse: 00:00:00.000 ClientDoneResponse: 00:00:00.000 RESPONSE BYTES (by Content-Type) -------------- ~headers~: 0
logging一台正在工作的PC的成功请求（今天上午完成，原因是时间戳与上面不同）：
Request Count: 1 Bytes Sent: 493 (headers:493; body:0) Bytes Received: 20,413 (headers:525; body:19,888) ACTUAL PERFORMANCE -------------- ClientConnected: 08:22:47.766 ClientBeginRequest: 08:22:47.766 GotRequestHeaders: 08:22:47.766 ClientDoneRequest: 08:22:47.766 Determine Gateway: 0ms DNS Lookup: 26ms TCP/IP Connect: 30ms HTTPS Handshake: 0ms ServerConnected: 08:22:47.828 FiddlerBeginRequest: 08:22:47.828 ServerGotRequest: 08:22:47.828 ServerBeginResponse: 08:22:48.905 GotResponseHeaders: 08:22:48.905 ServerDoneResponse: 08:22:48.905 ClientBeginResponse: 08:22:48.905 ClientDoneResponse: 08:22:48.905 Overall Elapsed: 00:00:01.1388020 RESPONSE BYTES (by Content-Type) -------------- text/html: 19,888 ~headers~: 525
所以我的问题已经演变成：
更新2 ：
看到我的答案在下面。 我将来可能会接受，但如果不能重现问题（或解决方法），我想留下这个问题。
如果您想了解HTTP GET请求的区别，请从OWASP或其他代理服务器下载ZAP（Zed Attack Proxy），以便在发送到服务器之前检查每个数据包。 这将回答“两个请求之间有什么区别”的问题。
如果请求是相同的尝试另一个网卡。
你的网卡很可能是机载的。 尝试安装适当的驱动程序的PCI网卡，看看你是否可以到达那里。 听起来像硬件/驱动程序问题在这一点上。
我以前从来没有使用Fiddler，但基于在失败场景中未设置的“ServerGotRequest”意味着三件事之一：
我知道这是一个托pipe的服务器，你有权访问服务器日志或在其上运行嗅探器（即WireShark）来捕获数据，而你正在testing？ 如果是这样，请观察服务器日志文件是否有任何错误，然后运行嗅探器，直到工作站出现故障情况，然后查看服务器是否收到完整响应并尝试响应。
之后，检查Kapersky防火墙日志，看是否丢弃了任何数据包。 是否有可能在防火墙前设置一个嗅探器，并查看服务器的响应是否使它回到这么远？ 如果它进入防火墙，卡巴斯基不会放弃任何东西，那么可以认为它是安全的。
在这些testing中，我build议在其中一台失败的机器上运行WireShark。 它会显示出站连接，另外还应显示NIC收到的任何响应。 如果是NIC问题，则嗅探器跟踪应显示正在接收的数据包，并从那里确定是否需要更新NIC和/或驱动程序。
由于无法将嗅探器连接到防火墙的外部，因此您需要与您的ISP一起工作，让他们对离开您的路由器的数据包进行设置监控，但绝不会收到响应。
一旦ISP已经确认或驳斥你关于数据包发生位置的假设，有两种select：选项1：数据包将其发送到防火墙，但在失败的Web连接尝试期间不会发送到ISP。 scheme2：数据包通过防火墙到达ISPnetworking，但响应永远不会到来。
如果可能的话，选项1可能是最简单的replace和/或重新安装防火墙。 如果它是ISP提供的设备，则需要保存当前configuration，但在新系统上应用非常基本的configuration，以确保它不是与configuration有关的问题。
选项2会很好，因为它会让问题解决，但如果他们没有时间去查看，那么你就会被困在他们的答案中。 在这种情况下，它可能会离开他们的networking，并出去到他们的互联网提供商那里 – 进入另一个蠕虫的networking，试图找出一个数据包死亡的地方。
你能否确认工作机器与非工作机器是否是相同的品牌/型号。 你也可以确认你的ipv6在所有机器上都是一样的（在一个内部局域网上我会禁用ipv6）。 也作为最后一个检查 – 确保主机文件中可能会停止networking访问（c：\ windows \ drivers \ etc）
事实上，你已经排除了浏览器和硬件（使用现场光盘）让我觉得它必须是networking适配器相关的。
如果所有这一切都失败 – 绝对交换硬盘，看看问题是否遵循硬盘或networking。
我会比较有问题的系统上的networking掩码和网关地址，并将其与工作系统进行比较。
我之前就看到了这个问题，这就是原因 – 一个错误的（但还是有点用处的）网关地址。
从基础开始 – 你有两个不同系列的机器，可能有两个不同系列的网卡。 双方是否都要进行自动协商，如果是，他们是否同意适当的速度？ 尝试双方的硬编码作为一个实验，看看它是否有所改善（或者，如果它是双方硬编码，然后让双方进行谈判）。
之间有很大的差距
ClientConnected: 17:02:33.720
…和…
ClientBeginRequest: 17:02:39.118
要么丢失数据包，要么客户端安全软件被破坏。 使用Wiresharktesting前者是微不足道的 – 即使您没有看到数据包较less（重新传输），也可以确定注入延迟的方向性。
截至今天上午，这个问题是“固定的”。
我已经通过电子邮件与Piers Karsenbarg在几种不同的解决途径上工作，都是徒劳的。 网站上没有任何改变，机器上没有任何改变 – 除了一些Windows更新。 无法感谢Piers足以涉足这个问题，花费大量的时间来解决问题！
docker把我和这个问题联系在一起， 这些问题上有所有的症状（但没有任何原因）（即没有Type 1字体）。 但是有可能Windows更新（或一些Adobe更新） 解决了这个问题 – 我正在考虑replace或删除types1的字体。 更多信息可以在这里和这里find。