eCDN レート制限ルール

レート制限ルールを使用することにより、特定の式に一致するリクエストのレート制限を指定し、そのレート制限に達したときにアクションを実行できます。レート制限ルールを使用して、特定のトラフィックパターンをターゲットにしてボットなどの脅威に対抗することで、ストアフロントの可用性を向上することができます。

このガイドでは、関連するさまざまなレート制限パラメーターの概要とともに、CDN-API を使用してこれらのルールをゾーンで有効にする方法について説明します。このページの下部にあるよくある質問 (FAQ) セクションも参照してください。

レート制限ルールの動作は、レート制限パラメーターの数によって異なります。

  • 説明
  • ルール式
  • 特性
  • アクション
  • 期間
  • 期間ごとのリクエスト
  • 緩和タイムアウト (Block ルールまたは Log ルールの場合のみ)
  • カウント式 (オプション)
  • 有効 (オプション)
  • 位置 (オプション)
  • API での使用法: description
  • レート制限ルールの説明。

  • API での使用法: expression

  • ルールをいつ適用するかを定義します。ルール式は、true または false のいずれかに評価されます。ルール式が true と評価された場合、ルールが実行されます。レート制限ルールの場合、ルールのアクションは、その時点でレート制限条件が満たされている場合にのみ適用されます。

    • 比較演算子:

      • eq, ne, contains, matches, in, lt, le, gt, ge

    • 論理演算子:

      • not, and, or, xor

    • 関数:

      関数説明式での使用法タイプ例
      any引数の比較演算子が、引数配列の値の いずれか に対して true を返す場合に true を返します。それ以外の場合は false を返します。any(Array<Boolean>)Booleanany(http.request.headers[\"content-type\"][*] eq \"application/x-www-form-urlencoded\")
      all引数の比較演算子が、引数配列の すべて の値に対して true を返す場合に true を返します。それ以外の場合は false を返します。all(Array<Boolean>)Booleanall(http.request.headers[\"content-type\"][*] eq \"application/json\")
      concatコンマで区切られた値のリストを取ります。引数の値を 1 つの String (文字列) に連結します。concat( String | Integer | Bytes | Array elements)Stringconcat(http.request.uri.path,\"String\") eq \"sampleString\"
      ends_withソースが、指定された部分文字列で終わる場合に true を返します。それ以外の場合は false を返します。ソースをリテラル値 ("foo" など) にすることはできません。ends_with(sourceString, substringString) Booleanends_with(http.request.uri.path, \".html\")
      lenString (文字列) フィールドまたは Bytes (バイト) フィールドのバイト長を返します。len(String | Bytes) Integerlen(http.host) lt 20
      lookup_json_integerfield に指定された key に関連付けられた整数値を返します。

      注: field は、有効な JSON ドキュメントの文字列表現である必要があります。key は、属性名、JSON 配列内の 0 から始まる位置番号、またはこれら 2 つのオプションの組み合わせ (追加の関数パラメーターとして) にすることができますが、JSON ドキュメントの階層に従って特定の整数値を取得します。この関数は、通常の整数に対してのみ機能します。たとえば、42.0 などの小数点以下がゼロの浮動小数点数では機能しません。      		lookup_json_integer(fieldString, keyString | Integer [, keyString | Integer , …])Integer
      lookup_json_integer(http.cookie, \"sampleCookie\") eq 10

      lookup_json_integer(http.cookie, 1) eq 10

      lookup_json_integer(http.cookie, 1, \"sampleCookie \") eq 10
      lookup_json_stringfield に指定された key に関連付けられた文字列の値を返します。

      注: field は、有効な JSON ドキュメントの文字列表現である必要があります。key は、属性名、JSON 配列内の 0 から始まる位置番号、またはこれら 2 つのオプションの組み合わせ (追加の関数パラメーターとして) にすることができますが、JSON ドキュメントの階層に従って特定の整数値を取得します。      		lookup_json_string(fieldString, keyString | Integer [, keyString | Integer, …])String
      lookup_json_string(http.cookie, \"sampleCookie\") eq \"sampleString\"

      lookup_json_string(http.cookie, 1) eq \"sampleString\"

      lookup_json_string(http.cookie, 1, \"sampleCookie\") eq \"sampleString\"
      lower文字列フィールドを小文字に変換します。大文字の ASCII バイトのみが変換されます。他のすべてのバイトは影響を受けません。lower(String)Stringlower(http.host) eq \"www.example.com\"
      starts_withソースが、指定された部分文字列で始まる場合に true を返します。それ以外の場合は false を返します。ソースをリテラル値 ("foo" など) にすることはできません。starts_with(sourceString, substringString)Booleanstarts_with(http.request.uri.path, \"/blog\")
      substringstart バイトインデックスから end バイトインデックスまで (ただし、end バイトインデックスを除く) の field 値の一部 (文字列またはバイトフィールドの値) を返します。

      field の最初のバイトは、インデックス 0 です。オプションの end インデックスを指定しない場合、関数は start インデックスから文字列の末尾までの文字列の一部を返します。end インデックスは start インデックスより大きくなければなりません。start インデックスと end インデックスは負の整数値にすることができ、これにより、文字列の先頭ではなく末尾の文字にアクセスできます。      		substring(fieldString | Bytes, startInteger [, endInteger])String
      substring(http.request.uri.path, 2, 5) eq \"sampleString\"

      substring(http.request.uri.path, 2) eq \"sampleString\"
      upper文字列フィールドを大文字に変換します。小文字の ASCII バイトのみが変換されます。他のすべてのバイトは影響を受けません。upper(String)Stringupper(http.host) eq \"WWW.EXAMPLE.COM\"
      url_decode次のように source で定義された URL 形式の文字列をデコードします。
      - %20 と + を空白文字 ( ) にデコードします。

      options パラメーターはオプションです。すべてのオプションは、引用符で囲まれた単一の文字列として指定する必要があります (例: "r" や "ur")。使用可能なオプションは次のとおりです。
      - r: 再帰的デコードを適用します。たとえば、%2520 は空白文字に 2 回 (再帰的に) デコードされます。
      - u: Unicode パーセントのデコードを有効にします。たとえば、%E2%98%81%EF%B8%8F は雲の絵文字にデコードされます。      		url_decode(sourceString [, optionsString])String
      url_decode(http.request.full_uri) contains \"sampleString\"


      url_decode(http.request.full_uri, \"ur\") contains \"sampleString\"g"'

    • フィールド:

      フィールド説明式での使用法タイプ例
      AS Numberクライアント IP アドレスに関連付けられた自律システム (AS) 番号。ip.geoip.asnumIntegerip.geoip.asnum eq 12345
      CookieCookie 全体を文字列として表します。http.cookieStringhttp.cookie eq \"session=8521F670545D7865F79C3D7BEDC29CCE;-background=light\"
      CountryISO 3166-1 Alpha 2 形式の 2 文字の国コードを表します。ip.geoip.countryStringnot ip.geoip.country eq \"US\"
      Host Name完全なリクエスト URI で使用されるホスト名を表します。http.hostStringhttp.host eq \"www.example.com\"
      IP Addressクライアントの TCP IP アドレスを表します。ip.srcIP addressip.src in {93.184.216.34 192.168.123.132}
      HTTP HeadersHTTP リクエストヘッダーを Map (または連想配列) として表します。http.request.headersMap\String\Arrayany(http.request.headers[\"content-type\"][*] eq \"application/json\")
      URI FullWeb サーバーが受信した完全な URI を表します。http.request.full_uriStringhttp.request.full_uri eq \"htt­ps://www.example.com/path/index?section=123456&expand=comments\"
      URIリクエストの URI パスとクエリ文字列を表します。http.request.uriStringhttp.request.uri eq \"/path/index?section=123456&expand=comments\"
      URI Pathリクエストの URI パスを表します。http.request.uri.pathStringhttp.request.uri.path eq \"/path/index\"
      URI Query String? 区切り文字を除いたクエリ文字列全体を表します。http.request.uri.queryStringhttp.request.uri.query eq \"section=123456&expand=comments\"
      Raw URI Fullhttp.request.full_uri 非 raw フィールドと同様です。Web サーバーが受信した完全な URI を表します。URI フラグメント (存在する場合) は含まれず、変換も行われません。この raw フィールドには、HTTP サーバーによる基本的な正規化が含まれる場合があることに注意してください。raw.http.request.full_uriStringraw.http.request.full_uri eq \"htt­ps://www.example.com/path/index?section=123456&expand=comments\"
      Raw URIhttp.request.uri 非 raw フィールドと同様です。リクエストの URI パスとクエリ文字列を変換せずに表します。この raw フィールドには、HTTP サーバーによる基本的な正規化が含まれる場合があることに注意してください。raw.http.request.uriStringraw.http.request.uri eq \"/path/index?section=123456&expand=comments\"
      Raw URI Pathhttp.request.uri.path 非 raw フィールドと同様です。リクエストの URI パスを変換せずに表します。この raw フィールドには、HTTP サーバーによる基本的な正規化が含まれる場合があることに注意してください。raw.http.request.uri.pathStringraw.http.request.uri.path eq \"/path/index\"
      Raw URI Query Stringhttp.request.uri.query 非 raw フィールドと同様です。? 区切り文字と変換を含まないクエリ文字列全体を表します。この raw フィールドには、HTTP サーバーによる基本的な正規化が含まれる場合があることに注意してください。raw.http.request.uri.queryStringraw.http.request.uri.query eq \"section=123456&expand=comments\"
      HTTP Referer現在リクエストされているページにリンクされている Web ページのアドレスを含む HTTP Referer リクエストヘッダーを表します。http.refererStringhttp.referer contains \"www.example.com\"
      User AgentHTTP ユーザーエージェントを表します。これはクライアントオペレーティングシステムと Web ブラウザーの識別を可能にする特性文字列を含むリクエストヘッダーです。http.user_agentStringhttp.user_agent eq \"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/101.0.4951.61 Safari/537.36\"
      Request MethodHTTP メソッドを表し、大文字の文字列として返されます。http.request.methodStringhttp.request.method eq \"GET\"
      Continentクライアント IP アドレスに関連付けられた大陸コードを表します。
      AF – アフリカ
      AN – 南極大陸
      AS – アジア
      EU – ヨーロッパ
      NA – 北アメリカ
      OC – オセアニア
      SA – 南アメリカ
      T1 – Tor ネットワーク      		ip.geoip.continentStringip.geoip.continent in {\"NA\" \"EU\"}
      Bot Score*リクエストがボットから発信された可能性を 1 ～ 99 のスコアで表します。スコアが低い場合は、リクエストがボットまたは自動エージェントからのものであることを示します。cf.bot_management.scoreIntegercf.bot_management.score le 10
      Threat Score0 ～ 100 の脅威スコアを表します。0 はリスクが低いことを示します。10 を超える値はスパマーまたはボットを表している可能性があり、40 を超える値はインターネット上の悪意ある人物を識別します。
      60 を超える値はまれです。一般的な推奨事項は、10 を超えるスコアのリクエストにチャレンジを提示し、50 を超えるリクエストをブロックすることです。      		cf.threat_scoreIntegercf.threat_score gt 50
      JA3 Fingerprint*潜在的なボットリクエストの識別に役立つ SSL/TLS フィンガープリントを提供します。cf.bot_management.ja3_hashStringcf.bot_management.ja3_hash eq \"e7d705a3286e19ea42f587b344ee6865\"
      Verified Bot*true の場合、このフィールドはリクエストが既知の良好なボットまたはクローラーから発信されたことを示します。cf.client.bot と同じ情報を提供します。cf.bot_management.verified_botBooleancf.bot_management.verified_bot

cf.bot.management.* フィールドを使用するには、ボット管理を有効にして独自の Cloudflare アカウント (o2o) を実装する必要があります。

レート制限ルール式の長さは最大 4096 文字です。
  • API での使用法: characteristics
  • 文字列の配列を受け取ります。特性により、受信リクエストがどのようにグループ化されるかが決まります。定義された特性と同じ値をもつリクエストはグループ化され、レートカウンターを共有します。
    • たとえば、ルールの特性として IP が使用されるとしましょう。単一の IP アドレスからのリクエストのレートが、定義された制限を超える場合、その IP アドレスからのさらなるリクエストのレートは制限されます。他の IP アドレスからのリクエストは、同じレートカウンターを共有しません。つまり、1 つの IP アドレスのリクエストレートは、他の IP アドレスのリクエストレートに影響を与えません。
  • 以下の特性がサポートされます。
特性説明特性配列での使用法
IPクライアントの TCP IP アドレスに基づいてリクエストをグループ化します。ip.src
NAT サポート付き IP同じ IP アドレスを共有する NAT のもとでのリクエストなどの状況を含め、プライバシー保護技術を使用してユニーク訪問者数を識別します。cf.unique_visitor_id

  • 同じレート制限ルールの特性として「 NAT サポート付き IP 」と「 IP 」の両方を使用することはできないことに注意してください。したがって、API の使用例は次のとおりです。

    "characteristics": ["ip.src"]

    または

    "characteristics": ["cf.unique_visitor_id"]

推奨事項は、NAT サポート付きの IP を使用することです。詳細については、よくある質問 (FAQ) を参照してください。
  • API での使用法: action
  • レート制限基準が満たされた場合に実行するアクションです。
  • サポートされているアクション: block、log、legacy_captcha、js_challenge、managed_challenge
    • 各アクションの詳細については、こちらのドキュメントを参照してください。
  • API での使用法: period
  • リクエストレートを評価する際に考慮する期間。
  • サポートされている値: 10、60、120、300、600 (単位: 秒)。
  • API での使用法: requestsPerPeriod
  • 任意の正の整数値。指定された期間内のリクエスト数の制限を表します。
  • API での使用法: mitigationTimeout
  • 「タイムアウト」の時間。レート制限基準が満たされると、レート制限ルールは、このフィールドで定義された期間、ルール式に一致するさらなるリクエストにアクションを適用し続けます。
    • block または log アクションを使用するルールにのみ関連します。このパラメーターは、チャレンジアクション (legacy_captcha、js_challenge、managed_challenge) を使用するルールには指定できません。
  • サポートされている値: 60、120、300、600、3600、86400 (単位: 秒)。
    • mitigationTimeout の値も、定義された period 以上である必要があります。
  • API での使用法: countingExpression
  • レート制限を適用するリクエスト基準を定義します。つまり、このパラメーターはレートカウンターをインクリメントするタイミングを定義します。レートカウンターは、期間ごとにリクエスト数を追跡 ​​ します。レートカウンターが、設定した期間ごとに定義されたリクエスト制限を超えると、ルールのアクションが実行されます。
    • カウント式が指定されていない場合、カウント式はルール式と同じになります。
    • カウント式は、HTTP レスポンスコードに基づいてレート制限するオプションをサポートしています。 ルール式のみを使用する場合、これはできません。HTTP レスポンスコードに基づいてレート制限を行う場合は、カウント式を使用する必要があります。カウント式を使用する場合のその他の例については、よくある質問 (FAQ) を参照してください。
  • カウント式の検証はルール式と同じですが、次のフィールドが追加されています。
フィールド説明カウント式での使用法タイプ例
HTTP Response Codeクライアントに返される HTTP ステータスコードを表します。http.response.codeInteger``http.response.code eq 400
  • API での使用法: enabled
  • レート制限ルールが有効かどうかを指定します。デフォルト値は true です。

  • API での使用法: position

  • このパラメーターを指定すると、ルールセット内の特定の相対位置にルールが挿入されます。このパラメータは、レート制限ルールを作成または更新するときに使用できます。

    • 提供されたインデックスが現在のルールセット内のルールと一致するかを検証します。レート制限ルールの作成時に位置が指定されていない場合、そのルールはデフォルトでルールセットの最後に追加されます。

次のセクションでは、レート制限ルールの一般的なユースケースについて説明します。これらの例を使用し、必要に応じて組み合わせて、独自のビジネスニーズに合わせて調整してください。

  • ユーザーエージェント、IP アドレス、ホスト、国、世界の地域などの基準に基づくアクセス管理を含む、リソースへのきめ細かいアクセス管理を実施します。
  • 例 A: 個々のユーザーエージェントによって実行されるリクエストの速度を制限します。
    • ルール式: http.user_agent eq "MobileApp"
    • レート: 100 件のリクエスト/ 10 分
    • アクション: 管理されたチャレンジ
  • 例 B: 特定の IP アドレスまたは ASN をレート制限ルールに含める、または除外します。
    • ルール式: http.request.uri.path eq "/status" and http.request.method eq "GET" and not ip.src in { <defined IPs> }
    • レート: 10 件のリクエスト / 1 分
    • アクション: 管理されたチャレンジ
  • クレデンシャルスタッフィングやアカウント乗っ取り攻撃から保護します。一般的なユースケースは、ログインエンドポイントを保護することです。また、複数のレート制限ルールを作成し、増加するペナルティを定義して、リクエストが多すぎるクライアントを管理することもできます。
  • 例 A: ログイン失敗回数が多すぎる場合の保護。
    • ルール式: http.host eq "example.com" and http.request.uri.path eq "/login" and http.request.method eq "POST"
    • カウント式: http.request.uri.path eq "/login" and http.request.method eq "POST" and http.response.code in {401 403}
    • レート: 5 件のリクエスト / 1 分
    • アクション: 管理されたチャレンジ
  • 例 B: ユーザーが例 A で定義されたルールによって提示されたチャレンジにパスした場合に備えて、別の保護層を作成します。ユーザーがこの 2 番目のしきい値を超えると、ログインページへのアクセスは 10 分間ブロックされます。
    • ルール式: http.host eq "example.com" and http.request.uri.path eq "/login"
    • カウント式: http.request.uri.path eq "/login" and http.request.method eq "POST" and http.response.code in {401 403}
    • レート: 20 件のリクエスト/ 10 分
    • アクション: 10 分間ブロック
  • 個々のクライアントが実行するオペレーションの数を制限します。ボットによるスクレイピング、機密データへのアクセス、新しいアカウントの一括作成、自動買い付けを防ぎます。
  • 例 A: (クエリ文字列による) コンテンツのスクレイピングを防ぎます。
    • ルール式: http.request.uri.path eq "/merchant" and http.request.uri.query contains "action=lookup_price"
    • レート: 10 件のリクエスト / 1 分
    • アクション: 管理されたチャレンジ
  • 例 B: ボットからのリクエストを制限します。ボットからのトラフィックを識別する一般的な方法は、エラーレスポンスのステータスコードを大量にトリガーするリクエストをレート制限することです。
    • ルール式: http.host eq "example.com"
    • カウント式: http.response.code in {401 403}
    • レート: 25 件のリクエスト/ 2 分
    • アクション: 管理されたチャレンジ
  • 例 C: ゾーンにボット管理の資格がある場合は、bot_management フィールドの使用を検討します。
    • ルール式: cf.bot_management.score lt 30 and http.request.uri.query contains "action=delete"
    • レート: 20 件のリクエスト/ 5 分
    • アクション: 1 時間ブロック

次のセクションでは、一般的な使用例について説明します。

このエンドポイントは、指定されたゾーンのレート制限ルールを作成します。

  • パラメーター検証の詳細については、上記の レート制限パラメーター セクションを参照してください。

新しく作成されたルールはデフォルトで有効になり、特に指定のない限り、ルールセットの最後に追加されます。1 つのゾーンで最大 3 つのレート制限ルールが許可されます。

成功レスポンス - 201 HttpStatus コードの例 レスポンスボディには、作成されたレート制限ルールが含まれます。

このエンドポイントは、指定されたゾーンのすべてのレート制限ルールを優先順位に従って返します。レート制限ルールが存在しない場合は、404 (Not Found) レスポンスが返されます。

成功レスポンス - 200 HttpStatus コードの例 レスポンスボディには、指定されたゾーンの現在のレート制限ルールがすべて含まれます。

このエンドポイントは、リクエストされたレート制限ルールを返します。リクエストされたルールが存在しない場合は、404 (Not Found) レスポンスが返されます。

成功レスポンス - 200 HttpStatus コードの例 レスポンスボディには、リクエストされたレート制限ルールが含まれます。

このエンドポイントは、リクエストされたレート制限ルールを更新します。リクエストされたルールが存在しない場合は、404 (Not Found) レスポンスが返されます。

  • 少なくとも 1 つのレート制限パラメーターをリクエストボディに指定する必要があります。
  • countingExpression を設定したが、それを削除したい (したがってルール式のデフォルトにしたい) というシナリオでは、リクエストボディに "countingExpression": "" を含めて値をリセットする必要があります。

成功レスポンス - 200 HttpStatus コードの例 レスポンスボディには、リクエストされたレート制限ルールが含まれます。

このエンドポイントは、リクエストされたレート制限ルールを削除します。リクエストされたルールが存在しない場合は、404 (Not Found) レスポンスが返されます。

成功レスポンス - 204 HttpStatus コード (コンテンツなし) の例

  • カウント式はルール式とどのように異なりますか?
    • ルール式は、レート制限ルールを 評価 するタイミングを定義します。リクエストがルール式に一致する場合、レート制限ルールが評価されます。レート制限ルールを評価するときは、レートカウンターが、期間ごとに定義されたリクエストを超えているかどうかを確認します。超えている場合、ルールのアクションが適用されます。
    • カウント式は、レート制限する リクエストの種類 を定義します。リクエストがカウント式に一致する場合、レートカウンターがインクリメントされます。カウンターは、レート制限基準を満たしたリクエスト数を記録します。
  • カウント式はどのような場合に使用しますか?
    • ほとんどのユースケースでは、カウント式をルール式と同じにするだけで十分であり、カウント式を指定する必要はありません。
      • 例 A: 特定のパスに送信される高トラフィックをレート制限します。リクエスト数が 1 分間に 10,000 件を超えた場合、そのパスへのさらなるリクエストを 10 分間ブロックします。
        • ルール式: http.request.uri.path eq "/path"
        • カウント式 (デフォルト): http.request.uri.path eq "/path"
        • レート: 10,000 件のリクエスト / 1 分
        • アクション: 10 分間ブロック
    • 時には、HTTP レスポンスコードに基づいてレート制限を行いたい場合があります。これらのユースケースでは、カウント式を指定する必要があります。カウント式では、追加のレスポンスコードフィールドを利用できるためです。ルール式のみを使用する場合、HTTP レスポンスコードに基づくレート制限はできません。
      • 例 B: 自動化された攻撃者に対して管理されたチャレンジを提示することで、悪意のあるトラフィックでフォームが過負荷になるのを防ぎます。400 応答コードを返す特定のフォームに送信されるトラフィックをレート制限します。
        • ルール式: http.request.uri.path eq "/form"
        • カウント式: http.request.uri.path eq "/form" and http.response.code eq 400
        • レート: 15 件のリクエスト/ 5 分
        • アクション: 管理されたチャレンジ
    • 次に挙げるのは、カウント式をルール式と異なるものとする別の例です。
      • 例 C: 悪意のある攻撃者からログインエンドポイントを保護します。ユーザーが 10 分間に 15 回の不正なログインリクエストを行った場合、そのユーザーはサイト 全体 へのアクセスを 1 時間ブロックされます。
        • ルール式: http.host eq "example.com"
        • カウント式: http.request.uri.path eq "/login" and http.request.method eq "POST" and http.response.code in {401 403}
        • レート: 15 件のリクエスト/ 10 分
        • アクション: 1 時間ブロック
  • 特性はどのように機能しますか?
    • 定義されたルールの特性の値の組み合わせごとに、個別のレートカウンターが保持されます。つまり、特性によって、受信リクエストがどのようにグループ化されるかが決まります。
      • 次の特性で構成されたルールを考えてみましょう。
        • IP アドレス
        • HTTP ヘッダー x-api-key
      • この場合、HTTP ヘッダー X-API-Key の値は同じですが、IP アドレスが 異なる 2 つの受信リクエストは、値の組み合わせが異なるため、別々にカウントされます。さらに、カウンターはデータセンター間で共有はされません。
    • CDN-API は現在、「 IP 」または「 NAT サポート付き IP 」のみを特性として受け入れ、これら 2 つの特性を同じレート制限ルールで使用することはできないことに注意してください。したがって、上で示した使用例は今回は関係ありませんが、特性がどのように機能するかを理解するのに役立つ例となります。
  • NAT サポート付きの IP の使用が推奨されるのはなぜですか?
    • 同じ IP アドレスで eCDN にリクエストが入ってくる可能性がある状況でもユニーク訪問者を識別できるため、NAT サポート付き IP を使用することをお勧めします。
    • NAT サポート付き IP の使用は、スタック型 eCDN 構成を使用している顧客に必要です。 これは、リクエストが eCDN に到達する前にスタックされたプロバイダーを経由してルーティングされるためです。NAT サポート付き IP を使用すると、それぞれのユニーク訪問者が適切に識別され、スタックされたプロバイダーのソース IP はレート制限されなくなります。
  • ルールの順序が重要なのはなぜですか?
    • レート制限ルールは、リストされた最初のルールから始めて、レスポンスボディで返される順序で評価されます。特定のルールの優先度を更新するには、PATCH エンドポイントを使用し、リクエストボディに position パラメーターを指定します。
    • リクエストがレート制限基準を満たし、レート制限ルールの実行をトリガーすると、ルールのアクションが実行され、その特定のリクエストに対して他のレート制限ルールは評価されません。次のリクエストが受信されると、ルールの評価はルールセットの先頭から始まります。
  • ルール式を構築するにはどうすればいいですか?
    • ルール式の構築に関する詳細については、こちらのドキュメントを参照してください。
  • ルール式で特定のフィールドを使用するにはどうすればよいですか?
    • 特定のフィールドの使用法の詳細については、こちらのドキュメントを参照してください。