Cloudflareは、ルールの特性の各値の組み合わせごとに、レート制限ルールのための別々のレートカウンターを保持します。
次の特性で構成されたルールを考えてみましょう：
x-api-keyこの場合、HTTPヘッダー X-API-Key の同じ値を持つ2つの受信リクエストは、異なるIPアドレスを持つため、別々にカウントされます。さらに、カウンターはデータセンター間で共有されません。
このレート制限ルールのカウントモデルは、受信リクエストの数に基づいています。高度なレート制限を持つエンタープライズ顧客は、受信リクエストの処理の複雑さに基づいてカウントモデルを設定するルールも構成できます。詳細については、複雑さに基づくレート制限を参照してください。
次のレート制限ルールの設定を考えてみましょう：
レート制限ルール #1
受信リクエストが一致する場合:
http.request.uri.path eq "/form" and any(http.request.headers["content-type"][*] eq "application/x-www-form-urlencoded")
アクションを選択: ブロック
期間（緩和タイムアウト）: 10分
リクエスト: 1
期間: 10秒
同じ値の（特性）:
x-api-key次の図は、Cloudflareが上記のレート制限ルールの文脈で4つの受信リクエストをどのように処理するかを示しています。
リクエスト1はルールの式に一致するため、レート制限ルールが評価されます。Cloudflareは、レート制限ルールの文脈で特性の値に対してリクエストカウンターを定義し、そのカウンターを1に設定します。カウンターの値がリクエストで設定された制限内にあるため、リクエストは許可されます。
リクエスト2はルールの式に一致し、そのためCloudflareはレート制限ルールを評価します。特性の値は既存のカウンターと一致しません（X-API-Keyヘッダーの値が異なります）。したがって、Cloudflareはこのルールの文脈で別のカウンターを定義し、それを1に設定します。カウンターの値はリクエストで設定された制限内にあり、このリクエストも許可されます。
リクエスト3はルールの式に一致し、リクエスト1と同じ特性の値を持っています。したがって、Cloudflareは既存のカウンターの値を増加させ、2に設定します。カウンターの値は現在、リクエストで定義された制限を超えているため、リクエスト3はブロックされます。
リクエスト4はルールの式に一致しません。なぜなら、Content-Typeヘッダーの値が式の値と一致しないからです。したがって、Cloudflareはこのリクエストのために新しいルールカウンターを作成しません。リクエスト4はこのレート制限ルールの文脈で評価されず、リクエスト評価ワークフローの後続のルールに渡されます。
次のレート制限ルールの設定を考えてみましょう。ルールのカウント式は、レスポンスHTTPステータスコードが400のときにカウンターが1増加することを定義しています：
レート制限ルール #2
受信リクエストが一致する場合:
http.request.uri.path eq "/form"
アクションを選択: ブロック
期間（緩和タイムアウト）: 10分
リクエスト: 1
期間: 10秒
同じ値の（特性）:
x-api-keyカウンターを増加させる条件:
http.request.uri.path eq "/form" and http.response.code eq 400
次の図は、Cloudflareが上記のレート制限ルールの文脈で10秒間に受信した4つのリクエストをどのように処理するかを示しています。
リクエスト1はルールの式に一致するため、レート制限ルールが評価されます。リクエストはオリジンに送信され、キャッシュされたコンテンツはスキップされます。なぜなら、レート制限ルールにはカウント式にレスポンスフィールド（http.response.code）が含まれているからです。オリジンは400のステータスコードで応答します。カウント式に一致するため、Cloudflareは特性の値に対してリクエストカウンターを作成し、このカウンターを1に設定します。
リクエスト2はルールの式に一致し、そのためCloudflareはレート制限ルールを評価します。特性の値のリクエストカウンターは、リクエストで定義された最大リクエスト数内にあります。オリジンは200のステータスコードで応答します。レスポンスがカウント式に一致しないため、カウンターは増加せず、その値は1のままです。
リクエスト3はルールの式に一致し、そのためCloudflareはレート制限ルールを評価します。リクエストはまだリクエストで定義された最大リクエスト数内にあります。オリジンは400のステータスコードで応答します。カウント式に一致するため、カウンターは2に設定されます。
リクエスト4はルールの式に一致し、そのためCloudflareはレート制限ルールを評価します。リクエストはもはやリクエストで定義された最大リクエスト数内にありません（カウンターの値は2で、最大リクエスト数は1です）。Cloudflareはレート制限ルール設定で定義されたアクションを適用し、リクエスト4およびその後に一致するリクエストを10分間ブロックします。
複雑さに基づくレート制限ルールは、同じ期間内のリクエスト数ではなく、特定の期間中のリクエスト処理の複雑さまたはコストに基づいてレート制限を行います。
一般的なユースケースは、各リクエストに対して、そのリクエストを処理するために必要なコスト（または複雑さ）の推定値でスコアを付けることです。レート制限ルールは、その後、各クライアントが特定の期間内にアプリケーションにかけることができる総複雑さの最大制限を強制することができます。これは、クライアントが送信するリクエストの総数に関係なく行われます。
複雑さに基づくレート制限ルールを構成する際、オリジンサーバーはレスポンスにHTTPヘッダーを含め、その複雑さスコアを提供する必要があります。
複雑さに基づくレート制限ルールには、次のプロパティが含まれている必要があります：
score_per_period）：期間あたりの最大スコア。この値を超えると、ルールアクションが実行されます。score_response_header_name）：オリジンサーバーによって設定される、現在のリクエストのスコアを含むレスポンスのHTTPヘッダーの名前。スコアは、現在のリクエストを処理するための複雑さ（またはコスト）に対応します。スコア値は1から1,000,000の範囲内でなければなりません。Cloudflareは、ルールの式に一致する特性の同じ値を持つすべてのリクエストの総スコアを保持します。カウント式に一致する場合（デフォルトでは、ルールの式と同じ）、オリジンからのレスポンスで提供された値によってスコアが増加します。総スコアが設定された期間あたりの最大スコアを超えると、ルールアクションが適用されます。
オリジンサーバーがスコア値を持つHTTPレスポンスヘッダーを提供しない場合、またはスコア値が許可された範囲外である場合、対応するレート制限カウンターは更新されません。
複雑さに基づくレート制限ルールの例については、APIを介してレート制限ルールを作成するを参照してください。