我们的ASP.NET应用程序（最近更新为ASP.NET 4.0）的一些用户报告在Google Chrome中接收页面挂起 – 特别是Chrome错误：
此网页无法使用。 错误7（net :: ERR_TIMED_OUT）：操作超时。
用户声称其他网站都很好 – 这只是我们的麻烦 – 当他们尝试其他浏览器与我们的应用程序（例如FF / IE），这些浏览器都很好。
我们当然质疑他们安装的Chrome（版本？/病毒？） – 这就是所有谷歌浏览器论坛所说的关于这个错误和挂起。
我们决定做一些我们自己的testing，我们在Windows 7和最新版本的Chrome（安装没有扩展）下间歇性地收到了“Error 7”。
在我们收到错误的那一刻，我们试着用IE / FF来打这个应用程序 – 他们没事。
此外，根据我们对networking日志的分析，当我们收到“Error 7”时，我们的Web服务器（Win 2008 R2下的IIS 7.5，完全打补丁）没有收到来自Chrome的HTTP请求。
所以对于我们来说，神秘的一点是，为什么Chrome浏览器周期性地不能build立到我们的networking服务器的HTTP连接，而其他浏览器则完全没有问题。
我知道这是一个模糊的情景，我们无法一直重现。 但是如果有人对我们可以研究的东西有一些想法 – 或者我们可以尝试的一些进一步的testing，那么肯定会感激。
更新：
在我们的testing中，这个问题似乎可以通过（在Chrome中）选项> Under the Hood> Network> Change proxy settings …> LAN设置，并确保没有select“自动检测设置” 这个解决scheme是在一个Google论坛上find的。
这是一个奇怪的。 您可能需要使用Wireshark之类的工具在IIS之前进行检查。 我最近有一个相当类似的问题，虽然它不是基于浏览器的。 我们的Broadcomnetworking适配器一到达服务器，就会在重负载下丢弃一些数据包。 我不得不使用Wireshark来certificate请求在网卡上丢失了。 驱动程序更新大多解决了这个问题，尽pipe我们最终完全换出了NIC。
如果出于某种原因不喜欢Chrome浏览器代理，请检查所有防火墙IPS策略。
尝试在chrome.exe的命令行上运行以下开关…..
-disable-SSL-假开始
由于Chromeselect包含的草稿规范“function”，因此我们在几个SSL站点上遇到了一些问题。