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>)
Boolean any(http.request.headers[\"content-type\"][*] eq \"application/x-www-form-urlencoded\")
all 引数の比較演算子が引数配列のすべての*値を返す true
*ときに返されますtrue
。それ以外の場合を返しますfalse
。all(Array<Boolean>)
Boolean all(http.request.headers[\"content-type\"][*] eq \"application/json\")
concat カンマで区切られた値のリストを取ります。引数の値を 1 つの String に連結します。 concat( String
|
Integer
|
Bytes
|
Array elements)
糸 concat(http.request.uri.path,\"String\") eq \"sampleString\"
ends_with true
ソースが指定された部分文字列で終わる場合を返します。それ以外の場合を返しますfalse
。ソースをリテラル値にすることはできません (例"foo"
: )。ends_with(sourceString, substringString)
Boolean ends_with(http.request.uri.path, \".html\")
len 文字列型フィールドまたはバイト型フィールドのバイト長を返します。 len(String
|
Bytes)
Integer len(http.host) lt 20
lookup_json_integer で field
指定された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_string で指定された に関連付けられた文字列値を返します。 key``field
注: は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)
String lower(http.host) eq \"www.example.com\"
starts_with true
ソースが指定された部分文字列で始まる場合を返します。それ以外の場合を返しますfalse
。ソースをリテラル値にすることはできません (例"foo"
: )。starts_with(sourceString, substringString)
Boolean starts_with(http.request.uri.path, \"/blog\")
substring バイトインデックスからバイトインデックスまで(ただし、バイトインデックスを除く) end
の値の一部field
(文字列またはバイトフィールドの値)start
を返します。
の最初のfield
バイトのインデックス0
は です。省略可能なend
index を指定しない場合、関数は文字列の index からstart
文字列の末尾までの部分を返します。インデックスはend
インデックスよりstart
大きくなければなりません。インデックスは負の整数値にすることができ、これにより、文字列の先頭ではなく末尾の文字にアクセスできます。&substring(fieldString
start``end
#124;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)
String upper(http.host) eq \"WWW.EXAMPLE.COM\"
url_decode - のように、 で定義された URL 形式の文字列をデコードし、空白文字 ( ) にデコードします。 source
-%20
+
(
このパラメーターはoptions
オプションです。すべてのオプションは、引用符で囲まれた単一の文字列として指定する必要があります (例"r"``"ur"
: )。使用可能なオプションは次のとおりです。r
再帰的デコードを適用します。たとえば、%2520
は空白文字に 2 回 (再帰的に) デコードされます。
-u
パーセントのデコードを有効にします。たとえば、 %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\"
-
フィールド:
フィールド 説明 式での使用法
タイプ
例AS Number クライアント IP アドレスに関連付けられた自律システム (AS) 番号。 ip.geoip.asnum
Integer ip.geoip.asnum eq 12345
Cookie Cookie 全体を文字列として表します。 http.cookie
String http.cookie eq \"session=8521F670545D7865F79C3D7BEDC29CCE;-background=light\"
Country ISO 3166-1 Alpha 2 形式の 2 文字の国コードを表します。 ip.geoip.country
String not ip.geoip.country eq \"US\"
Host Name 完全なリクエスト URI で使用されるホスト名を表します。 http.host
String http.host eq \"www.example.com\"
IP Address クライアントの TCP IP アドレスを表します。 ip.src
IP address ip.src in {93.184.216.34 192.168.123.132}
HTTP Headers HTTP リクエストヘッダーを Map (または連想配列) として表します。 http.request.headers
Map\String\Array any(http.request.headers[\"content-type\"][*] eq \"application/json\")
URI Full Web サーバーが受信した完全な URI を表します。 http.request.full_uri
String http.request.full_uri eq \"https://www.example.com/path/index?section=123456&expand=comments\"
URI リクエストの URI パスとクエリ文字列を表します。 http.request.uri
String http.request.uri eq \"/path/index?section=123456&expand=comments\"
URI Path リクエストの URI パスを表します。 http.request.uri.path
String http.request.uri.path eq \"/path/index\"
URI Query String ?
区切り文字を除いたクエリ文字列全体を表します。http.request.uri.query
String http.request.uri.query eq \"section=123456&expand=comments\"
Raw URI Full http.request.full_uri
非 raw フィールドと同様です。Web サーバーが受信した完全な URI を表します。URI フラグメント (存在する場合) は含まれず、変換も行われません。この raw フィールドには、HTTP サーバーによる基本的な正規化が含まれる場合があることに注意してください。raw.http.request.full_uri
String raw.http.request.full_uri eq \"https://www.example.com/path/index?section=123456&expand=comments\"
Raw URI http.request.uri
非 raw フィールドと同様です。リクエストの URI パスとクエリ文字列を変換せずに表します。この raw フィールドには、HTTP サーバーによる基本的な正規化が含まれる場合があることに注意してください。raw.http.request.uri
String raw.http.request.uri eq \"/path/index?section=123456&expand=comments\"
Raw URI Path http.request.uri.path
非 raw フィールドと同様です。リクエストの URI パスを変換せずに表します。この raw フィールドには、HTTP サーバーによる基本的な正規化が含まれる場合があることに注意してください。raw.http.request.uri.path
String raw.http.request.uri.path eq \"/path/index\"
Raw URI Query String http.request.uri.query
非 raw フィールドと同様です。?
区切り文字と変換を含まないクエリ文字列全体を表します。この raw フィールドには、HTTP サーバーによる基本的な正規化が含まれる場合があることに注意してください。raw.http.request.uri.query
String raw.http.request.uri.query eq \"section=123456&expand=comments\"
HTTP Referer 現在リクエストされているページにリンクされている Web ページのアドレスを含む HTTP Referer リクエストヘッダーを表します。 http.referer
String http.referer contains \"www.example.com\"
User Agent HTTP ユーザーエージェントを表します。これはクライアントオペレーティングシステムと Web ブラウザーの識別を可能にする特性文字列を含むリクエストヘッダーです。 http.user_agent
String http.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 Method HTTP メソッドを表し、大文字の文字列として返されます。 http.request.method
String http.request.method eq \"GET\"
Continent クライアント IP アドレスに関連付けられた大陸コードを表します。 AF
– アフリカAN
– 南極大陸AS
– アジアEU
– ヨーロッパNA
– 北アメリカOC
– オセアニアSA
– 南アメリカT1
– Tor ネットワークip.geoip.continent
String ip.geoip.continent in {\"NA\" \"EU\"}
Bot Score* リクエストがボットから発信された可能性を 1 ~ 99 のスコアで表します。スコアが低い場合は、リクエストがボットまたは自動エージェントからのものであることを示します。 cf.bot_management.score
Integer cf.bot_management.score le 10
Threat Score 0 ~ 100 の脅威スコアを表します。0 はリスクが低いことを示します。10 を超える値はスパマーまたはボットを表している可能性があり、40 を超える値はインターネット上の悪意ある人物を識別します。
60 を超える値はまれです。一般的な推奨事項は、10 を超えるスコアのリクエストにチャレンジを提示し、50 を超えるリクエストをブロックすることです。cf.threat_score
Integer cf.threat_score gt 50
JA3 Fingerprint* 潜在的なボットリクエストの識別に役立つ SSL/TLS フィンガープリントを提供します。 cf.bot_management.ja3_hash
String cf.bot_management.ja3_hash eq \"e7d705a3286e19ea42f587b344ee6865\"
Verified Bot* true
の場合、このフィールドはリクエストが既知の良好なボットまたはクローラーから発信されたことを示します。cf.client.bot
と同じ情報を提供します。cf.bot_management.verified_bot
Boolean cf.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.code | Integer | ``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 分間ブロック
- ルール式:
- 例 A: 特定のパスに送信される高トラフィックをレート制限します。リクエスト数が 1 分間に 10,000 件を超えた場合、そのパスへのさらなるリクエストを 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 分
- アクション: 管理されたチャレンジ
- ルール式:
- 例 B: 自動化された攻撃者に対して管理されたチャレンジを提示することで、悪意のあるトラフィックでフォームが過負荷になるのを防ぎます。400 応答コードを返す特定のフォームに送信されるトラフィックをレート制限します。
- 次に挙げるのは、カウント式をルール式と異なるものとする別の例です。
- 例 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 時間ブロック
- ルール式:
- 例 C: 悪意のある攻撃者からログインエンドポイントを保護します。ユーザーが 10 分間に 15 回の不正なログインリクエストを行った場合、そのユーザーはサイト 全体 へのアクセスを 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
パラメーターを指定します。 - リクエストがレート制限基準を満たし、レート制限ルールの実行をトリガーすると、ルールのアクションが実行され、その特定のリクエストに対して他のレート制限ルールは評価されません。次のリクエストが受信されると、ルールの評価はルールセットの先頭から始まります。
- レート制限ルールは、リストされた最初のルールから始めて、レスポンスボディで返される順序で評価されます。特定のルールの優先度を更新するには、PATCH エンドポイントを使用し、リクエストボディに
- ルール式を構築するにはどうすればいいですか?
- ルール式の構築に関する詳細については、こちらのドキュメントを参照してください。
- ルール式で特定のフィールドを使用するにはどうすればよいですか?
- 特定のフィールドの使用法の詳細については、こちらのドキュメントを参照してください。