针对已知端点的抢先式 Basic 代理认证
判断抢先式 Basic 代理认证何时适用于固定端点，并避免让这一决定变成针对任意路由的凭据规则。
先等待挑战的客户端会等代理来询问。抢先式 Basic 客户端已经知道所选端点，并在第一个适用请求中发送凭据。去掉这次往返可能很有用。但这仍然是一个关于密码去向的决定。
在优化之前先了解端点
认证策略已知的固定私有代理，比可能选择陌生中间层的路由层要清晰得多。把账号绑定到预期的代理身份和协议上。不要构建一个用同一个公司密码应答所有挑战的通用回调。
Basic 传输的是账号的 base64 表示，而不是加密证明。到代理监听端的 TLS 是与网站 HTTPS 会话分开的连接选择。网站的 HTTPS 隧道不会回溯保护在未加密的客户端到代理连接上发送的 Basic 凭据。私有 LAN 是一个位置，不是加密属性。
让机制保持具体
抢先式 Basic 不是 Digest、NTLM 或 Negotiate 的通用捷径。这些机制各有自己的交互要求。发现受支持方案的客户端可以正当地执行额外事务。
使用所选库的代理认证接口，然后检查实际生效的方案和范围。目标预认证的设置可能并不控制代理握手。已有的已认证连接也可能掩盖新连接是否会执行挑战。
比较整个操作：交互次数、完成时间、所需的传输保护，以及代理变化时的行为。日志更干净只在应用仍然向预期中间层认证、并在该安排无法建立时停止的前提下才有用。