显式代理的客户端知道自己正在与代理通信。被拦截的浏览器却以为自己连的是网站。这一差别正是认证的核心。

普通的代理认证使用代理质询和代理授权响应。没有选择代理的客户端,不应该随手把代理凭据发给一个意料之外的中间人。

因此 Squid 的拦截指南并不支持把 proxy_auth 与拦截模式简单组合。一个能正常工作的 Basic 认证助手,也改变不了浏览器对远端端点的判断。

如果已识别的用户需要正常的、带认证的正向代理,就应显式配置客户端,可以直接配置,也可以通过合适的受管代理配置。请把那个监听及其认证策略与拦截监听分开。

认证门户、网络层身份系统或 TLS 拦截方案是另一种设计,对信任和部署的要求都不同。它不是对缺失的显式代理交互的一行修复。

不要通过把被拦截的服务公开或放行所有客户端来解决没有提示的问题。先判断需求到底是显式的用户认证,还是对从未配置代理的流量做拦截。两者需要不同的前提。

相关文章