制限
| 機能 | Workers Free | Workers Paid (Bundled, Unbound) および Standard |
|---|---|---|
| サブリクエスト | 50/request | 50/request (Bundled), 1000/request (Unbound, Standard) |
| 同時出力 接続/request | 6 | 6 |
| 環境変数 | 64/Worker | 128/Worker |
| 環境変数 サイズ | 5 KB | 5 KB |
| Workerサイズ | 1 MB | 10 MB |
| Worker起動時間 | 400 ms | 400 ms |
| Workerの数1 | 100 | 500 |
| アカウントあたりのCronトリガー の数 | 5 | 250 |
1 制限に達している場合、プロジェクトはWorkers for Platformsに適しているかもしれません。
URLのサイズ制限は16 KBです。
リクエストヘッダーは合計32 KBの制限がありますが、各ヘッダーは16 KBに制限されています。
Cloudflareにはリクエストボディサイズに関するネットワーク全体の制限があります。この制限は、Cloudflareアカウントのプランに関連しており、Workersプランとは別です。POST/PUT/PATCHリクエストのリクエストボディサイズがプランの制限を超えると、リクエストは(413) Request entity too largeエラーで拒否されます。
Cloudflare Enterpriseの顧客は、アカウントチームまたはCloudflareサポートに連絡して、500 MBを超えるリクエストボディ制限を設定できます。
| Cloudflareプラン | 最大ボディサイズ |
|---|---|
| Free | 100 MB |
| Pro | 100 MB |
| Business | 200 MB |
| Enterprise | 500 MB (デフォルト) |
Cloudflareはレスポンス制限を強制しませんが、CloudflareのCDNのキャッシュ制限が適用されます。最大ファイルサイズは、Free、Pro、Businessの顧客で512 MB、Enterpriseの顧客で5 GBです。
| 機能 | Free | Bundled usage model | Unbound および Standard使用モデル |
|---|---|---|---|
| リクエスト | 100,000 リクエスト/日 1000 リクエスト/分 | なし | なし |
| Workerメモリ | 128 MB | 128 MB | 128 MB |
| CPU時間 | 10 ms | 50 ms HTTPリクエスト 50 ms Cron Trigger | 30 s HTTPリクエスト 15分 Cron Trigger |
| 持続時間 | なし | なし | 15分 Cron Trigger 15分 Durable Object Alarm 15分 Queue Consumer |
持続時間は、ウォールクロック時間の測定です — Workerの呼び出しの開始から終了までの合計時間です。Workerの持続時間に対する厳密な制限はありません。リクエストを送信したクライアントが接続されている限り、Workerは処理を続け、サブリクエストを行い、そのリクエストに代わってタイムアウトを設定できます。クライアントが切断されると、そのクライアントリクエストに関連するすべてのタスクはキャンセルされます。event.waitUntil()を使用して、キャンセルをさらに30秒遅らせるか、waitUntil()に渡されたプロミスが完了するまで待機します。
CPU時間は、特定のリクエスト中にCPUが実際に作業を行っている時間のことです。ほとんどのWorkersリクエストは、1ミリ秒未満のCPU時間を消費します。通常の動作をしているWorkersがCPU時間制限を超えることは稀です。
Each isolate has some built-in flexibility to allow for cases where your Worker infrequently runs over the configured limit. If your Worker starts hitting the limit consistently, its execution will be terminated according to the limit configured.
ローカルでDevToolsを使用すると、コードのCPU集約部分を特定するのに役立ちます。詳細については、DevToolsを使用したCPUプロファイリングのドキュメントを参照してください。
各Workerの呼び出し中に使用できるCPU時間のカスタム制限を設定することもできます。そのためには、CloudflareダッシュボードのWorkersセクションに移動し、変更したい特定のWorkerを選択し、「設定」タブをクリックしてCPU時間制限を調整します。
| 機能 | Workers Free | Bundled | Unbound および Standard |
|---|---|---|---|
| 最大オブジェクトサイズ | 512 MB | 512 MB | 512 MB |
| 呼び出し/request | 50 | 50 | 1,000 |
- リクエストごとに合計50の
put(),match(), またはdelete()呼び出しが可能で、fetch()と同じクォータを使用します。
Workersは自動的に世界中のCloudflareグローバルネットワークサーバーにスケールします。Workersが処理できるリクエストの数に一般的な制限はありません。
Cloudflareの悪用防止方法は、善意のトラフィックには影響しません。ただし、少数のクライアントIPアドレスから毎秒数千のリクエストを送信すると、意図せずCloudflareの悪用防止をトリガーする可能性があります。トラフィックに対して1015エラーが返されることを予想している場合や、アプリケーションがこれらのエラーを受けることを予想している場合は、Cloudflareサポートに連絡して制限を引き上げてもらうことができます。Cloudflareの悪用防止Workersレート制限は、Enterprise顧客には適用されません。
また、Cloudflareダッシュボードにログインし、アカウントとゾーンを選択してセキュリティ > イベントに移動することで、悪用防止Workerレート制限によって制限されているかどうかを確認できます。イベントを見つけて展開します。Rule IDがworkerであれば、これは悪用防止Workerレート制限が適用されていることを確認します。
バーストレートと日次リクエスト制限はアカウントレベルで適用されるため、*.workers.devサブドメインのリクエストは、同じ制限にカウントされます。これらの制限を自動的に解除するには、Workers Paidプラン ↗にアップグレードしてください。
Workers Freeプランを使用しているアカウントは、1分あたり1,000リクエストのバーストレート制限を受けます。レート制限されたサイトを訪問するユーザーは、Cloudflareの1015エラーページを受け取ります。ただし、プログラムでWorkerを呼び出している場合は、レート制限ページを検出し、HTTPステータスコード429を探すことで自分で処理できます。
悪用防止保護によってレート制限されているWorkersは、Cloudflareダッシュボードでも確認できます：
- Cloudflareダッシュボード ↗にログインし、アカウントとウェブサイトを選択します。
- セキュリティ > イベント > アクティビティログにスクロールします。
ruleIDがworkerのWebアプリケーションファイアウォールブロックイベントをログで確認します。
Workers Freeプランを使用しているアカウントは、日次リクエスト制限が100,000リクエストに設定されています。Freeプランの日次リクエストカウントは、UTCの真夜中にリセットされます。日次リクエスト制限エラーの結果として失敗したWorkerは、対応するルートを2つのモードで切り替えることで構成できます：1) Fail open および 2) Fail closed。
ルートがフェイルオープンモードの場合、失敗したワーカーをバイパスし、受信トラフィックに対して操作を行うのを防ぎます。受信リクエストは、ワーカーが存在しないかのように振る舞います。
フェイルクローズモードのルートは、訪問者にCloudflareの1027エラーページを表示し、ワーカーが一時的に無効になっていることを示します。Cloudflareは、ワーカーがセキュリティ関連のタスクを実行している場合、このオプションを推奨します。
多くのグローバルCloudflareネットワークサーバーの各Workersインスタンスは、1つだけ実行されます。各Workersインスタンスは最大128 MBのメモリを消費できます。グローバル変数を使用して、個々のノード間でリクエスト間のデータを永続化します。ただし、ノードは時折メモリから追い出されることに注意してください。
ワーカーが128 MBの制限を超えるリクエストを処理すると、Cloudflare Workersランタイムは1つ以上のリクエストをキャンセルする場合があります。これらのエラーやCPU制限の超過を確認するには：
- Cloudflareダッシュボード ↗にログインし、アカウントを選択します。
- Workers & Pagesを選択し、Overviewで調査したいワーカーを選択します。
- Metricsの下で、Errors > Invocation Statusesを選択し、Exceeded Memoryを確認します。
メモリ使用量が気になる場合は、TransformStream APIを使用してレスポンスをストリーミングします。これにより、全体のレスポンスをメモリに読み込むことを避けられます。
ローカルでDevToolsを使用すると、コード内のメモリリークを特定するのに役立ちます。詳細については、DevToolsによるメモリプロファイリングのドキュメントを参照してください。
サブリクエストは、ワーカーがFetch APIを使用してインターネットリソースに対して行うリクエストや、R2、KV、またはD1などの他のCloudflareサービスへのリクエストです。
アカウント内の別のワーカーにサブリクエストを行うには、Service Bindingsを使用します。サービスバインディングを使用すると、リクエストがインターネットを経由せずに別のワーカーにHTTPリクエストを送信できます。
同じゾーンで実行されているアカウント内の別のワーカーに対して、グローバルfetch()を使用してサブリクエストを行おうとすると、リクエストは失敗します。
ワーカーからターゲットワーカーに対して、ルートではなくカスタムドメインで実行されている場合、リクエストは許可されます。
ワーカーが行えるサブリクエストの制限は、バンドル使用モデルでリクエストごとに50、無制限使用モデルでリクエストごとに1,000です。リダイレクトチェーン内の各サブリクエストは、この制限にカウントされます。つまり、ワーカーが行うサブリクエストの数は、ワーカー内のfetch(request)呼び出しの数よりも多くなる可能性があります。
Workers KVやDurable Objectsなどの内部サービスへのサブリクエストの場合、サブリクエストの制限はリクエストごとに1,000であり、ワーカーに設定された使用モデルに関係なく適用されます。
ワーカーが使用できるリアルタイムの量に設定された制限はありません。リクエストを送信したクライアントが接続されている限り、ワーカーは処理を続け、サブリクエストを行い、そのリクエストのためにタイムアウトを設定できます。
クライアントが切断されると、そのクライアントのリクエストに関連するすべてのタスクは積極的にキャンセルされます。ワーカーがevent.waitUntil()に約束を渡した場合、キャンセルは約束が完了するまで、または追加の30秒が経過するまで遅延されます。どちらが先に起こるかは不明です。
ワーカーの各呼び出しに対して、最大6つの接続を同時に開くことができます。以下のAPI呼び出しによって開かれた接続はすべて、この制限にカウントされます：
- Fetch APIの
fetch()メソッド。 - Workers KV名前空間オブジェクトの
get()、put()、list()、およびdelete()メソッド。 - キャッシュオブジェクトの
put()、match()、およびdelete()メソッド。 - R2の
list()、get()、put()、delete()、およびhead()メソッド。 - キューの
send()およびsendBatch()メソッド。 connect()APIを使用してTCPソケットを開くこと。
呼び出しが6つの接続を開いた後でも、追加の接続を開こうとすることができます。
- これらの試みは保留キューに入れられます — 現在開いている接続の1つが閉じるまで接続は開始されません。
- 以前の接続が後の接続を遅延させる可能性があります。ワーカーが多くの同時サブリクエストを行おうとすると、後のサブリクエストが開始されるまでに時間がかかるように見えることがあります。
アプリケーション内でfetch()を使用しているが、レスポンスボディを消費する必要がない場合、response.body.cancel()を使用して未読のレスポンスボディが同時接続を消費するのを避けることができます。
たとえば、HTTPレスポンスコードが成功（2xx）であるかどうかを確認したい場合、ボディを消費する前に保留中のレスポンスボディを明示的にキャンセルする必要があります：
let resp = await fetch(url);
// 成功したレスポンスのボディのみを読み取るif (resp.statusCode <= 299) { // resp.json()、resp.text()またはその他の方法でボディを処理する} else { // 明示的にキャンセルする resp.body.cancel();}これにより、オープン接続が解放されます。
システムがワーカーがオープン接続でデッドロックしていることを検出した場合（たとえば、ワーカーが保留中の接続試行を持っているが、すでに開いている接続で進行中の読み取りまたは書き込みがない場合）、最も最近使用されていないオープン接続がキャンセルされ、ワーカーがブロック解除されます。
ワーカーが後でキャンセルされた接続を使用しようとすると、例外がスローされます。これらの例外は実際にはまれに発生するはずですが、ワーカーが即座に使用する必要のない接続を開くことは一般的ではありません。
ワーカーの最大環境変数数（秘密とテキストを合わせて）は、Workers Paidプランで128変数、Workers Freeプランで64変数です。 アカウントごとの環境変数の数に制限はありません。
各環境変数には5 KBのサイズ制限があります。
ワーカーは、Workers Paidプランで圧縮後最大10 MB、Workers Freeプランで最大1 MBのサイズにすることができます。
wranglerを使用してドライランを実行し、wranglerによって出力された最終的な圧縮（gzip）サイズを確認することで、ワーカーバンドルの圧縮後のサイズを評価できます：
wrangler deploy --outdir bundled/ --dry-run# 出力は以下のようになります：Total Upload: 259.61 KiB / gzip: 47.23 KiB大きなワーカーバンドルは、ワーカーの起動時間に影響を与える可能性があるため、ワーカーをメモリに読み込む必要があります。不要な依存関係を削除するか、Workers KV、D1データベースまたはR2を使用して、設定ファイル、静的アセット、バイナリデータをワーカーコード内にバンドルするのではなく保存することを検討してください。
ワーカーは、400 ms以内にグローバルスコープ（ハンドラーの外のトップレベルコード）を解析し、実行できる必要があります。ワーカーのサイズは、解析および評価するコードが多いため、起動に影響を与える可能性があります。グローバルスコープ内の高コストのコードを避けることで、起動を効率的に保つことができます。
ワーカーの起動時間を測定するには、Wranglerを使用してCloudflareにデプロイします。npx wrangler@latest deployまたはnpx wrangler@latest versions uploadを実行すると、Wranglerはコマンドライン出力でワーカーの起動時間を出力します。これは、Workers Script APIまたはWorkers Versions APIのstartup_time_msフィールドを使用します。
この制限を下回るのに苦労している場合は、ローカルでDevToolsを使用してプロファイリングし、コードを最適化する方法を学ぶことを検討してください。
Workers Paidプランでは、アカウントに最大500のワーカーを持つことができ、Workers Freeプランでは最大100のワーカーを持つことができます。
500を超えるワーカーが必要な場合は、Workers for Platformsの使用を検討してください。
各ゾーンには1,000のルートの制限があります。ゾーンに1,000を超えるルートが必要な場合は、Workers for Platformsの使用を検討するか、この制限の増加をリクエストしてください。
ルーティングを構成する際、ワーカーが参照できるゾーンの最大数は1,000です。ワーカーに1,000を超えるゾーンが必要な場合は、Workers for Platformsの使用を検討するか、この制限の増加をリクエストしてください。
ワーカーによる画像リサイズを使用する場合は、適用される制限に関する詳細について画像リサイズのドキュメントを参照してください。
単一のリクエストに対して、コンソールに最大128 KBのデータ（console.log()ステートメント、例外、リクエストメタデータおよびヘッダー）を出力できます。この制限を超えると、リクエストに関連するさらなるコンテキストはログに記録されず、ワーカーのログを追尾する際やTail Worker内で表示されません。
ログプッシュ先に送信されるフィールドの最大サイズに関する情報は、Workers Trace Event Logpushのドキュメントを参照してください。
他の開発者プラットフォームのリソース制限を確認してください。