VPN 可以将浏览器的流量传输到代理服务器,但仍然使浏览器无法使用该代理,因为路由和凭证是不同的东西。无头自动化使差距更难看到,因为没有窗口,也没有提示来注意。故障通常表现为挂起或一般的导航错误,第一反应就是归咎于隧道。下面的清单区分了在通过经过身份验证的代理的无头请求成功之前必须满足的四件事。

两次对话,两份凭证

发生了两次对话,并且它们属于不同的一方。浏览器首先连接到代理侦听器,代理侦听器可能会询问其凭据;然后代理建立或允许到目的地的前向连接。VPN 可以承载第一条腿,而不是挑战浏览器的端点,并且它对第二条腿没有什么可说的。

HTTP 407 是客户端必须对代理请求进行身份验证的信号,在 Proxy-Authenticate 中携带,并在 Proxy-Authorization 中预期得到答案。这不是目标网站的登录,混合两者是这里最常见的混乱来源。

因此,这四项检查是:浏览器实际选择的代理、谁回答 407、浏览器进程位于哪个网络以及如何在无人操作的情况下传递凭证。每个故障都可能独立发生故障,并且每个故障从外部看起来都很相似。按顺序进行操作,因为较晚的检查无法弥补较早的检查。从未选择的代理无法进行身份验证,并且仅存在于您的笔记本电脑上的凭证无法到达容器。

检查1:实际选择了哪个代理

从选择开始,因为忽略代理设置的浏览器根本无法应对挑战。在 Chrome 中,标志是 --proxy-server=proxy.example:3128 ,其中 --proxy-bypass-list 表示排除,Selenium 通过其浏览器选项公开相同的内容。PAC 文件是一种不同的机制,具有自己的故障模式。

然后从运行的浏览器环境内部而不是从 shell 进行确认。具有相同代理的独立探针是 curl -x http://proxy.example:3128 -v https://example.com ,其详细输出显示 CONNECT 是否成功、Proxy-Authenticate 返回的内容以及是否返回 407。如果curl 得到407 并且浏览器挂起,则问题出在凭证路径而不是网络上。如果curl成功而浏览器没有成功,则浏览器没有使用您认为的代理。

检查 2:谁回答了 407

407 有一个所有者,它的命名决定了修复的位置。如果挑战来自公司代理,则修复方法是浏览器可以在无人值守的情况下提供的凭据。如果它来自第一个代理转发到的上游代理,则该凭证属于第二跳,并且第一个代理可能会以不变的方式中继质询。读取 Proxy-Authenticate 标头中的身份验证范围和主机,因为它们命名了询问的框。

在您记录的任何内容中都保留这种区别。代理质询、拒绝继续连接、网站登录和 VPN 传输超时是四种不同的故障,涉及四个不同的所有者,而一条通用错误消息会破坏您所需的信息。

检查3:凭证路径

凭证本身是大多数无人值守设置失败的地方。Selenium 可以设置代理主机和端口,但 HTTP 代理身份验证不是该配置的可移植部分,并且代理 URL 中的凭据不是可以跨浏览器和驱动程序版本依赖的机制。支持的选项是您实际堆栈文档的选项:回答挑战的浏览器扩展、添加标头并且只能从作业访问的本地转发代理,或者通过其他方式验证工作负载的代理。仔细选择一个,并根据您将运行的确切浏览器、驱动程序和 Selenium 版本进行检查。

确保凭证远离泄露的地方。命令行在进程列表中可见,屏幕截图最终出现在测试报告、浏览器跟踪和 HAR 文件捕获标头中,并且提交的测试配置是永久的。使用作业的秘密交付机制及其编辑规则,并将代理帐户的范围限制到其所需的目的地或角色。

如果组织提供允许的直接 VPN 路由而不是强制代理,请明确比较这两种设计。不要悄悄禁用代理或模仿其他客户端的身份验证来绕过策略。

检查4:浏览器进程自己的网络上下文

这是人们跳过的检查。由工作人员、容器或远程 Selenium Grid 节点启动的浏览器使用该环境的网络,因此您的笔记本电脑的 VPN 连接和 shell 的代理变量描述了浏览器可能永远不会触及的路径。

记录失败作业的五个事实:浏览器主机、配置的代理、初始解析器路径、选择的路由和身份验证的所有者。然后从该确切上下文发出一个无害的授权请求,并保留正常的目标 TLS 验证和应用程序授权。成功启动的无头浏览器既不能证明代理准入,也不能证明 VPN 覆盖范围,而空白页面的屏幕截图也不能证明任何事情。通过整个链返回200的请求是唯一重要的证据。

完成的工作流程具有三个值得作为一组检查的属性。存在从浏览器主机到代理的受支持路由、指定代理和目的地的显式中介策略以及不依赖于操作员回答不可见提示的凭证生命周期。如果这三者中的任何一个依赖于一个人,那么无论退出代码显示什么,该工作都还没有无人值守。在下一个人继承管道之前写下五个事实。

相关文章