Iis 7 IIS ARR（边缘）缓存（反向代理）-上游连接超时问题

我希望使用IIS应用程序请求路由作为反向代理缓存。我考虑了几种不同的选择，得出的结论是它最适合我的需要。 然而，我遇到了一个死胡同，我真的需要一些对ARR模块有更多经验的人的输入

我有以下设置：

• IIS ARR缓存代理请求到内部服务器场（加权） 循环负载平衡以使用最近的源服务器）
• 在IIS代理中禁用保持活动状态
• 服务器场由nginx web服务器组成
• IIS服务器具有RAM磁盘缓存

该用例是这样的：边缘服务器将接收字节范围请求，当它将内容提供给最终用户时，它将对其进行缓存（先在内存缓存中缓存60秒，然后将其写入RAM磁盘）。到目前为止，一切都正常工作，但当下一个最终用户开始请求相同的字节范围（现在在缓存中）时，我开始这样做，以便看到IIS边缘和nginx源之间的一些奇怪行为： 在第一个字节范围请求（由第二个最终用户）时，IIS服务器打开一个到nginx源的连接，但它不使用该连接，因为缓存中已经有请求的段。由于连接未被使用，因此由于超时（60秒），最终由nginx关闭。同时，第二个最终用户仍在请求缓存中的文件段。然后，这就是问题发生的地方，第二个最终用户到达文件中不在缓存中的点。在这里，我希望IIS的行为（保持活动状态被禁用）是，它将打开到源站的新连接，并开始获取文件中不在缓存中的部分。然而，我看到的行为是，IIS试图重用它在请求开始时打开的相同连接（没有意识到它已被源服务器删除）。我还使用了“失败的请求跟踪”来验证这一点，其结果是IIS没有从源站获得预期的回复（因为连接不再存在），然后反过来，向最终用户返回502.3

---

我已经验证了在源端增加连接超时将“解决”问题，但这并不是一个切实可行的解决方案，因为我基本上必须设置一个无限超时，这可能会在源端造成一组全新的问题。是否有任何方法可以控制IIS如何处理此上游连接（即，当它实际需要来自源站的数据时，强制它打开新连接，或者让它意识到源站关闭了连接）？

适用于可能遇到相同问题的任何人；经过与微软的反复讨论，这实际上是ARR模块中的一个缺陷，将在即将发布的版本中解决