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。
