代理返回 407 Proxy Authentication Required 时，不能只反复输入用户名密码。响应中的 Proxy-Authenticate 会提示代理接受的认证方案，客户端必须支持并按对应流程发送 Proxy-Authorization。
Basic、Digest、NTLM和Negotiate并不是“密码格式不同”，它们的握手、连接状态和部署环境都不同。
一、常见认证方式对比
| 方式 | 基本特点 | 主要注意 |
|---|---|---|
| Basic | 对凭据做编码后发送 | 编码不是加密，需要受保护传输 |
| Digest | 基于质询和摘要计算 | 兼容与算法支持因实现而异 |
| NTLM | 多阶段、常与连接状态相关 | 企业Windows环境常见，代理池需谨慎 |
| Negotiate | 可能使用Kerberos等机制 | 依赖域、票据、SPN和时间 |
二、Basic为什么必须保护传输
Basic凭据只是Base64编码，能够被还原。若客户端到代理之间没有受保护的通道，凭据可能暴露给链路上的观察者。是否支持TLS代理连接取决于服务和客户端，不能因为目标网站是HTTPS就自动认为代理认证段已加密。
三、Digest是否一定更安全
Digest避免直接发送明文密码，但安全性取决于算法、nonce处理、实现和传输环境，兼容性也不如Basic普遍。不要自行宣布某种实现“绝对安全”，应按组织标准和客户端支持选型。
四、NTLM为何与连接复用相关
NTLM认证通常涉及多步握手并可能绑定连接。中间连接池、HTTP/2多路复用或负载均衡若处理不当，会出现间歇认证失败。客户端和代理需明确支持该组合。
只把NTLM用户名密码填进Basic字段不会成功。
五、Negotiate常见故障点
- 客户端未加入正确域或无法取得票据；
- 代理SPN不正确；
- DNS名称与访问名称不一致；
- 系统时间偏差导致票据无效；
- 客户端回退到NTLM但代理策略不允许；
- 容器或服务账户没有对应身份上下文。
六、如何查看代理要求的认证
使用客户端调试日志或抓取自己有权查看的握手头，确认407响应中的 Proxy-Authenticate。注意日志可能包含域名、用户名和挑战信息，分享前脱敏。
不要把 Proxy-Authorization 完整值发到工单。
七、为什么浏览器能用，脚本不能用
浏览器可能集成系统凭据、域认证或协商机制，而脚本库只支持Basic或需要额外插件。检查客户端文档，不要假定“都支持HTTP代理”就支持相同认证。
Python、Node和Java客户端还可能使用不同连接池与信任库。
八、407排查顺序
- 确认响应确实来自代理，而非目标服务器；
- 读取Proxy-Authenticate方案；
- 确认客户端支持并已启用该方式；
- 核对用户名格式、域、密码和账号状态；
- 检查TLS、DNS、时间和连接复用；
- 确认来源IP白名单是否与账号认证冲突；
- 使用专用测试账号做最小复现。
通用错误码说明见代理407、502、503、504排查。
九、凭据管理
不要将域密码用于普通外部代理。企业代理应采用最小权限、专用服务身份、短期票据或受控凭据。明文密码不能进入URL、Shell历史、CI日志和配置仓库。
十、认证轮换怎么避免中断
Basic类账号可在平台支持时使用双凭据过渡；NTLM/Negotiate还需考虑服务身份、票据和连接寿命。切换后旧连接可能继续有效，新连接才使用新身份。
通用流程见代理凭据无中断轮换。
十一、为什么不能高频重试407
407通常是确定性配置或身份问题，高频重试不会自愈，反而可能锁定账号、放大日志和触发安全告警。达到少量失败后停止并人工核对。
十二、选型原则
公网或简单服务不应为了便利复用企业域凭据；企业集成则应优先组织批准的认证和设备管理。最终选择取决于威胁模型、客户端支持、TLS保护、审计与撤权能力，而不是哪个名字看起来更高级。
