如何為 200 個並行瀏覽器工作階段規劃代理容量
瀏覽器平台提高並行上限，不代表代理池、目標網站和資料管線能安全承載相同規模。系統可能成功啟動 200 個瀏覽器，卻因認證排隊、工作階段混用、目標限流、記憶體壓力和重試放大，最終得到的有效結果反而少於 60 並行。
本指南適用於已獲授權的資料蒐集、市場研究、廣告驗證、在地化檢查與迴歸測試。目標不是追求最高啟動數，而是在目標規則、帳戶限制、隱私要求與成本預算內，找出最高的可持續有效吞吐量。
先建立容量模型
壓測前分別定義五類上限：
- 瀏覽器上限：可同時運行的瀏覽器程序或上下文數量。
- 代理上限：並行工作階段、連線速率、頻寬與可用地區庫存。
- 目標上限：獲授權目標允許的請求頻率與並行度。
- 管線上限：任務佇列、解析器、資料庫、物件儲存與下游介面的處理能力。
- 業務上限：每個有效結果可接受的最高成本與完成時間。
安全運行點由其中最小的限制決定，而不是某個元件宣傳的最大數字。
有效吞吐量 = 啟動工作階段數 × 首次成功率 × 結果驗證通過率 ÷ 總分鐘數首次成功率必須與重試後的最終成功率分開記錄，否則依賴大量重試的脆弱系統也會看起來很健康。
建立具代表性的測試分組
不要只測一個簡單頁面再推斷全部業務。分組至少涵蓋：
- 國家與地區；
- 動態住宅、靜態住宅或資料中心線路；
- 黏性或輪換工作階段；
- 頁面體積與 JavaScript 複雜度；
- 無登入流程與已授權登入流程；
- 單頁檢查與多步驟業務旅程。
每個分組至少完成 30 次有效嘗試後再判斷。測試資料、截圖、Trace 和日誌不得包含密碼、代理憑證或非必要個人資料。
執行階梯式並行測試
依 10、25、50、100、150、200 等階段逐步提高並行。每個階段須持續足夠長時間，涵蓋頁面的正常波動，而非只測第一次突發請求。
每階段記錄：
- 瀏覽器啟動成功率；
- 代理認證成功率；
- 連線與 TLS 耗時；
- 首位元組、DOM 就緒與工作流程完成時間；
- 首次與最終成功率；
- 403、407、429 與 5xx 的分類原因；
- 國家、ASN 或黏性工作階段的異常變化；
- 流量及每個驗證通過結果的成本；
- 排隊、執行與清理時間；
- 記憶體、CPU、檔案描述符與資料庫飽和度。
若有效吞吐量不再上升、p95 完成時間超過服務目標、錯誤率連續兩階段上升，或目標顯示已達允許上限，就停止加壓。
區分瀏覽器工作程序與代理工作階段
一個瀏覽器工作程序不一定等於一個代理工作階段。依業務選擇隔離模型：
- 強隔離旅程：每個瀏覽器上下文使用獨立代理工作階段；
- 多步驟流程：全程使用同一黏性工作階段，保持地區與出口連續；
- 完全無狀態請求：只有在每次請求互相獨立時才使用受控輪換。
不要讓無關使用者或任務共享同一黏性工作階段。復用能降低連線成本，但失控復用可能混合 Cookie、出口身分或歷史限流狀態。
先設定背壓，再設定重試
安全佇列應在系統失穩前延遲或拒絕新任務，至少限制：
- 每秒新啟動瀏覽器數；
- 每地區的活動上下文；
- 每代理閘道的工作階段數；
- 每目標的請求並行；
- 重試並行；
- 單次運行的總流量與總預算。
重試任務應進入更小的獨立佇列，加入隨機抖動與重試預算，且只重試冪等操作。若某階段有 20 個失敗，又立即向已飽和代理池啟動 20 個重試，重試策略便成為負載放大器。
定位第一個瓶頸
| 監控信號 | 可能瓶頸 | 下一步檢查 |
|---|---|---|
| 啟動失敗增加但代理認證穩定 | 瀏覽器平台 | 工作配額、記憶體、啟動速率 |
| 407 明顯增加 | 代理設定 | 憑證範圍、工作階段格式、閘道上限 |
| 所有目標連線時間都增加 | 代理或網路 | 閘道飽和、DNS、TLS、頻寬 |
| 只有一個目標的 429 增加 | 目標策略 | 降低允許速率並增加排隊 |
| 成功率穩定但排隊時間增加 | 資料管線 | 工作者或資料庫容量 |
| 最終成功率穩定但首次成功率下降 | 過度依賴重試 | 線路品質、隱藏成本、重試風暴 |
每次只改一個變數。一次同時更換地區、瀏覽器版本、代理類型與並行級別，只會產生漂亮圖表，卻無法形成可靠結論。
選擇正式環境上限
不要把壓測的崩潰點直接當作正式設定。應在最低已驗證飽和閾值下保留餘量，以因應更重頁面、地區庫存變化與下游延遲。可先將上限設為閾值的 70%–80%，並在錯誤或延遲預算被突破時自動降載。
最終決策記錄應包含：
- 各地區、各工作流程的核准並行；
- 代理工作階段與輪換規則；
- 佇列和重試上限；
- p50 與 p95 完成時間；
- 首次成功率目標；
- 每個有效結果的最高成本；
- 自動停止條件；
- 測試日期、版本與負責人。
發布前檢查清單
- 已確認書面授權與目標規則。
- 已驗證代理地區和工作階段持續性。
- 憑證不會進入日誌與截圖。
- 測試樣本涵蓋真實頁面類型。
- 採階梯式加壓而非一次跳到最大值。
- 分開統計首次成功與重試恢復。
- 已設定地區、目標與預算上限。
- 取消或逾時後能完整清理資源。
- 只保留必要且允許的資料。
- 瀏覽器、代理或目標重大變更後重新壓測。
常見問題
200 個並行瀏覽器是否等於 200 條代理連線？
不等於。一個瀏覽器可能建立多條連線，多個上下文也可能復用或輪換代理工作階段，必須分別測量瀏覽器並行與真實連線/工作階段行為。
是否應為每個瀏覽器分配唯一住宅 IP？
只有獲授權流程確實需要此隔離時才這樣做。不必要的唯一出口會提高成本並降低庫存效率。工作階段模型應匹配業務旅程、目標規則與隱私邊界。
應以哪個指標決定並行上限？
使用同時符合延遲、錯誤、合規與成本限制的「每分鐘驗證通過結果數」。啟動工作階段數只是基礎設施指標，不是業務成果。
何時需要重新執行容量測試？
瀏覽器或執行環境大版本變更、代理方案或閘道變更、目標改版、新增地區，或頁面體積與流程複雜度明顯變化時，都應重新測試。
合規說明
只對已獲授權的系統和資料執行自動化。遵守目標條款、適用的 robots 與存取政策、速率限制、隱私義務、地區法規和資料保留要求。不得利用並行或代理輪換繞過存取控制。
繼續閱讀Playwright 代理設定指南、住宅代理工作階段黏性測試和代理 429 處理指南。
內部研究記錄：Cloudflare，Browser Run 並行上限更新，2026 年 8 月 20 日。
