我在 Linux CentOS 5.4 上运行 Squid 代理（最新版本 3.1.4），使用 Samba 3.5.4，以便允许域用户进行经过身份验证的 Web 访问；一切运行正常，甚至完全支持 Windows 7 客户端。身份验证对于域用户是透明的，而对于非域用户则明确要求进行身份验证，并且如果用户可以提供有效的域凭据，它就可以正常工作。一切都很好。
然后，Outlook Anywhere 开始发挥作用，痛苦和折磨随之而来。
当 Outlook（无论是 2007 还是 2010，都没关系）在 Windows XP 客户端上运行时，它可以通过 Squid 代理顺利连接到其远程 Exchange 服务器。
当它在 Windows 7 上运行时，则不会。
如果从代理取消身份验证要求，则一切在 Windows 7 上也能正常运行，因此问题显然与 Squid 的 NTLM 身份验证有关。
通过更深入的挖掘（WireShark），我发现 Outlook Anywhere 在 Windows 7 上运行时使用 HTTP 1.1，而在 Windows XP 上运行时使用 HTTP 1.0。而且看起来 Squid，即使是最新版本，在正确处理 HTTP 1.1 方面仍然存在一些严重问题，特别当 SSL 和代理身份验证混合在一起时。
在等待 Squid 全面正式支持 HTTP 1.1 期间（这看起来可能需要相当很长时间了），我正在寻找以下解决方案之一：
- 如果可能的话，让 Squid 正确处理这个问题。
- 识别 Outlook Anywhere 连接并让 Squid 不要求对其进行身份验证。但这并不容易：同样，Outlook 在 Windows XP 和 Windows 7 上运行时的行为有所不同，在 Windows XP 上，Outlook 发送一个非常好的用户代理字符串“MSRPC”，而在 Windows 7 上它不发送任何字符串（为什么？为什么?!?)。
- 即使在 Windows 7 上运行时，也强制 Outlook Anywhere 使用 HTTP 1.0。不，这并不像在 Internet Explorer 中取消选择“使用 HTTP 1.1”那么简单，看起来 Outlook 会忽略该设置并自行选择使用哪种协议。
- 任何其他可行的解决方案都不涉及将特定目标 Exchange 服务器列入白名单，这是我试图避免的最后手段解决方案。
答案1
Windows 7、Server 2008，我相信甚至 Vista 默认都不支持 NTLMv1。如果它在 XP 上运行，但在 Windows 7 上不运行，我会先启用 NTLMv1，看看它是否能解决您的问题。以下是当我遇到类似问题时帮助过我的帖子。Windows7 - “指定的网络密码不正确。”但实际上密码是正确的
答案2
加载rpcping.exe到 Dependency Walker 中，很明显它使用的是WinHttp.dll而不是WinInet.dll。因此，将WinHttp.dllWindows XP SP3 中的 复制到C:\Program Files\Microsoft Office\Office11所在Outlook.exe的位置会导致 Outlook 发送带有 和所有其他标头字段的HTTP/1.0请求User-Agent，就像在我的旧计算机上一样。
Windows 7 SP1 上的现有版本：6.1.7601.17514
从 Windows XP SP3 复制的版本：5.1.2600.6175
这不是最干净的解决方案，但目前只能这样了。如果有人有更好的主意，我会洗耳恭听……
答案3
3.1.4 不是 Squid 的最新版本 — 3.1 分支中的当前上游版本是 3.1.16，并且变更日志中有许多与 HTTP 1.1 兼容性相关的更改。您可能需要尝试更新的版本。
这篇文章来自 squid-users至少在一月份，即使使用最新的 3.1.x 也是不够的，并且所需的 HTTP 1.1 支持修复仅在 3.2 测试版中。