Cloudflare Workers 放寬連線限制：收到回應標頭就釋放名額，不再誤殺正常連線

一句話看懂：Cloudflare Workers 的連線名額改成「收到回應標頭就釋放」，可以同時開更多連線，也不會再因為誤判而取消正常的連線。

先用白話講：連線名額是什麼？

想像你開了一家外送店，只有 6 個「電話線路」可以同時打給供應商訂貨。以前的規則是：電話必須從頭到尾講完（包含聽完對方報完全部的貨單），才算把線路還回來，所以第 7 通電話得排隊。

現在的規則是：只要對方「接起來、開始報貨單」，線路就先還給你，你可以立刻撥下一通。只有「等對方接電話」那段時間才佔用 6 個名額。

發生什麼事

Cloudflare 在 2026 年 4 月 9 日的更新日誌宣布：

• Workers 每次呼叫同時開啟連線的上限仍是 6 條，但計算方式變了
• 以前：從建立連線到整條連線結束（包含讀完回應內容）都佔用名額
• 現在：回應標頭（response headers）一到，就釋放名額，限制只管「還在等標頭」的連線
• 因此 Workers 現在可以同時開著更多連線，只要等標頭的不超過 6 條，就不用排隊

為什麼以前會誤取消？

舊機制為了避免所有連線互相卡死，會監控各連線有沒有資料在流動：如果 6 條看起來都閒置，就取消最久沒動靜的那一條，騰出空間給新請求。

問題是這個判斷不夠準。官方舉的例子是回應有用 Content-Encoding: gzip 時，執行環境內部解壓縮會讓「讀」和「寫」之間出現短暫空檔，連線看起來像停住了，其實 Worker 還在讀。若多條連線剛好同時遇到空檔，就可能誤殺正常的連線，並出現 Response closed due to connection limit 例外。

新做法只在「等標頭」這個執行環境完全掌控的階段計數，這一類誤判就不會發生。

給開發者的技術細節

• 限制值不變：每次呼叫「等標頭」的連線同時最多 6 條
• 影響到的情境：一次對很多後端或 API 發出 fetch 的 Worker，例如彙整多個資料來源
• 官方公告沒有要求改程式碼；這是執行環境端的調整

// 示意：一次呼叫多個後端（程式碼為示意，非官方範例）
const urls = env.BACKENDS.split(',')
const results = await Promise.all(urls.map((u) => fetch(u)))

• 如果專案日誌裡曾出現 Response closed due to connection limit，可以在更新後觀察是否消失

我的看法

用 Workers 做 API 閘道或彙整多個資料來源時，大家很容易下意識把連線數壓低，甚至自己加一層排隊機制，怕撞到那個「6 條」的上限。這次更新讓限制的語意更貼近直覺：只管「還在等」的連線，已經開始回資料的不佔名額。

不過我也會保留一點謹慎：官方公告只說明了限制的計算方式，沒有提供效能數字。如果你的專案有為了這個限制而寫的排隊或重試邏輯，建議先做測試，再決定要不要拿掉，不要看到公告就直接大改。

名詞小辭典

• Cloudflare Workers：在 Cloudflare 全球節點上執行程式的無伺服器服務。
• 回應標頭（Response headers）：伺服器回應時最先送來的一小段資訊，包含狀態碼和內容類型，之後才是內容本體。
• 死鎖（Deadlock）：多個工作互相等對方，結果誰都動不了的狀態。
• gzip：一種常見的壓縮格式，傳輸時縮小檔案，收到後要解壓縮。

資料來源

• Cloudflare Changelog：Relaxed simultaneous connection limiting for Workers