我的情况与根除401 "未经授权"中提到的情况非常非常相似。回答之后是200个"ok";反应
但是它并没有为我们提供足够的响应。
我有一个简单的GET请求的例子，当在本地运行api而没有IIS时，结果是一个响应是OK/200:
但是当它托管在IIS上时，它返回两个401和一个200:
还有IIS网络认证配置:Config
在调用API的应用程序中，我们检查200响应代码，我们在代码中收到间歇性的200/401，这使得验证非常烦人，请求在每种情况下都能完美地通过。
如果这是NTLM身份验证的工作方式，那么是否有其他方法来验证对api的调用最终是否成功?最后，这就是我们想要在调用方应用程序中知道的。正如在一些文章中提到的，我已经尝试在IIS中将NTLM移到提供者列表的顶部(在底部协商)->身份验证→提供者列表，但这不能解决
谢谢你看一看。
编辑:这是fiddler在IIS情况下的请求头:
- 请求1与401:img 请求2:401:img
- 请求2:200:img
编辑2:根据MisterSmith的回答和其他一些阅读，这是NTLM身份验证的工作方式，它更多的是关于我们如何处理应用程序中的响应。
在我的情况下，我使用。net核心HttpClient库来发出请求，它处理NTLM身份验证的方式可能存在问题。如果有人对此感兴趣，可以在这里找到:NTLM认证HttpClient in Core
这基本上就是它的工作原理——用户的前两次握手请求还没有成功验证，所以401是预期的，也是完全合理的。
如果你能(以某种方式)让浏览器总是发送认证头(只针对这个站点!)，这将删除401中的一个，另一个是不可避免的，而不会完全放弃NTLM。
在本地运行和在IIS中运行的区别在于拦截和修改报头的身份验证模块。如果您在IIS中关闭auth，它也将返回单个200响应(这是一个测试，而不是一个解决方案)。
200/401这使得验证非常烦人
401、401、200将依次来自同一个套接字。如果您查看401的响应头，您应该能够确认哪些是预期的。此外，在IIS中运行的代码的访问日志和请求上下文中，IIS有一个可见的子状态。非常确定您可以根据子状态条件和标头重写—这可能有助于区分请求，作为最后的手段?
是否有其他方法来验证对api的调用是否成功最终
NTLM使用keep alive套接字发送多个请求——只是保持从套接字读取直到一个合理的超时，并存储接收到的最终响应代码。
将NTLM移至提供商列表的顶部
我不确定改变顺序会做什么，但我想到了一些事情-system.webServer/security/authentication/windowsAuthentication部分通常被锁定，因此在web上发生了变化。配置级别将被忽略，需要在机器上应用。配置水平。