Skip to content

非公式本サイトは非公式の日本語ドキュメントであり、Cloudflare 公式サイトではありません。最新情報はdevelopers.cloudflare.comをご確認ください。

リクエストレートの計算

最終更新 Markdown で表示Agent セットアップ

Cloudflare は、ルールの 特性 の値の一意な組み合わせごとに別カウンターを持ち、リクエストレートを追跡します。

たとえば、次の特性を持つルールを考えます。

  • IP アドレス
  • HTTP ヘッダー x-api-key

2 つのリクエストが同じ x-api-key ヘッダー値を共有していても、IP アドレスが異なれば、特性の組み合わせが違うため Cloudflare は別々に数えます。

カウンターはデータセンター間で共有しません。同じ地理的ロケーションに属するデータセンターは例外です。

既定では、リクエストレートは受信リクエスト数に基づきます。Advanced Rate Limiting を契約している Enterprise のお客様は、各リクエストの処理コストに基づいてレートを決めることもできます。詳細は 複雑度ベースのレート制限 を参照してください。

例 A

次のレート制限ルール設定を考えます。

レート制限ルール #1

受信リクエストが次に一致する場合:
http.request.uri.path eq "/form" and any(http.request.headers["content-type"][*] eq "application/x-www-form-urlencoded")

アクションを選択: ブロック

期間(緩和タイムアウト): 10 分

リクエスト数: 1

計測期間: 10 秒

同じ特性を持つ:

  • データセンター ID(ダッシュボードでルールを作成すると既定で含まれます)
  • IP
  • ヘッダー値 > x-api-key

次の図は、上記のレート制限ルールの文脈で、Cloudflare が 4 件の受信リクエストをどう扱うかを示します。

4 件のリクエストのうち 1 件がレート制限される例です。詳細は以降を参照してください。

リクエスト 1 はルール式に一致するため、レート制限ルールが評価されます。Cloudflare は、このレート制限ルールの文脈で特性の値に対するリクエストカウンターを定義し、カウンターを 1 にします。カウンター値は リクエスト数 で定めた上限内のため、リクエストは許可されます。

リクエスト 2 はルール式に一致するため、Cloudflare はレート制限ルールを評価します。特性の値は既存のカウンターに一致しません(X-API-Key ヘッダーの値が異なります)。そのため Cloudflare は、このルールの文脈で別カウンターを定義し、1 にします。カウンター値は リクエスト数 で定めた上限内のため、このリクエストは許可されます。

リクエスト 3 はルール式に一致し、ルール特性の値はリクエスト 1 と同じです。そのため Cloudflare は既存カウンターの値を増やし、2 にします。カウンター値は リクエスト数 で定めた上限を超えたため、リクエスト 3 はブロックされます。

リクエスト 4 はルール式に一致しません。Content-Type ヘッダーの値が式の値と一致しないためです。そのため Cloudflare は、このリクエスト向けに新しいルールカウンターを作りません。リクエスト 4 はこのレート制限ルールの文脈では評価されず、リクエスト評価の流れの後続ルールへ渡されます。

例 B

次のレート制限ルール設定を考えます。カウント式は、レスポンスの HTTP ステータスコードが 400 のときにカウンターを 1 増やすと定義しています。

レート制限ルール #2

受信リクエストが次に一致する場合:
http.request.uri.path eq "/form"

アクションを選択: ブロック

期間(緩和タイムアウト): 10 分

リクエスト数: 1

計測期間: 10 秒

同じ特性を持つ:

  • データセンター ID(ダッシュボードでルールを作成すると既定で含まれます)
  • IP
  • ヘッダー値 > x-api-key

次のときにカウンターを増やす: http.request.uri.path eq "/form" and http.response.code eq 400

次の図は、10 秒の期間に受け取った 4 件の受信リクエストを、上記のレート制限ルールの文脈で Cloudflare がどう扱うかを示します。

カウント式にレスポンスフィールド(HTTP レスポンスコード)を使うレート制限ルールの、4 件のリクエストの例です。詳細は以降を参照してください。

リクエスト 1 はルール式に一致するため、レート制限ルールが評価されます。カウント式にレスポンスフィールド(http.response.code)があるため、キャッシュ済みコンテンツはスキップされ、リクエストはオリジンへ送られます。オリジンは 400 ステータスコードで応答します。カウント式に一致するため、Cloudflare はこのレート制限ルールの文脈で特性の値に対するリクエストカウンターを作り、1 にします。

リクエスト 2 はルール式に一致するため、Cloudflare はレート制限ルールを評価します。特性の値に対するリクエストカウンターは、まだ リクエスト数 で定めた上限内です。オリジンは 200 ステータスコードで応答します。レスポンスはカウント式に一致しないため、カウンターは増えず、値(1)のままです。

リクエスト 3 はルール式に一致するため、Cloudflare はレート制限ルールを評価します。リクエストはまだ リクエスト数 で定めた上限内です。オリジンは 400 ステータスコードで応答します。カウント式に一致し、カウンターは 2 になります。

リクエスト 4 はルール式に一致するため、Cloudflare はレート制限ルールを評価します。リクエストは リクエスト数 で定めた上限を超えています(カウンターは 2、上限は 1)。Cloudflare はレート制限ルール設定のアクションを適用し、リクエスト 4 と、このルールに一致する以降のリクエストを 10 分間ブロックします。

複雑度ベースのレート制限

リクエストの処理コストは同じではありません。単純な API の読み取りはリソースをほとんど使いませんが、複雑なデータベースクエリやファイルエクスポートは、はるかに多く使うことがあります。リクエスト数ベースのレート制限はこれらを同等に扱います。軽いリクエスト 100 件も、重いリクエスト 100 件も、同じカウンターを増やします。

複雑度ベースのレート制限は、オリジンサーバーが各リクエストに付けるコストスコアを追跡し、期間あたりのクライアントごとの合計スコア上限を適用します。こうすると、重いリクエストを少数送るクライアントは、リクエスト総数に関係なく、リクエスト数が多くなる前にレート制限できます。

複雑度ベースのレート制限を使うには、オリジンサーバーが各リクエストの数値スコアを含む HTTP レスポンスヘッダーを返す必要があります。このスコアは、そのリクエストを処理する複雑度またはコストを表します。値は 1 から 1,000,000 の間である必要があります。ルールが読むヘッダー名は設定で指定します。

複雑度ベースのレート制限ルールには、次のプロパティが必要です。

  • 期間あたりのスコア: 期間あたりに許可する合計スコアの上限です。合計がこの値を超えると、ルールアクションが実行されます。
  • 期間: 合計スコアを評価する時間枠です。
  • レスポンスヘッダー名: オリジンサーバーが設定する、各リクエストのスコアを含む HTTP レスポンスヘッダーです。

Cloudflare は、ルール式に一致し、ルール特性の値が同じすべてのリクエストの合計スコアをカウンターで保持します。カウント式に一致すると(既定ではルール式と同じ)、オリジンがレスポンスで渡した値だけスコアが増えます。合計スコアが設定した期間あたりの最大スコアより大きいと、ルールアクションが適用されます。

オリジンサーバーがスコア値を持つ HTTP レスポンスヘッダーを返さない場合、またはスコア値が許容範囲外の場合、対応するレート制限カウンターは更新されません。

例 C

次のレート制限ルール設定を考えます。ルールに一致すると、複雑度スコアのカウンターは、オリジンサーバーが返す x-score レスポンスヘッダーの値に基づいて増えます。

レート制限ルール #3

受信リクエストが次に一致する場合:
(http.request.uri.path eq "/graphql")

同じ特性を持つ:

  • データセンター ID(ダッシュボードでルールを作成すると既定で含まれます)
  • ヘッダー値 > x-api-key

レートが超過した場合: 複雑度ベース

  • 期間あたりのスコア: 400
  • 計測期間: 1 分
  • レスポンスヘッダー名: x-score

アクションを選択: ブロック

次の動作で: 選んだ期間ブロックする

期間(緩和タイムアウト): 10 分

次の図は、1 分間に受け取った 4 件の受信リクエストを、上記のレート制限ルールの文脈で Cloudflare がどう扱うかを示します。

x-score HTTP ヘッダーで渡される複雑度スコアを考慮するレート制限ルールの、4 件のリクエストの例です。詳細は以降を参照してください。

リクエスト 1 はルール式に一致するため、レート制限ルールが評価されます。オリジンは 200 ステータスコードと、x-score HTTP レスポンスヘッダーに複雑度スコア 100 を返します。Cloudflare はこのレート制限ルールの文脈で特性の値に対するリクエストカウンターを作り、100 にします。

リクエスト 2 はルール式に一致するため、Cloudflare はレート制限ルールを評価します。特性の値に対するリクエストカウンターは、まだ期間あたりの最大スコア内です。オリジンは 200 ステータスコードで応答し、リクエストカウンターは 200 増えます。現在の複雑度スコアは 300 です。

リクエスト 3 はルール式に一致するため、Cloudflare はレート制限ルールを評価します。特性の値に対するリクエストカウンターは、まだ期間あたりの最大スコア内です。オリジンは 200 ステータスコードで応答し、リクエストカウンターは 150 増えます。現在の複雑度スコアは 450 です。

リクエスト 4 はルール式に一致するため、Cloudflare はレート制限ルールを評価します。リクエストはルールで定めた期間あたりの最大スコアを超えています(カウンターは 450、最大スコアは 400)。Cloudflare はレート制限ルール設定のアクションを適用し、リクエスト 4 と、このルールに一致する以降のリクエストを 10 分間ブロックします。

役に立ちましたか?