ルールエンジンは、条件付きルールを設定するためのグラフィカルユーザーインターフェースを提供します。これらのルールは、ユーザーリクエストのパラメーターを分析して特定の構成が適用されるかどうかを判断することで、CDN や の設定ポリシーの適用を柔軟かつ正確にコントロールできます。
背景情報
Alibaba Cloud CDN コンソールは、キャッシュの有効期限の設定やオリジンへのパラメータの書き換えなどの基本的な機能を提供し、ほとんどの一般的なニーズを満たします。 パス /example を含むリクエストを特定のオリジンサーバーにルーティングするなど、特別な要件については、ルールエンジンを使用してカスタム設定を作成できます。 さらに、Alibaba Cloud CDN は、柔軟性の高いカスタマイズをサポートし、Fastly や CloudFront などのサードパーティの CDN プロバイダーと同様のきめ細やかなポリシーを設定できる EdgeScript 機能を提供します。
機能 | 基本機能 | 基本機能とルールエンジン | EdgeScript |
機能の実装 | 汎用的な設定 | グラフィカルインターフェイスを使用して、条件付きのフィルタリングルールを作成できます。 URI、ヘッダー、クッキー、クエリ文字列など、複数の一致タイプと AND/OR の論理結合に対応しています。 | 非常に柔軟なカスタマイズをサポートしており、カスタムスクリプティングが必要な高度なシナリオに適しています。 |
シナリオ | 汎用的なシナリオ | 高度なカスタムシナリオ | 完全にカスタムのシナリオ |
使いやすさ | 高 | 中 | 低 |
設定の柔軟性 | 低 | 中 | 高 |
複雑なロジックと EdgeScript
ルールエンジンは、基本的な AND/OR の論理的な組み合わせをサポートしており、ほとんどの条件付きフィルタリングシナリオに適しています。ただし、 EdgeScript を使用するかどうかを判断する際には、以下のシナリオが参考になります。
複雑な正規表現マッチング：ルールエンジンの正規表現演算子は、デフォルトで無効になっています。有効にするには、チケットを送信する必要があります。頻繁に正規表現マッチングを行う場合、 EdgeScript はネイティブでサポートしているため、より便利です。
精密な多次元の組み合わせ：ルールエンジンでは、クライアント IP と User-Agent の両方を正規表現で照合する （例えば、User-Agent に特定のキーワードが含まれる特定の IP 範囲 からのリクエストをブロックする） といった、複数の基準を組み合わせた複雑な評価の設定は煩雑です。 EdgeScript を使用すると、スクリプトのロジックで複数の条件を柔軟に組み合わせることができます。
特定の URI に対する精密なアクセス制御：なお、Referer または IP ホワイトリスト に基づいて特定の URI へのリクエストをブロックするだけであれば、ルールエンジンを直接使用します。この場合、EdgeScript は不要です。
制限
ドメイン名あたり、最大 50 件のルール条件を作成できます。
各ルール条件には、最大 20 件のサブルールを含めることができます。
コンソールでルール条件を設定する場合、または OpenAPI を使用する場合、「正規表現一致」または「正規表現不一致」の演算子は使用できません。ただし、これらの演算子を使用している既存の設定は表示できます。これらの演算子を使用するには、ESA を使用してください。
1 つのドメイン名内のすべての機能において、1 つのルール条件はデフォルトで 5 回参照できます。
ルール条件は最大 3 階層までネストでき、各階層で独立した論理関係を設定できます。
キャッシュの有効期限の設定や送信リクエストヘッダーの変更などの機能がルール条件を参照する場合、実行順序は機能の設定順ではなく、条件の優先度によって決まります。
前述の制限のうち、ルール条件 50 件、サブルール 20 件、ネスト 3 階層の上限は、リクエストしても引き上げられないハードリミットです。1 つの高速化ドメイン名内のすべての機能におけるルール条件の参照回数の合計上限は、デフォルトで 5 回ですが、リクエストにより引き上げることができます。
1 つの高速化ドメイン名におけるルール条件の参照回数の合計上限を引き上げるには、チケットを送信し、次の情報を提供してください：上限を引き上げたい高速化ドメイン名、参照回数の目標値、ビジネスシナリオの説明。
後から別の高速化ドメイン名を追加する場合、そのドメイン名についても参照回数を引き上げるために、別途チケットを送信する必要があります。手順は初回のリクエストと同じです。
この上限を自動的に引き上げる仕組みはありません。チケットを送信した後、リクエストはバックエンドチームによる手動レビューで処理されます。
各条件では、クライアント IP、URI、ファイル拡張子、ファイル名、User-Agent などの一致タイプに対して、最大 32 件の一致値を設定できます。クライアント IP の許可リストが大きい場合は、一致値のクォータを節約するために、複数の IP アドレスを CIDR ブロック (例：
120.209.XXX.X/24) にまとめてください。User-Agent の一致値は最大 32 件まで設定できます。この上限を超える値は無視されます。多数の User-Agent を一致させるには、ワイルドカード (
*) を使用して類似する値をまとめる (例：*Chrome*) は Chrome ブラウザーのすべてのバージョンに一致します) か、より柔軟なマッチングロジックのために EdgeScript を使用してください。
機能の優先度と実行ロジック
ルールエンジンを構成する際は、次の機能の優先度と実行ロジックを考慮してください。
Referer ホットリンク保護はルールエンジンより優先されます：リクエストに Referer ヘッダーが含まれている場合、システムはまず Referer ブラックリストとホワイトリストと照合します。このうち、ホワイトリストとの照合結果が優先されます。リクエストがホワイトリストに一致する場合は、ルールエンジンをバイパスして処理が続行されます。リクエストがホワイトリストに一致しない場合、システムは直ちにブロックします。Referer ヘッダーが空の場合、リクエストはこのロジックをバイパスし、ルールエンジンによって評価されます。
ルール条件を使用する機能の実行順序：キャッシュ有効期限やアウトバウンドリクエストヘッダーの変更などの機能がルール条件を使用する場合、システムは機能の構成順序ではなく、関連付けられたルール条件の優先度に基づいて実行します。たとえば、キャッシュ有効期限とオリジンへのパラメータ書き換えが異なる優先度のルール条件を使用している場合、システムはルール条件の優先度順 (高い順から低い順) に実行します。
URL 認証とキャッシュ間の競合のトラブルシューティング：URL 認証を構成した後、認証パラメーターなしでリクエストにアクセスできる、または有効なリンクが誤ってブロックされるなどの予期しない動作が発生した場合は、次の項目を順番に確認してください。
WAF ホワイトリストが構成されているかどうかを確認してください。WAF ホワイトリストは CDN または の URL 認証ロジックをバイパスし、リクエストが直接処理される可能性があります。
URL パラメーターの無視機能が
auth_keyなどの認証パラメーターを削除していないことを確認してください。これにより、キャッシュヒット時に認証がスキップされる可能性があります。キャッシュキールールが認証パラメーターを無視していないことを確認してください。無視している場合、異なる認証パラメーターを持つリクエストが同じキャッシュされたコンテンツを受け取り、事実上認証がバイパスされる可能性があります。
ルール条件の構文
ルール条件とは、論理演算子を使用して 1 つ以上の条件式を組み合わせたものです。以降のセクションでは、構文について説明します。
論理演算子
論理演算子は、ネストされた条件セットを含め、同じレベルの条件を評価します。サポートされている演算子は and と or です。
and：論理 AND 演算子。すべての条件が true の場合にのみ、一致します。or：論理 OR 演算子。少なくとも 1 つの条件が true の場合に一致します。たとえば、異なる状況下でヘッダーを追加するために、同じレスポンスヘッダーに対して複数のルール条件を構成できます。例： URI に/path-aが含まれている[または] URI に/path-bが含まれている場合、システムはレスポンスヘッダーを追加します。
条件式のパラメーター
ルール の最小単位である条件式には、次のパラメーターが含まれます。
パラメーター | 条件 関数パラメーター | 説明 | 必須 |
条件一致 | match | 条件一致式を指定します。 | はい |
論理演算子 | logic | 条件一致式の論理演算子を指定します。有効な値は | はい |
条件 | criteria | 評価する条件式の配列を指定します。 | はい |
一致タイプ | MatchType | クライアントリクエスト 内の一致対象となる情報のタイプを指定します。 | はい |
一致オブジェクト | MatchObject | 一致タイプ をさらに絞り込みます。たとえば、クライアント IP アドレスは、POP 接続 IP または XFF IP として指定できます。 | いいえ |
一致演算子 | MatchOperator | 比較方法を指定します。 | はい |
一致値 | MatchValue | クライアントリクエスト のデータと比較する値を指定します。 | はい |
条件の否定 | negate | 条件式の結果を否定するかどうかを指定します。有効な値は true と false です。 | はい |
大文字と小文字の区別 | caseSensitive | 一致値の比較で大文字と小文字を区別するかどうかを指定します。 | いいえ |
ルール条件名 | name | ルール条件 の名前を指定します。 | はい |
ステータス | status | ルール条件 のステータス を指定します。 | はい |
条件式の設定
マッチタイプ | 条件 関数パラメーター | 説明 | 照合対象 | マッチ演算子 | マッチ値 | 大文字と小文字の区別 | Nginx 変数 |
プロトコル | scheme | クライアントリクエストで使用されるプロトコル (HTTP や HTTPS など) です。 | 該当なし |
|
| 該当なし | $scheme |
リクエストメソッド | method | クライアントリクエストで使用されるリクエストメソッド (GET や PUT など) です。 | 該当なし |
|
| 該当なし | $request_method |
URI (パス) | uri | クライアントリクエスト URL のパス部分です。リクエストパラメーターは除きます。例： | 該当なし |
| ワイルドカードの |
| $raw_uri or $uri |
ファイル名 | basename | クライアントがリクエストしたファイルの名前です。例： name1。 | 該当なし |
| ワイルドカードの |
| - |
拡張子 | extension | クライアントがリクエストしたファイルの拡張子です。システムは、最後のドット (.) からファイル名の終わりまでを拡張子として識別します。例： | 該当なし |
| ワイルドカードの |
| - |
ホスト名 | hostname | クライアントリクエストのホスト名です。一致順序：リクエスト URL 内のホスト > | 該当なし |
| クライアントリクエストのホストです。複数の値を入力できます。 |
| $host or $http_host |
クライアント IP アドレス | clientip | クライアントの IP アドレスです。IPv4 (例： |
説明 POP 接続 IP および XFF IP の詳細については、「IP アドレス検証モード」をご参照ください。 |
| 240e:XXX:3004:2:3:0:0:3f7 などの IPv6 アドレス、および 120.209.XXX.XXX/31 などの CIDR ブロックに対応しています。複数の値を入力できます。 | 該当なし | $remote_addr |
クライアント IP バージョン | clientipVer | クライアントアドレスの IP バージョンです (IPv4 または IPv6)。 |
説明 POP 接続 IP および XFF IP の詳細については、「IP アドレス検証モード」をご参照ください。 |
|
| 該当なし | - |
インターネットサービスプロバイダー (ISP) | geolocation | クライアント IP アドレスが属する ISP です。 |
説明 POP 接続 IP および XFF IP の詳細については、「IP アドレス検証モード」をご参照ください。 |
| ドロップダウンリストから ISP を選択するか、文字を入力してオプションを絞り込むことができます。ID または名前によるあいまい検索が可能です。複数の値を入力できます。 | 該当なし | $ip_isp_id |
IP ジオロケーション | geolocation | クライアント IP アドレスの地理的な場所です。 |
説明 POP 接続 IP および XFF IP の詳細については、「IP アドレス検証モード」をご参照ください。 |
| ドロップダウンリストから場所を選択するか、文字を入力してオプションを絞り込むことができます。ID または名前によるあいまい検索が可能です。複数の値を入力できます。 | 該当なし | $ip_country_id |
リクエストパラメーター | querystring | リクエスト URL 内のパラメーターです。 | パラメーター名を入力します。 |
| ワイルドカードの |
| $arg_{name} |
リクエストヘッダー | header | クライアントリクエスト内のヘッダーです。 | パラメーター名を入力するか、ドロップダウンリストからパラメーターを選択できます。 |
| 複数の値を入力できます。 |
| $http_{name} |
Cookie | cookie | クライアントリクエスト内の Cookie です。 | Cookie 名を入力します。 |
| ワイルドカードの |
| $cookie_{name} |
User-Agent | useragent | クライアントリクエスト内の | 該当なし |
| ドロップダウンリストから値を選択するか、 |
| $http_user_agent |
範囲バケット | range | 指定されたパーセンテージのクライアントリクエストに一致します。 | 該当なし |
| パーセンテージ値を入力します。 | 該当なし | - |
時間 | time | クライアントリクエストが発生した時間です。時間は UTC+08:00 です。例：09:10～14:22。 | 該当なし |
| 「09:10～14:22」のように時間範囲を入力します。この例は、09:10 から 14:22 までの期間を表します。 | 該当なし | - |
Nginx 変数 | ngxvar | 上記の変数が要件を満たさない場合は、Nginx 変数を使用します。使用できる変数の一覧については、Nginx の公式ドキュメントをご参照ください。 | ドロップダウンリストから変数を選択するか、変数名を入力できます。 |
| 複数の値を入力できます。 | Not applicable | ${name} |
条件式の一般的な設定に関する注意事項
URI (パス) の一致開始点：URI 照合では、照合する値はドメイン名の後の最初の
/から始まるパス部分です。値にはドメイン名やリクエストパラメーターは含まれません。リクエストhttps://example.com/path/file.html?key=valueの場合、照合する値は/path/file.htmlです。照合値は/で始まる必要があります。拡張子の一致形式：拡張子で照合する場合、照合値にはドット (
.) を含める必要があります。たとえば、.txtファイルに一致させるには、txtではなく.txtと入力します。そうしないと、照合が失敗する可能性があります。ワイルドカードの使用例：URI と拡張子の照合では、ワイルドカードの
?(1 文字に一致) と*(0 文字以上に一致) を使用できます。一般的な例は次のとおりです。/*.pdf：ルートディレクトリ内のすべての PDF ファイルに一致します。/api/*/data：/api/配下の任意のサブディレクトリにあるdataパスに一致します。.??：.jsや.tsなど、すべての 2 文字の拡張子に一致します。
IP アドレス検証モード
ルールエンジンは、2 つの IP アドレス検証モードを提供しています。選択したモードは、CDN または ノードがクライアント IP アドレスを識別する方法に影響します。
POP 接続 IP： このモードは、クライアントが CDN または ノードへの接続に使用する IP アドレスと照合します。クライアントと CDN または ノードの間にプロキシサーバーが使用されている場合、POP 接続 IP はプロキシサーバーの IP アドレスになります。
XFF IP： このモードは、
x-forwarded-forリクエストヘッダー内の最も左側の IP アドレスと照合します。XFF IP は、クライアントと CDN または ノードの間にプロキシサーバーが使用されているかにかかわらず、常にクライアントの実際の IP アドレスです。
検証モードの選択は、クライアントリクエストが CDN または ノードに到達する前にプロキシサーバーを経由するかどうかによって決まります。
なお、CDN または ノード上で機能が有効になる場所も、IP アドレス検証モードに影響します。L2 ノードで有効になるオリジン設定に関連する機能の場合、リクエストが通過する L1 ノードは中間プロキシサーバーとみなされます。
例： 実際のクライアント IP アドレスが 10.10.10.10 で、プロキシサーバーの IP アドレスが 192.168.0.1 であると仮定します。
プロキシサーバーなしの場合：
x-forwarded-forリクエストヘッダーの値は10.10.10.10です。クライアントの実際の IP アドレス (x-forwarded-for リクエストヘッダーの左端の IP) = クライアントと CDN ノード間の接続確立に使用される IP アドレス =
10.10.10.10。
With a proxy server:
The value of the
x-forwarded-forrequest header is10.10.10.10,192.168.0.1.The real client IP address (the leftmost IP address in the
x-forwarded-forrequest header) is10.10.10.10.Client-to-CDN node connection IP = Proxy server IP =
192.168.0.1.The real client IP address (the first IP address from the left in the x-forwarded-for request header) ≠ the IP address of the client connection to the CDN node.
Some internet service providers (ISPs) in specific regions may assign private IP addresses to end-users. As a result, nodes may receive a user's private IP address.
Private IP addresses fall into three ranges:
Class A private IP address: 10.0.0.0 to 10.255.255.255, subnet mask: 10.0.0.0/8
Class B private IP address: 172.16.0.0 to 172.31.255.255, subnet mask: 172.16.0.0/12
Class C private IP address: 192.168.0.0 to 192.168.255.255, subnet mask: 192.168.0.0/16
マッチ演算子 (matchOperator)
演算子 | 条件関数のパラメーター | 説明 |
等しい |
| 変数が指定された一致する値と完全に等しいか、等しくない場合にのみ条件が満たされます。 |
等しくない |
| |
存在する |
| リクエストに指定された変数が存在するかどうかに応じて、条件が満たされます。 |
存在しない |
| |
いずれかを含む |
| 変数が指定された一致する値の いずれか を含む (またはいずれも含まない) 場合に条件が満たされます。最大 32 個の一致する値がサポートされています。 2 種類の包含マッチングがサポートされています：
|
いずれも含まない |
| |
より大きい |
| つまり、 |
より小さい |
| つまり、 |
以上 |
| つまり、 |
以下 |
| つまり、 |
正規表現一致 |
| 変数を正規表現と照合します。 説明 コンソールまたは OpenAPI を使用してルールを設定する場合、これらの正規表現演算子は使用できません。ただし、既存の設定を表示することはできます。正規表現関連のマッチ演算子を使用するには、チケットを送信するか、Edge Security Acceleration (ESA) を使用してください。 |
正規表現不一致 |
|
ワイルドカード
ワイルドカード | 説明 | パス マッチングの例 |
| 任意の 1 文字に一致します。 |
|
| パス区切り文字 (/) を含まない、0 文字以上の文字列に一致します。 |
|
ルール条件をサポートする機能
カテゴリ | 機能 |
基本設定 | |
キャッシュ設定 | |
オリジン設定 | |
アクセス制御 | |
パフォーマンス最適化 | |
ビデオ設定 | |
トラフィックスロットリング |
設定管理
アクションの管理: ルールエンジン ページは、ルール条件の定義専用です。アクション (キャッシュ有効期限、URL 書き換え、スロットリングなど) を管理するには、その機能の設定ページに移動します。たとえば、キャッシュ有効期限設定がルール条件を参照している場合、[キャッシュ設定] > [キャッシュ有効期限] に移動して表示または変更します。
[リモート認証]：リモート認証 機能はルール条件を参照できません。つまり、ルールエンジンを使用して、いつトリガーされるかを制御することはできません。
認証タイムアウト制限: リモート認証タイムアウトは、最大 3000 ミリ秒 (3 秒) に設定できます。 デフォルト値は 500 ミリ秒です。 これは、システムがサポートする最大値です。
高度なユースケース
ルールエンジンを使用して、次の高度な設定を実装できます：
差別化されたスロットリングポリシー: リクエストによってスロットリングの有無を分けたい場合 (たとえば、署名パラメーターを含む URL はスロットリングし、他の URL はスロットリングしないなど)、またはフォールバックのスロットリングポリシーが必要な場合は、ルールエンジン でルール条件を作成してリクエストを区別します。 次に、リクエスト単位のスロットリング設定で、異なるルール条件を参照し、異なるスロットリング値を設定します。
オリジンフェッチのための IP ベースのカナリアリリース：クライアント IP アドレスに基づいてカナリアリリースを実装したり、特定の IP からのリクエストを異なるオリジンにルーティングしたりするには、ルールエンジンで IP ベースの一致条件を作成します。次に、条件付きオリジン 設定で、これらの条件を参照して異なるオリジンアドレスを指定します。
混合オリジンアーキテクチャに関する推奨事項：オリジンとして WAF と OSS の両方を使用する場合は、それらを複数のプライマリーオリジンとして設定しないでください。代わりに、ルールエンジンを使用して URL パスに基づいた一致条件を作成します。次に、条件付きオリジン 設定で、各パスのリクエストを適切なオリジンに動的にルーティングできます。このアプローチにより、競合を防ぐことができます。
手順
Alibaba Cloud CDN コンソールにログインします。
左側のナビゲーションペインで [ドメイン名 ] をクリックします。
[ドメイン名] ページで、管理対象のドメイン名を見つけ、[アクション] 列の [管理] をクリックします。
指定したドメイン名の左側のナビゲーションバーで、[ルールエンジン]をクリックします。
[ルールの追加]をクリックします。
[ルールの追加]ページで、[ルール名]とルール内容を設定します。
[送信]をクリックして構成を完了します。
一般的な設定シナリオ
以降のセクションでは、3 つの一般的な設定シナリオを実装する方法について説明します。
シナリオ 1：IP 許可リストとリダイレクト
目的：特定の IP アドレスのみがサイトにアクセスできるようにし、他のすべてのトラフィックをメンテナンスページにリダイレクトします。
実装：
ルールエンジン でルール条件を作成します。[一致タイプ] を [クライアント IP] に、[一致演算子] を [いずれにも一致しない] に設定し、許可リストに登録する IP アドレスを [一致する値] として入力します。
[キャッシュ設定] > [URL リライト] でこのルール条件を参照し、一致したリクエスト (許可リストにない IP アドレスからのリクエスト) を、OSS オリジンでホストされている HTML ページなど、指定したメンテナンスページの URL にリダイレクトします。
注意事項：
許可リストにない IP アドレスからのリクエストがリダイレクトされずに 403 エラーを返す場合は、オリジンの競合を引き起こす可能性のある複数の OSS オリジンが設定されていないか確認してください。各 CDN ドメインには、プライマリ OSS オリジンを 1 つだけ設定することを推奨します。
メンテナンスページの URL が公開されており、他のアクセス制御ルールによってブロックされていないことを確認してください。
シナリオ 2：Referer 不正リンク防止と拡張子の一致
目的：ほとんどのファイルに Referer 不正リンク防止を適用し、特定の拡張子をチェックから除外します。
実装：
ルールエンジン でルール条件を作成します。[一致タイプ] を [拡張子] に、[一致演算子] を [いずれにも一致しない] に設定し、除外したい拡張子 (たとえば
.pdf) を [一致する値] として入力します。[アクセス制御] > [Referer 不正リンク防止] で、このルール条件を参照します。これにより、除外された拡張子へのリクエストを除くすべてのリクエストに、Referer 許可リストまたは拒否リストが適用されます。
シナリオ 3：画像およびビデオ以外のファイルへのアクセスブロック
目的： OSS バケットは CDN によって高速化され、外部にコンテンツを配信します。悪意を持って作成されたリンクを介してアクセスされる可能性のある .html ファイルなど、メディア以外のファイルへのリクエストをブロックします。
実装：
ルールエンジン でルール条件を作成します。[一致タイプ] を [拡張子] に、[一致演算子] を [いずれかに一致する] に設定し、[一致する値] として
.html,.htm,.php,.asp,.jspを入力します。別のルール条件を追加します。[一致タイプ] を [クライアント IP] に、[一致演算子] を [いずれにも一致しない] に設定し、許可リストに登録されている IP アドレスを [一致する値] として入力します。
[アクセス制御] で、ルール条件を参照し、一致したリクエストに 403 エラーが返されるようにします。
注意事項：
ルールエンジンはアクセス側のみを制御します。アップロード側でファイルタイプを制限するには、OSS の
PostObjectポリシー (たとえば、starts-with $Content-Type image/を含むポリシーは.htmlファイルのアップロードを拒否します) を使用します。PutObjectAPI はファイルタイプをチェックしないため、この制限を適用できません。