该站点使用循环负载均衡和Windows NT身份validation与NTLM。
其中一个问题似乎是http 401.2响应过多。 有5个401.2响应后面跟着一个401.1，然后是200个响应。这个握手是为每个请求的文件完成的。
我想知道如果循环赛引起额外的401.2响应。
也许这是因为如果你需要一个有状态的连接，那么每个请求的auth都是坏的。 当负载平衡器设置为使用轮循机制时，我看到了类似的情况。 WSS上的ViewState会对服务器进行身份validation，视图状态会使用机器密钥进行encryption。 如果这些密钥没有在组中的所有服务器上同步，则视图状态将会变差，并强制重新进行身份validation……这将一直发生，直到发生对同一服务器的2或3个请求。 第一个请求没有被授权（请求1），我们知道这是因为它是一个新的用户，所以下一个请求发送auth（请求2），下一个请求发送请求1，但有一个良好的viewstate 3）。 如果在这个请求链中随时发送给另一台服务器，则重新开始。
检查系统日志，你有一堆asp.net错误视图状态不佳？ 奇怪的encryption错误？ 我不知道是否WSS在他们打到日志之前捕捉到了，在许多.net应用程序中，它没有被捕获，并且可以在事件查看器中看到。
解决方法是同步键或使用粘滞。
我不清楚你是在谈论循环DNS负载均衡，还是你正在使用第7层负载平衡器，它正在对HTTP会话进行循环负载平衡。 目前还不清楚是否允许客户端使用HTTP / 1.1持久连接到应用程序服务器。
总之，DNS负载平衡不应该导致你看到的行为。 第7层负载平衡certificate可以，特别是如果你不允许客户端保持持续连接对应用程序服务器开放。
在NTLM-over-HTTP环境中对客户端请求的401响应是正常的。 NTLM-over-HTTP握手是这样的：
您可以在http://www.innovation.ch/personal/ronald/ntlm.html （包括标题的字节对字节描述等）获得更深入的背景。
NTLM-over-HTTP身份validation会validation每个连接，因此需要连接Keepalive或HTTP / 1.1持久会话。 如果假设你没有使用永久连接，并且随机popup客户端请求并响应不同IIS服务器之间的NTLM挑战，那么你将遇到问题（坦率地说，我无法想象它甚至可以工作）。