Selenium 4.49 更新 BiDi 与 Grid：代理浏览器集群上线前验证指南

Selenium 项目于 2026 年 9 月 9 日发布 Selenium 4.49，覆盖 JavaScript、Ruby、Python、.NET、Java 和 Grid。与代理浏览器自动化直接相关的变化包括：.NET 修复 BiDi 数据对象中不匹配的代理 JSON 属性名；Python 开始为 BiDi 线路错误抛出类型化 WebDriver 异常，并在 Grid 服务端运行 BiDi 测试；Grid 修复文件名包含空格时下载返回 500 的问题；Docker Selenium 将 Kubernetes 存活探针改为 TCP socket，并使用包含进行中会话的扩缩容策略。

发行说明没有宣称代理速度普遍提升。但这些变化触及配置序列化、错误分类、节点健康与会话调度，代理集群不应一次性全量升级，而应先做可回滚的对照验证。

为什么必须回归测试 BiDi 代理字段

WebDriver BiDi 在客户端与浏览器之间传输结构化命令和事件。字段名不一致会让不同语言绑定对同一协议字段采用不同序列化方式。此次发行说明明确提到 .NET 的代理属性名修复。

如果 .NET 测试通过 capabilities 创建代理会话，不要只看“会话创建成功”。浏览器可能仍走直连、错误的代理模式或不完整的认证。应记录经过脱敏的会话清单：绑定和版本、浏览器版本、Grid 节点别名、请求的代理模式、路由别名、请求市场、观察市场、地址族、是否启用 BiDi 以及创建时间。禁止写入代理密码、令牌和原始 Cookie。

建立直连与代理对照矩阵

使用自己控制或明确获准测试的固定页面，在旧版和候选版本上执行完全相同的流程。矩阵至少包含：经典 WebDriver 直连对照、经典 WebDriver 代理路径、BiDi 直连、BiDi 代理路径，以及 Grid 远程代理会话。

直连用于发现与代理无关的浏览器或应用回归；代理路径验证认证、路由和页面正确性；BiDi 路径隔离协议事件与错误变化；Grid 路径验证节点选择、容量及产物处理。浏览器版本、视口、语言、时区、测试页面、超时、重试和网络条件必须保持一致，每次只改变一个变量。

从浏览器会话内部证明路由

不要只在启动 Selenium 的主机上查询出口。Grid 节点和浏览器可能位于另一台主机或容器。每个浏览器会话都应访问一个低流量、已授权的检测端点，由端点返回观察到的来源地区与本次随机挑战值。

保存挑战值是否匹配、观察市场、地址族、响应摘要和时间，然后再打开第二个确定性页面验证语义标记。这样可以区分“浏览器确实使用了目标路由”和“浏览器外部的预检请求使用了目标路由”。

轮换代理需明确是否允许每次请求改变出口；粘性会话则验证路由在约定窗口内稳定，并与其他独立会话隔离。可结合住宅代理会话粘性测试进一步检查。

验证 BiDi 事件与类型化失败

Python 对 BiDi 线路错误采用类型化异常后，既有异常处理可能改变。至少准备一个成功用例，以及无效命令或参数、导航超时、浏览上下文关闭、代理认证被拒、代理网关不可达、隧道建立后目标连接失败等受控失败。

应用必须保留原始失败阶段，不能把所有错误折叠为“可重试网络错误”。认证、配置和策略错误通常应快速停止；临时传输错误才可能进入有上限的重试。

事件驱动采集还要确认导航、网络与日志事件始终属于正确会话和浏览上下文。重复、缺失或延迟事件不能生成重复业务记录。

用真实文件名测试 Grid 下载

Selenium 4.49 修复 Grid 对含空格文件名的 500 错误，同时 Java 移除已弃用的文件下载端点。如果广告验证或市场研究流程下载报告、截图和导出文件，应覆盖空格、Unicode、长扩展名和重复文件名。

不能只检查状态码，还要验证文件属于正确会话、名称规范化符合预期、字节数与摘要匹配固定样本、临时文件按策略删除、一个会话不能取得另一个会话的产物，并确认客户端没有继续调用已移除的 Java 旧端点。金丝雀测试不要使用真实客户导出数据。

重新区分存活、就绪与可用

Docker Selenium 把存活探针从 HTTP 就绪路径改为 TCP socket，会改变 Kubernetes 对“存活”的判断。端口监听只能说明进程接受连接，不能证明它能创建浏览器会话、访问代理网关或完成页面任务。

• 存活探针决定是否重启进程；
• 就绪探针决定节点是否接收新会话；
• 合成可用性检查验证浏览器能否完成有业务意义的直连或代理任务。

包含进行中会话的新扩缩容逻辑也需观察。缩容期间要确认活动会话不会被遗弃，代理凭据不会重分配给其他租户，下载在节点终止前完成。记录排队会话、活动会话、创建延迟、节点排空时长和强制终止数量。

守住三种身份边界

代理浏览器集群同时存在客户端身份、Grid 会话身份和代理会话身份。工作流全程必须保持三者映射。连接池或重试不能把 Cookie、授权请求头、代理凭据或粘性标识转移到另一租户的会话。

可并行运行两个合成租户，使用不同路由别名和金丝雀标记，确认各自只能看到本会话的事件与产物。这是正确性和隐私验证，不是压力测试。再使用代理请求头完整性测试检查浏览器与代理路径是否意外增加或丢失敏感请求头。

设定发布门槛

候选版本只有在目标路由和市场、会话创建与关闭、BiDi 事件完整性、类型化异常、代理认证失败分类、下载归属与摘要、节点就绪及排空、有效结果率、P95 耗时和每次有效结果重试数均达到对照标准时才可推进。同时必须确认不存在跨会话凭据、Cookie、事件或产物。

先投放到少量工作节点和低风险路由类型，正确性门槛失败时自动暂停。不得通过增加重试或不断轮换出口来掩盖回归。

发布检查清单

• [ ] 新旧 Selenium 使用同一浏览器与固定测试页面。
• [ ] 已比较直连、代理、经典 WebDriver 与 BiDi。
• [ ] 路由从浏览器会话内部验证。
• [ ] .NET 代理 capabilities 与实际会话一致。
• [ ] Python 类型化 BiDi 错误进入正确的重试策略。
• [ ] 事件始终属于正确上下文与业务记录。
• [ ] 空格和 Unicode 文件名通过归属与摘要校验。
• [ ] 客户端不再调用已弃用的 Java 下载接口。
• [ ] 存活、就绪与有效工作流探针相互独立。
• [ ] 活动会话在缩容时安全排空。
• [ ] 合成租户之间不存在凭据、事件或产物串线。
• [ ] 日志和截图不含机密及个人数据。
• [ ] 回滚已经演练且可快速完成。

常见问题

Selenium 4.49 会提高代理速度吗？

官方公告没有这一结论。相关变化集中在协议字段、错误、Grid 下载、构建基础设施和容器运行，应由自己的有效结果延迟测试判断。

会话创建成功能证明代理生效吗？

不能。必须从浏览器内部验证路由和市场，再验证页面语义；会话可能在非预期网络路径上正常启动。

所有 BiDi 错误都应该重试吗？

不应该。保留错误类型和失败阶段。无效配置、认证和策略问题通常不能靠重试解决。

TCP 存活探针能替代端到端检查吗？

不能。它只回答进程层面的窄问题，还需要独立的就绪检查与低流量合成浏览器任务。

可以在公开网站上运行金丝雀吗？

优先使用受控目标。确需第三方目标时，必须获得授权、保持低频并遵守其条款和速率限制。

合规与安全运行

浏览器自动化和代理只能用于已获授权的账户、系统与目标。遵守访问控制、隐私要求、适用的 robots 指令、平台条款和速率限制。不得通过轮换绕过封锁、规避挑战或掩盖禁止活动。保护代理凭据，并只保留必要证据。

资料说明：Selenium 项目《Selenium 4.49 Released!》，2026 年 9 月 9 日发布、9 月 10 日最后修改；Selenium 项目 4.49 版本发行说明。

扩大金丝雀范围前，继续执行代理响应完整性测试。