Cloudflare Browser Run 限流怎麼看？Free／Paid 與 Quick Actions

先分清 Browser Sessions 與 Quick Actions#

例如用 Worker binding 呼叫 .quickAction()，排查時要看 Quick Actions requests per second；如果是持續開啟多個 session，才看 concurrent browsers 和 new browser instances per second。兩者都在 Browser Run 產品裡，不代表共用同一個配額。

目前 Free 與 Paid 的限制#

Workers Free 的 /crawl 還有每日 5 個 crawl job、每次最多 100 頁的限制。Workers Paid 的上表數字是預設值，Cloudflare 文件說明需要更高並行數時可以申請提高帳號限制；這不等於應該先把所有工作都開到最大。

本機 wrangler dev 為什麼會出現 RPC 錯誤#

如果你的文章擷取流程是從 Worker binding 使用 Quick Actions，本機開發還有一個容易和限流混淆的條件：.quickAction() 目前不支援一般 local mode，必須使用 remote mode。設定可以像這樣：

1
{
2
  "$schema": "./node_modules/wrangler/config-schema.json",
3
  "compatibility_date": "2026-03-24",
4
  "browser": {
5
    "binding": "BROWSER",
6
    "remote": true
7
  }
8
}

沒有 remote mode 時，收到 The RPC receiver does not implement the method "quickAction"，這是本機執行模式的邊界，不是 Paid 方案的 rate limit。若要先確認 Worker 的 binding 和遠端資源，可以參考 Workers Local Explorer 的檢查方式；兩者分別處理 local inspection 與 Browser Run 請求。

撞到限制時的排查順序#

1. 先記錄呼叫的是 Browser Session 還是 Quick Action，以及實際 endpoint。
2. 確認帳號目前是 Workers Free 或 Paid，不要只看本機 wrangler 設定。
3. 對 Browser Sessions 計算同時存活的 browser，檢查是否每個任務都重新建立 instance；能共用 browser 或 tabs 時，先評估重用。
4. 對 Quick Actions 計算每秒請求，將批次工作排隊或加入退避，不要用開更多 session 來繞過另一套速率限制。
5. 把 browser time、endpoint、回應時間和失敗時間留下來，再對照 dashboard 的 aggregate metrics。

Cloudflare 的建議也包含重用 sessions、tabs 或 shared browsers。這些是降低啟動成本與並行壓力的工作流調整，不會改變帳號本身的限制；需要更高容量時，再按產品限制頁的申請流程處理。

結論：先按產品類型對表，再調整並行策略#

Browser Run 的限流排錯關鍵不是背一個「200」或「30」，而是先知道請求落在 Browser Sessions 還是 Quick Actions，再確認 plan、生命週期和 endpoint。8 月 20 日的 Paid 預設值確實提高了，但 request rate、browser concurrency、本機 remote mode 和計費仍是不同問題。

常見問題#