我和我的团队一直试图通过反向代理发布我们的TFS http端点。 TFS使用NTLM身份验证进行身份验证，不鼓励进行基本身份验证：https://docs.microsoft.com/en-us/vsts/integrate/get-started/auth/tfs-basic-auth。由于NTLM是有状态的，因此通过反向代理会遇到挑战。忽略这个问题的悠久历史，现在的情况如下：
我们使用NTLM身份验证运行TFS 2017到后端域，TFS托管在Windows Server 2016上。反向代理服务器位于DMZ网络中，通过防火墙将其与TFS服务器分开，但是有一个防火墙规则打开端口TCP 8080从反向代理服务器到反向代理服务器的TFS服务器，反向代理服务器是与TFS相同的后端域的成员。在反向代理服务器上，我们使用带有URL重写插件的IIS 7作为Windows Server 2008 R2上的反向代理技术。
为了讨论起见，此处更改的TFS端点是：http://backendserver.example.com:8080/tfs/。反向代理网站在此处再次更改为http://reverseproxy.example.com:8081/。重写规则是对正则表达式进行过滤：tfs /(.*），重写URL为http://backendserver.example.com:8080/ {R.0}。所有其他设置基本没有变化。
因此，当我们直接（从反向代理）访问tfs端点时，它工作正常，防火墙是打开的，因此常规URL工作正常（上面列出）。但是，当我们尝试反向代理端点（http://reverseproxy.example.com:8081/tfs/）时，我们不断重新获得401错误的身份验证。当我们尝试运行相同的反向代理网址但作为重定向（网址重写 - ＆gt;编辑入站规则 - ＆gt;操作 - ＆gt;操作类型 - ＆gt;重定向）时，它会正确地将主页重定向到TFS，身份验证成功，以及所有其他TFS中的页面，在请求时，正确加载，无需额外的身份验证挑战。
有谁知道为什么会出现这些401错误？多次尝试失败后，我的帐户未被锁定，因此我有理由相信这些失败并非来自后端域本身。谢谢大家。