在 StackOverflow 上，我们每天都会看到一些“请求超时”异常。
事实：
我们已经测试了基于服务器的超时（即使用 Thread.Sleep）并且所有表单变量都被正确捕获在异常日志中——这使我们相信客户端在分配的时间内发送请求时遇到了问题。
任何关于如何捕获/调试这种情况的想法都非常受欢迎！
我在使用小型 AJAX 网络服务的生产服务器上遇到了同样的问题。在我们的防火墙外进行数据包捕获后，我们发现服务的 POST 来自两个 TCP 段，而第二个段从未到达我们。（第一个数据包只包含标头，第二个丢失的数据包应该是 json 正文）所以基本上 IIS 只是坐在那里等待其余的 POST。在配置的超时之后，服务器向客户端发送一个 RST 数据包并记录“请求超时”错误 - 这是正确的行为。
我们试图在没有太多运气的情况下获得客户端复制，但在我们的情况下，这似乎完全与网络相关（或者可能是一些不喜欢帖子内容的“安全”软件）。
如果您正在运行 IIS 7，则可以使用Failed Request Tracing。我实际上并没有将它用于超时，我主要将其设置为仅捕获特定的 http 错误代码。但我知道你可以让它转储任何花费超过 X 时间的请求的痕迹。
您是否尝试过通过 telnet 手动发布，而根本没有完成 POST。我很想看看你是否可以复制你所看到的行为。鉴于该站点的性质，如果您故意收到一些格式错误的 POST 来尝试破解系统，我不会感到惊讶。
我注意到有时我需要重新启动 Safari 以便在某些操作挂起后让 SO 再次工作，但我认为这是我的问题。
本文介绍了如何使用 windbg 捕获此问题：
我们过去经常在我们非常高流量的网络客户端上看到这些——想知道它是否相关。据说发生的是 HttpWebRequest（我假设您在使用 HttpWebResponse 时遇到问题？也许他们也有同样的问题）在幕后使用了一些 janky 线程池，即使您的请求是同步的。有时某些东西会死锁，因为堆栈中更高的一些其他 .NET 对象正在使用相同的系统线程池，一个会饿死另一个，最终导致超时。我认为这个问题在这里描述得更好：http: //www.deez.info/sengelha/2005/03/03/beware-threadpools-and-httpwebrequest/
我还会扫描您日志中的 IP 地址，以查看是否是同一个人反复出现问题。您知道，可能有些人仍在使用拨号帐户，或者他们的终端可能存在其他网络问题。但是，当然，不要在没有尽可能多的调查的情况下将其注销。
从 IIS6 切换到 IIS7 后，我们的网络服务器遇到了同样的“请求超时”问题。我相信这个问题是特定于 IIS7 的。我的猜测是，在将请求移交给 ASP.Net 进行处理之前，这些错误在 IIS6 的处理链中被进一步吞没或忽略了。我今天打开失败的请求跟踪，看看是否可以捕获有关该问题的更多信息。到目前为止，您对客户端原因的解释似乎是最有效的。