我希望将IIS应用程序请求路由用作反向代理缓存。我已经看了几个不同的选项，并得出结论，它最符合我的需求。 但是，我遇到了一种死胡同，可能真的使用了一些对ARR模块有更多经验的人的输入。
我有以下设置：
用例是边缘服务器将接收字节范围请求，并且当它向最终用户提供内容时，它将缓存它（在内存缓存中前60秒，然后将其写入RAM磁盘）。到目前为止一切正常，但是当下一个最终用户开始请求相同的字节范围（现在在缓存中）时，我开始这样看到IIS边缘和nginx起源之间的一些奇怪的行为： 在第一个字节范围请求（由第二个最终用户）时，IIS服务器打开与它不使用的nginx源的连接，因为它已经在缓存中具有所请求的段。由于没有使用连接，由于超时（60秒），它最终被nginx关闭。同时，第二个最终用户仍在请求缓存中的文件段。然后，这就是问题发生的地方，第二个最终用户到达文件中不在缓存中的一个点。我期望IIS在这里的行为（保持keep-alive被禁用）是它将打开与源的新连接并开始获取不在缓存中的文件部分。然而，我看到的行为是IIS尝试重用它在请求开始时打开的相同连接（没有意识到它已被原点丢弃）。我已经使用“失败的请求跟踪”来验证这一点，结果是IIS没有得到来自原点的预期回复（因为连接不再存在），然后又返回一个502.3给最终用户。
我已经确认增加原点上的连接超时将“解决”问题，但这不是一个真正可行的解决方案，因为我基本上必须设置无限超时，这可能会导致一系列全新的问题原点方面。有没有办法控制IIS如何处理这个上游连接（即当它实际需要来自原点的数据时强制它打开一个新连接，或让它意识到原点关闭了连接）？
答案 0 :(得分：1)
对于任何可能遇到同样问题的人;经过与微软的一些来回，这实际上是ARR模块中的一个错误，将在即将发布的版本中得到解决。