我正在研究从AWS切换到Azure并开始遇到有关负载均衡器级别的默认4分钟超时的一些问题。他们似乎最近对您现在可以将此值配置为最多30分钟（http://azure.microsoft.com/blog/2014/08/14/new-configurable-idle-timeout-for-azure-load-balancer/）的位置进行了一些更改，但除此之外还有。
当我尝试将我的hg存储库克隆到我的VM实例时，问题正在显现。回购相当大，克隆约15分钟，传输完成，所有网络活动停止，回购处理开始，我几乎立即收到以下错误消息：
＆＃34; abort：错误：连接尝试失败，因为连接方在一段时间后没有正确响应，或者建立的连接失败，因为 连接的主机未能响应＆＃34;
我认为这是因为LB超时而发生的，尽管我预计它会在hg克隆网络活动停止后4分钟发生，而不是在之后立即发生。
相关部分（以及我的问题的核心）是，在我收到此错误消息后，我立即尝试再次克隆，我立即再次收到以下消息：
＆＃34; abort：错误：连接尝试失败，因为连接方在一段时间后没有正确响应，或者建立的连接失败，因为 连接的主机未能响应＆＃34;
在超时发生后，LB似乎立即拒绝了我的请求！如果我等待10-20分钟，我可以尝试再次克隆。如果我猜测，也许这是一个反DOS的机制？ 我的问题是：
我正在处理的项目的主要用途包括上传大文件（最多100mb），如果客户超过分配的超时窗口，我不希望它们被阻止访问我的服务
答案 0 :(得分：0)
我建议重新检查参与负载平衡的所有计算机。听起来好像负载均衡器确定传入的数据包是一个新的会话，这会引发主机选择，并且通常会将您发送到您正在与之交谈的机器之外的其他机器，但是参与LB的某些主机没有正在侦听正确的端口为您服务。服务级别监控应该抓住这个，如果它已经配置，但你提到这是一个新的实现。
上面描述的使用模式也可以通过第一次获得一台好的机器，然后是一台糟糕的机器进行回购处理，然后是一台糟糕的机器再次尝试来解释。