Playwright 報告：一個無回應分頁可能拖住 CDP 連線
Playwright 在 2026 年 9 月 15 日收到一則問題報告：當瀏覽器中已存在一個不再回應頁面層級 Chrome DevTools Protocol 指令的頁面目標時，connectOverCDP 可能無法完成。報告所附重現中，WebSocket 已連線，瀏覽器層級指令仍有回應，但整體連線一直等待到明確逾時。
該報告剛提交，複核時仍為 open，沒有維護者留言或確認修正。根因分析與規避方式都來自報告者，尚不是專案結論。重現不需要代理，也不能證明 Playwright、Chromium 或遠端瀏覽器服務普遍故障。
內部來源說明：Microsoft Playwright 問題 42730，「connectOverCDP never completes when a pre-existing page target stops answering CDP commands」，提交於 2026 年 9 月 15 日；複核時 open、留言數為零。
重現顯示了什麼
報告環境使用 playwright-core 1.63.0-alpha、Playwright CLI 0.1.18/0.1.19，以及 openSUSE Tumbleweed 上的 Microsoft Edge 148。作者透過遠端偵錯啟動瀏覽器，暫停一個算繪程序，再以 15 秒逾時呼叫 connectOverCDP。
依照報告，呼叫記錄到達「WebSocket connected」，卻不回傳瀏覽器物件；恢復算繪程序後，同一連線約 31 毫秒完成。在三個分頁對照中，瀏覽器層級目標列舉和另外兩個正常分頁繼續運作，只有暫停分頁的頁面層級指令沒有回應。
這項區分很重要：傳輸連線可以健康，而某個既有目標的初始化仍被阻塞。
報告中的等待邊界
問題作者把等待定位到 Playwright 自動連接現有目標，並等待所有對應頁面完成初始化或回傳錯誤。報告指出，暫停目標的多個頁面層級 CDP 指令已送出卻沒有回覆，因此初始化 Promise 無法結束。
這個解釋有重現證據支持，但維護者尚未確認。營運團隊應保存指令與回應時間軸，不能把所有連線停滯都直接歸類為這個問題。
報告也把此情況與首次導覽提交、預先算繪啟用等其他等待點區分開來；症狀相似，不代表機制相同。
代理瀏覽器工作池為何需要關注
團隊經常透過代理、閘道或託管偵錯端點連接遠端瀏覽器。若 WebSocket 已連線後仍停滯，統一標記為「代理逾時」會把調查帶向錯誤方向。
應拆分以下層級：
- 代理 DNS 與 TCP；
- 代理端 TLS 與驗證；
- 通道建立；
- CDP WebSocket 升級；
- 瀏覽器層級 CDP 回應；
- 目標列舉與自動連接；
- 每個既有頁面目標的初始化；
- 工作負載導覽與資料收集。
某層成功不能證明下一層成功；同樣，一個頁面目標無回應也不能證明代理路徑或整個瀏覽器程序不可用。
建立目標層級診斷矩陣
只檢查明確獲准操作的瀏覽器和頁面。給每次連線設定有限逾時，並記錄 WebSocket 升級、第一個瀏覽器層級回應、目標列舉、頁面工作階段連接與初始化完成的時間戳記。
每個目標只記錄非敏感識別、類型、URL 類別、建立時長、生命週期狀態，以及最小獲准指令是否收到回覆。不要記錄完整私密 URL、Cookie、驗證標頭、頁面內容或客戶識別。
比較四個受控案例：
- 只有空白頁的新瀏覽器；
- 包含多個正常頁面的同一瀏覽器；
- 在隔離實驗環境中主動暫停的測試算繪程序；
- 安全移除或重啟可疑目標後的近正式環境瀏覽器。
預期證據應是每個目標的指令時間軸，而不是單一總連線時間。
存活判定不能止於 WebSocket
遠端瀏覽器工作節點不能因為偵錯通訊端接受連線就進入 ready。至少還應要求：
- 瀏覽器層級指令成功；
- 在預算內完成目標列舉；
- 每個必要頁面完成初始化或明確隔離；
- 輕量頁面層級指令得到回應；
- 透過獲准代理路徑完成受控導覽；
- 觀察到的出口與工作階段符合分配。
Playwright 無頭瀏覽器停滯存活報告提供更完整的主動探針框架。傳輸重複使用問題可對照Playwright keep-alive ECONNRESET 報告。
隔離異常目標，但不要掩蓋它
若自有自動化工作節點在連線階段反覆逾時，應停止分配新工作並隔離節點。保留去識別化目標清單與有限追蹤，再透過核准的編排路徑重啟受影響頁面或瀏覽器。
未經明確授權，不得關閉、重新載入或修改使用者控制的瀏覽器分頁。會破壞未儲存工作的強制恢復不能作為健康檢查。
問題作者描述了一種本機規避：讓初始化與逾時競爭，並刪除部分目標記錄，但明確說明這不是建議修正。跳過無回應頁面可以恢復容量，也可能掩蓋真實故障。必須記錄被跳過目標、原因與恢復動作，在目標工作負載通過前不得把節點視為完全健康。
恢復節點擴充前執行代理併發飽和測試，避免重複連線進一步放大不健康瀏覽器池的壓力。
營運檢查清單
- 設定明確連線逾時，不允許佇列無限等待。
- 區分 WebSocket、瀏覽器層級和頁面層級 ready。
- 在去識別化追蹤中配對已送出與已回答 CDP 指令編號。
- 記錄第一個超過回應預算的目標。
- 重試前先隔離失敗工作節點。
- 在相同網路路徑保留乾淨瀏覽器對照。
- 恢復後確認代理路由仍正確。
- 檢查追蹤中是否包含 URL、Token、Cookie 與客戶資料。
- 先測試受支援穩定版本，再把 alpha 報告擴大為整個工作池回歸。
- 持續關注上游維護者確認與受支援修正。
常見問題
這份報告是否證明代理導致連線逾時？
不能。重現不需要代理。它說明網路連線成功不代表每個既有頁面目標都能完成初始化。
「WebSocket connected」足以讓節點進入 ready 嗎？
不足。它只確認一個傳輸邊界，仍需瀏覽器層級和頁面層級探針。
是否應自動跳過所有慢分頁？
不應。跳過可能丟失必要狀態或掩蓋故障。只能對自有自動化目標使用有邊界、可記錄的隔離政策，保留證據，並在之後驗證目標工作負載。
合規說明
只檢查和控制自有或明確獲准操作的瀏覽器、頁面、代理帳戶與目標。最小化診斷資料，保護憑證與瀏覽狀態，遵守目標條款與速率限制，不得為了自動恢復而干擾使用者分頁或未儲存工作。
