Chrome onAuthRequired：发送凭据前先检查 isProxy

浏览器扩展可能遇到来自两个不同位置的认证挑战：承载请求的代理，以及目标网站。二者不应自动获得同一个账号。

Chrome 的 webRequest.onAuthRequired 事件中，有用的区分依据是 isProxy。仅仅为了让提示消失就去掉这项检查的回调，可能会开始把代理凭据交给源站挑战。

与你打算信任的代理匹配

检查 isProxy 只是起点。还应把处理范围限制在预期的代理挑战方和请求上下文内。管理多个端点的扩展应当选择属于该端点的账号，而不是为每个挑战使用同一个全局密码。

不要以为设置代理路由和处理其登录是同一个权限或同一个 API 调用。Chrome 分别记录这两者。请使用当前 webRequest 参考文档了解事件数据和认证权限。Manifest V3 监听器注册示例展示了回调内部的同步注册与账号选择。

检查 manifest 代际

提到实验性 WebRequest API 的示例来自旧版扩展发行版本。当前的权限要求取决于扩展的 manifest 代际和部署模型。特别是，认证处理有其自身受支持的权限路径；过时的阻塞式监听器示例不足以证明 Manifest V3 扩展可以原样运行它。

正确的处理程序还必须避免无限重试同一份被拒绝的凭据。在提供账号之后再次出现挑战，应当视为需要调查的证据，而不是要求永远重放密码。

凭据应留在扩展适当的受保护处理路径中。不要在 PAC 文件中公开它们，也不要硬编码到分发的示例中。目标是范围很窄的代理登录，而不是一条用同一个密钥回答每次认证挑战的浏览器级规则。