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 版本發布說明。

擴大金絲雀範圍前，繼續執行代理回應完整性測試。