Firefox 155 稳定并行 WebDriver BiDi 与 DevTools 代理调试
Firefox 155 于 2026 年 9 月 1 日发布。Mozilla 的开发者说明指出，moz:debugging 模块不再依赖 DevTools 使用的同一套嵌套事件循环 API，从而避免 WebDriver BiDi 与 DevTools 并行运行时发生冲突。
对使用代理的浏览器自动化团队而言，这不只是内部整理。测试程序可能通过 WebDriver BiDi 控制导航，同时由工程师打开 DevTools 检查请求、耗时和控制台证据。如果两个调试入口相互干扰，失败任务可能被误判成代理出口故障。
公开来源说明：Mozilla MDN，《Firefox 155 release notes for developers》，2026 年 9 月 1 日发布。
Firefox 155 改变了什么
WebDriver BiDi 提供双向浏览器自动化：客户端既能发送命令，也能在会话中订阅浏览器事件。DevTools 则用于交互式查看网络、控制台、存储和页面行为。故障调查经常需要两者同时工作。
Firefox 155 调整了 Mozilla 专用调试模块，使其不再与 DevTools 争用同一嵌套事件循环机制。Mozilla 明确说明，此变化可防止 WebDriver BiDi 与 DevTools 并行使用时的冲突。
这并不保证所有自动化框架、扩展或代理库天然兼容。它消除的是一个浏览器侧冲突来源。团队仍应针对实际 Firefox 版本、驱动、代理协议和业务负载执行验收。
为什么代理自动化团队需要关注
一项代理测试至少包含四层：
- 自动化控制器；
- 浏览器及其调试接口；
- 代理连接、认证与路由；
- 目标站点及预期内容。
当控制器与调试器争用浏览器执行资源时，可能出现命令卡住、事件缺失、网络记录延迟、检查面板无响应或虚假超时。此时立即轮换代理会破坏原始证据，也可能把浏览器控制故障错误归因到出口 IP。
Firefox 155 为同一任务的双通道观察提供了更可靠的基础，但故障归因仍需由测试设计完成。
设计控制与观察双通道
即使针对同一浏览器会话，也应把控制与观察分开。
| 通道 | 职责 | 应保留证据 |
|---|---|---|
| WebDriver BiDi | 导航、交互和事件订阅 | 命令 ID、事件序列、导航结果 |
| DevTools | 交互检查与人工诊断 | 请求耗时、发起方、控制台证据 |
| 代理遥测 | 网关、会话与路由状态 | 脱敏路由标签、连接耗时、轮换原因 |
| 业务验证器 | 判断业务结果 | 预期内容检查、有效记录数 |
不要让 DevTools 操作悄悄改变实验变量。编辑请求、清除存储或禁用缓存都会使受控代理对比失效。
执行有边界的 Firefox 155 验收
只使用自有或已明确获准测试的目标和账号。
1. 固定测试矩阵
记录 Firefox 版本、自动化库、WebDriver BiDi 客户端、代理协议、网关标签、目标地区、会话模式和目标类型。凭据保存在密钥管理系统中，报告只写无敏感信息的配置标签。
2. 建立三条基线
以完全相同的场景分别运行：
- 只运行 WebDriver BiDi，不打开 DevTools；
- 只用 DevTools 检查，不连接自动化客户端；
- WebDriver BiDi 与 DevTools 同时运行。
保持请求数量、超时、代理路由和预期内容规则不变。组合场景与任一基线的差异都可能暴露协调风险。
3. 显式关联事件
为每个逻辑浏览器旅程生成一个操作 ID，并把它写入自动化日志、代理遥测与验证结果。另行记录单调时钟，避免事件顺序完全依赖不同进程的墙上时间。
4. 每次只改变一个变量
组合场景失败后，先在不更换代理的情况下复现一次。随后只改变一个获准因素，例如关闭 DevTools、更换浏览器构建或创建新代理会话。不要同时修改代理、浏览器配置、请求头和超时。
5. 归类后再轮换
使用独立故障标签：自动化命令超时、BiDi 事件缺失或延迟、DevTools 响应问题、代理连接或认证失败、目标响应或策略信号、内容验证失败。只有明确可由路由恢复的瞬时故障才触发代理轮换。
用指标衡量升级结果
把 Firefox 155 与此前批准版本进行对比：
- 每 100 次尝试完成的浏览器旅程数；
- 自动化命令超时率；
- 事件缺失率；
- 打开与关闭 DevTools 的完成率差值；
- 代理连接成功率及连接耗时 p95；
- 首次成功率与有限重试成功率；
- 每个旅程的意外代理轮换次数；
- 旅程耗时中位数和 p95；
- 每个有效结果的成本。
只有业务结果保持稳定，且没有新增无法解释的路由抖动或重试流量时，浏览器升级才算通过。
并行会话卡住时的排查顺序
- 停止新增重试，保留原始证据；
- 记录最后完成的 BiDi 命令与最后接收的事件；
- 检查 DevTools 是否仍能响应；
- 检查代理隧道是否仍处于连接状态；
- 对照目标最后响应与业务验证结果；
- 关闭 DevTools 后以相同条件重跑；
- 打开 DevTools、断开 BiDi 客户端后重跑；
- 排除浏览器控制问题后再轮换代理。
路由归因可结合代理绕过审计，压力问题可结合代理并发爬坡测试，逐行证据可参考Firefox 155 NDJSON 代理质检流程。
上生产前的发布门槛
- BiDi 与 DevTools 组合场景可重复完成；
- 事件数量与命令数、完成旅程数可核对；
- 打开 DevTools 不会显著降低有效成功率；
- 代理连接与地区定向仍在既有阈值内；
- 没有新增隐藏重试或轮换层；
- 失败可明确归因到浏览器、代理、目标或验证器；
- 诊断输出不包含凭据、Cookie 或个人数据；
- 已验证回退到上一批准版本的流程。
使用“通过、有条件通过、失败、不确定”四种结论。浏览器没有崩溃不等于任务成功。
运维检查清单
- 固定 Firefox 155 与所有自动化依赖版本。
- 分别测试 BiDi、DevTools 和组合场景。
- 在控制、代理与验证日志之间保持同一个操作 ID。
- 记录单调事件时间和命令序号。
- 不把代理凭据与授权头写入诊断材料。
- 把浏览器控制失败与路由失败分开。
- 只有符合规则的瞬时错误才允许代理轮换。
- 分开报告首次成功与最终成功。
- 衡量打开 DevTools 带来的性能影响。
- 保留已验证的回退路径。
常见问题
Firefox 155 是否可以替代代理监控？
不可以。它只避免一种调试接口冲突。代理认证、可达性、位置准确性、会话连续性和目标响应仍需独立监控。
是否应在所有生产任务中一直打开 DevTools？
通常不需要。DevTools 更适合受控诊断或抽样质检，生产遥测应保持自动化并遵守隐私边界。
BiDi 命令卡住后是否应该直接换代理？
不应该。问题可能来自浏览器控制、页面执行、调试器、代理或目标站点。先定位层级，再决定是否轮换。
最安全的升级方式是什么？
让旧版与新版浏览器运行同一获准矩阵，使用预先固定的验收阈值，比较首次尝试结果，并保留经过测试的回退路径。
合规说明
浏览器自动化与代理服务仅应用于合法、获准的测试和数据任务。遵守目标条款、隐私要求、服务商合同与速率限制。不得利用调试权限提取秘密、规避访问控制或掩盖滥用行为。所有诊断材料都应移除凭据、Cookie、令牌和不必要的完整 URL。
