CDN:ルールエンジン

複雑なロジックと EdgeScript

ルールエンジンは基本的な AND/OR の論理結合をサポートしているため、ほとんどの条件付きフィルタリングシナリオに適しています。ただし、次のシナリオは EdgeScript を使用するかどうかを判断する際の参考になります：

• 複雑な正規表現マッチング：ルールエンジンの正規表現演算子は、デフォルトで無効になっています。有効化を依頼するには、チケットを送信する必要があります。正規表現を頻繁に使用する場合は、EdgeScript が正規表現マッチングをネイティブにサポートしているため、より便利です。

• 高精度な多次元の組み合わせ：クライアント IP と User-Agent の両方を正規表現でマッチさせるなど、複数の条件を組み合わせた複雑な評価 (例：User-Agent に特定のキーワードが含まれる特定の IP アドレス範囲からのリクエストをブロックする) を設定するのは、ルールエンジンでは煩雑です。EdgeScript では、スクリプトロジックを使用して複数の条件を柔軟に組み合わせることができます。

• 細かな複数ディレクトリの IP アクセス制御：EdgeScript を使用すると、異なるディレクトリに対して異なる IP アドレス範囲のアクセスを許可できます。たとえば、1 つの IP アドレス範囲にすべてのディレクトリへのアクセスを許可し、特定の IP アドレスには 1 つのディレクトリへのみアクセスを許可し、それ以外の IP アドレスはすべて拒否できます。 match_re を使用して IP アドレスと URI パスをマッチさせます。 return true を使用してリクエストを許可し、 exit(403) を使用して拒否します。

制限

• ドメイン名ごとに最大 50 個のルール条件を作成できます。

• 各ルール条件には、最大 20 個のサブルールを含めることができます。

• コンソールまたは OpenAPI でルール条件を設定する際に、正規表現一致演算子または正規表現不一致演算子を使用することはできません。ただし、これらの演算子を使用している既存の設定は表示できます。これらの演算子を使用するには、ESA を使用してください。

• 1つのドメイン名内のすべての機能において、ルール条件を参照できる合計回数は最大 5 回です。

• ルール条件は最大 3 レベルまでネストでき、各レベルで独立した論理関係を設定できます。

• キャッシュの有効期限の設定や送信リクエストヘッダーの変更などの機能がルール条件を参照する場合、機能の設定順序ではなく、条件の優先度によって実行順序が決まります。

• 前述の制限事項のうち、ルール条件 (最大 50 個)、サブルール (最大 20 個)、およびネスト (最大 3 レベル) はハードリミットであり、申請により増やすことはできません。1つの高速化ドメイン名内のすべての機能におけるルール条件の総参照回数の上限 (デフォルトは 5 回) は、申請により増やすことができます。

  • 1つのドメイン名あたりのルール条件の総参照回数 (デフォルトは 5 回) を増やすには、チケットを送信 してください。チケットには、制限を増やしたい高速化ドメイン名、目標参照数、およびビジネスシナリオの説明を記載してください。

  • 別の高速化ドメイン名を追加する際には、そのドメインのルール条件の参照数を増やすために別のチケットを送信してください。手順は最初の申請と同様です。

• クライアント IP、URI、ファイルの拡張子、ファイル名、User-Agent などのマッチタイプでは、各条件に最大 32 個のマッチ値を設定できます。大規模なクライアント IP 許可リストがある場合は、複数の IP アドレスを CIDR ブロック (例: 120.209.XXX.X/24) に統合して IP アドレスを設定し、マッチ値の数を節約してください。

• 最大 32 個の User-Agent マッチ値を設定できます。この制限を超える値は無視されます。多数の User-Agent をマッチングするには、ワイルドカード (*) を使用して類似した User-Agent 値を統合してください (例: *Chrome* はすべての Chrome ブラウザバージョンにマッチします)。または、より柔軟なマッチングロジックを実現するために EdgeScript を使用してください。

機能の優先度と実行ロジック

ルールエンジンを設定する際は、次の機能の優先度と実行ロジックを考慮してください：

• Referer ホットリンク保護はルールエンジンより優先されます：リクエストに Referer ヘッダーが含まれている場合、システムはまず Referer ブラックリストに照らしてリクエストを評価します。リクエストがブラックリストに一致する場合はブロックされます。一致しない場合は、次に Referer ホワイトリストに照らして評価します。ホワイトリストに一致するリクエストは許可され、ルールエンジンをバイパスして処理が続行されます。ホワイトリストに一致しないリクエストはブロックされます。Referer ヘッダーが空の場合、リクエストはこのロジックをバイパスし、ルールエンジンによって評価されます。

• ルール条件を使用する機能の実行順序：キャッシュ有効期限やアウトバウンドリクエストヘッダーの変更などの機能がルール条件を使用する場合、システムは機能の設定順序ではなく、関連するルール条件の優先度に基づいて実行します。たとえば、キャッシュ有効期限とオリジンリクエストパラメーターの書き換えが異なる優先度のルール条件を使用する場合、システムはルール条件の優先度順 (高いものから低いものへ) に実行します。

• URL 認証とキャッシュ間の競合のトラブルシューティング：URL 認証を設定した後に、認証パラメーターなしでリクエストにアクセスできてしまう、または有効なリンクが誤ってブロックされるなどの予期しない動作が発生した場合は、次の項目を順に確認してください：

  1. WAF ホワイトリストが設定されているかどうかを確認してください。WAF ホワイトリストは、 CDN および の認証ロジックをバイパスして、リクエストを直接通過させる可能性があります。

  2. URL パラメーターの無視機能によって auth_key などの認証パラメーターが除外されていないことを確認してください。この設定によって認証パラメーターが除外されると、キャッシュヒットに対する認証検証がスキップされます。

  3. キャッシュキールールが認証パラメーターを無視していないことを確認してください。無視している場合、異なる認証パラメーターを持つリクエストが同じキャッシュされたコンテンツを受け取る可能性があり、事実上、認証がバイパスされます。

ルール条件の構文

ルール条件は、論理演算子を使用して 1 つ以上の条件式を組み合わせたものです。本セクションでは、構文について説明します。

IP アドレス検証モード

ルールエンジンには 2 つの IP アドレス検証モードがあり、選択したモードによって CDN POP がクライアント IP アドレスを識別する方法が異なります。

• POP 接続 IP：このモードは、クライアントが CDN POP に接続するために使用する IP アドレスに一致します。クライアントと CDN POP 間のトラフィックがプロキシサーバーを通過する場合、POP 接続 IP はプロキシサーバーの IP アドレスになります。

• XFF IP：このモードは、x-forwarded-for リクエストヘッダー内の左端の IP アドレスを照合します。クライアントと CDN POP の間にプロキシサーバーが使用されているかどうかにかかわらず、XFF IP は常にクライアントの実際の IP アドレスになります。

認証モードの選択は、クライアントリクエストがプロキシサーバーを通過してから CDN POP に到達するかどうかによって決まります。

ルール条件を参照する機能が有効になる CDN POP のロケーションは、選択すべき IP アドレス検証モードにも影響することにご注意ください。 L2 POP で有効になるオリジンフェッチ機能の場合、ユーザーリクエストが経由する L1 POP は中間プロキシサーバーに相当します。

例：クライアントの実際の IP アドレスを 10.10.10.10、プロキシ IP アドレスを 192.168.0.1 とします。

• プロキシサーバーなしの場合：

  • x-forwarded-for リクエストヘッダーの値は10.10.10.10です。

  • クライアントのリアル IP アドレス (x-forwarded-for リクエストヘッダーの左端の IP) = クライアントと CDN POP 間の接続を確立するために使用される IP アドレス = 10.10.10.10。

• プロキシサーバーありの場合：

  • x-forwarded-for リクエストヘッダーの値は 10.10.10.10,192.168.0.1 です。

  • クライアントのリアル IP アドレス (x-forwarded-for リクエストヘッダーの左端の IP) は 10.10.10.10 です。

  • クライアントとCDN POP 間の接続確立に使用される IP アドレス = プロキシサーバーの IP アドレス = 192.168.0.1。

  • クライアントのリアル IP アドレス (x-forwarded-for リクエストヘッダーの左端の IP) は、クライアントが CDN POP との接続を確立する際に使用する IP アドレスとは異なります。

特定のリージョンでは、一部のインターネットサービスプロバイダー (ISP) がエンドユーザーにプライベート IP アドレスを割り当てることがあるため、CDN ノードはユーザーのプライベート IP アドレスを受信します。

ルール条件をサポートする機能