不靠猜测修复代理错误 407

起点

407 指向的是代理认证层。先从这里入手，再考虑修改目标站点请求或添加重试。

弄清是谁在索要凭据

HTTP 407 表示代理要求认证。响应中包含 Proxy-Authenticate 质询。客户端通过 Proxy-Authorization 提供代理凭据。目标站点的认证是另一回事：把代理密码放进目标站点的 Authorization 请求头是错误的修复方式。

对于 HTTPS 目标站点，拒绝可能发生在 CONNECT 阶段，早于你的应用收到任何目标站点响应。有些客户端会报告代理或隧道异常，而不是暴露一个状态码为 407 的普通 Response。

一次只检查一个变量

按下面的顺序进行，才能得到有用的复现，而不是一连串互不相关的改动。

• 网关：从账户当前的设置说明中原样复制 scheme、主机名和端口。
• 方式：确认该端点期望的是用户名/密码、允许的来源 IP，还是文档中列出的其他认证机制。
• 凭据范围：确认用户名属于该产品或子用户，而不仅仅是控制台的登录账号。
• 编码：把凭据嵌入 URL 时要做百分号编码；客户端支持时优先使用独立的凭据字段。
• 客户端：检查继承的代理设置，并确认实际选中的确实是预期的网关。

用 curl 与出错的应用做对比

使用相同的网关、目标站点和凭据，运行相关指南中那条有界的 curl 命令。如果它能成功，就把精力集中在应用是如何映射这些设置的。例如在 Playwright 中，代理凭据应放在 proxy.username 和 proxy.password 中，而不是 httpCredentials。

如果两个客户端都失败，去掉服务商特有的可选国家或会话修饰参数，测试文档中最简单的凭据格式。向服务商确认账户访问权限和该端点的认证说明。不要假设每个服务商都用 407 表示同样的计费或产品访问状况。

发送可复现、已脱敏的报告

保留客户端版本、UTC 时间戳、网关主机和端口、目标站点主机名、认证方式以及状态码或异常类。说明最小化的 curl 复现是否同样失败。这些细节能让支持团队在不接收你密码的情况下找到那次尝试。

从日志中移除令牌、带凭据的 URL、Cookie 和授权请求头。诊断持续出现的 407 时停止自动重试。修正之后，先重新运行一个请求，再运行最小的应用场景，然后才恢复正常并发。

上线前检查

• 把代理认证与网站认证分开识别。
• 在第二个客户端中用相同设置复现。
• 分享脱敏后的诊断信息，而不是凭据或原始跟踪记录。