我和我的团队一直在尝试通过反向代理发布我们的 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 错误。当我们尝试运行相同的反向代理 url 但作为重定向（url 重写 -> 编辑入站规则 -> 操作 -> 操作类型 -> 重定向）时，它会正确地将主页重定向到 TFS，身份验证成功，以及 TFS 中的所有其他页面，请求时，正确加载而无需额外的身份验证挑战。
有谁知道为什么会发生这些 401 错误？在多次尝试失败后，我的帐户并没有被锁定，所以我有理由相信这些失败不是来自后端域本身。感谢大家。