HTTP 407 与 401：到底是哪一层登录失败
分清代理认证和网站认证，查看正确的响应头，避免把凭据发送给错误的一方。
407 要求你向代理认证，401 要求你向目标资源认证。同一次请求可能遇到两者，因此提供密码之前，先弄清是谁在要求登录。
对照状态码与认证质询头
| 响应 | 认证质询头 | 凭据头 | 相关方 |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | 中间代理 |
| 401 Unauthorized | WWW-Authenticate | Authorization | 源站资源的认证流程 |
状态码是重要的第一条线索，但还要看完整交互。页面正文里写着 407，不等于真正的 HTTP 407 响应。同样，自定义网页登录页即便返回 200，也仍可能要求用户在应用层认证。
为什么 HTTPS 请求还没到网站就可能遇到 407
普通 HTTP 代理承载 HTTPS 请求时，客户端通常先要求代理建立CONNECT 隧道。代理可以对这条 CONNECT 请求发起认证质询。如果认证没有完成，通过隧道与目标建立的 TLS 会话也尚未建立，因此更换网站 API 令牌不太可能修复这一阶段的问题。
用详细输出查看认证质询出现在哪一步：
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/把本地监听地址换成自己的代理，查看日志中的第一次认证质询。CONNECT 期间的 407 发生在目标 TLS 之前；隧道成功建立之后，还可能出现后续的 401。
通过代理接口提供代理凭据
如果端点和账号由你信任的管理员提供，curl 可以协商代理认证方式，并在未提供密码时提示输入：
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/把示例端点和用户名换成获准使用的服务信息。只指定用户名，可以避免直接把密码写进上面的命令。不同 curl 构建和代理支持的认证方式可能不同；协商失败时，检查实际质询和该构建的能力。
代理认证选项与 curl 的源站用户认证选项相互独立。不要用源站 Authorization 头代替代理认证质询所需的响应，也不要手动把代理凭据头转发到无关请求，或保存在应用全局复用的请求头中。
如果代理一直返回 407
- 确认使用的是预期的代理主机和端口。
- 检查代理声明支持的认证方式，不要直接假定是 Basic。
- 确认账号状态，以及服务是否要求特定的用户名格式。
- 如果凭据嵌在 URL 中，检查特殊字符如何传递。
- 确定与浏览器集成的企业认证配置是否需要运行时或平台支持。
- 客户端证据不足时，请管理员提供脱敏的请求标识或服务端日志条目。
即便登录成功，403 或被拒绝的 CONNECT 也可能来自访问策略。再试更多密码，并不会让你获得访问被禁目标的权限。
目标网站的 HTTPS 无法保护每一次代理凭据交换
代理认证可能发生在目标 TLS 建立之前。如果到代理本身的连接是明文，而认证方法又会在这条链路上暴露可复用凭据，目标使用 HTTPS 也无法事后保护这次交换。选择适合服务的传输方式与认证安排，不要把私人账号交给未知的公共代理。
分享详细日志之前先检查内容。即使工具会遮蔽常见凭据字段，日志仍可能包含用户名、内部端点名称、Cookie 或其他可识别信息。