CloudflareのPage Rulesを理解した上で設定する(Page Rulesチュートリアル)
CloudflareのPage Rulesを理解した上で設定する(Page Rulesチュートリアル)
Page Ruleでは、リクエストが定義されたURLパターンの1つに一致する時は、いつでも特定のアクションがトリガーされます。Page Ruleの作成方法と利用できる様々な設定について説明します。
本記事の内容
概要
Page Ruleを定義し、URLパターンが一致するたびに、複数のアクションをトリガーすることができます。Page Ruleは、RulesアプリのPage Rulesタブで利用できます。
ページルール数で許可されているのデフォルトの上限は、以下の通り、ドメインプランによって異なります。
プラン | 許可されているページルール数の上限 |
---|---|
Free | 3 |
Pro | 20 |
Business | 50 |
Enterprise | 125 |
Freeプラン、Proプラン、Businessプランのドメインに関しては、(最大100まで) 追加のルールを購入できます。
はじめに
ページルールの基本的な2つの動作を理解しておくことが重要です:
- 優先度が高く、一致しているページルールだけがリクエストに対して有効となります。
- Cloudflareのダッシュボードでは、ページルールは降順で優先順位が付けられます。最も順位が高いルールが最上部に表示されます。
Page Ruleは、次のフォーマット(5つのセグメントから構成される)に基づくURLパターンと一致します: この4つのセグメントから成るURLの例は以下のようになります: _スキーム_と_ポート_のセグメントは任意です。省略した場合、_スキーム_が _http://プロトコルと_https:// プロトコル両方と一致します。_ポート_を特定しない場合、ルールはすべてのポートと一致します。 最後に、Page Ruleはいつでも無効にできます。ルールが無効になっている間、アクションはトリガーされませんが、ルールはRulesアプリのPage Rulesタブで表示され、編集可能です。そしてドメインで許可されるルール数にカウントされます。_「下書きとして保存」_オプションでデフォルトで無効になるPage Ruleを作成できます。 ページルール作成の手順: 既存のルールの変更方法: URLセグメントにアスタリスク記号 (*) を使って特定のパターンと一致させることができます。例えば、 は、以下と一致します: example.com/foo/* は、example.com/fooと一致しません。 しかし、 example.com/foo* は一致します。 _$X_構文を使って、後で一致するワイルドカードを参照することができます。_X_は、globパターンのインデックスを示します。したがって、$1は最初のワイルドカードの一致を表し、$2は二番目のワイルドカードの一致を表すことになります。 これは、_転送 URL_で特に便利なものです。例: 以下を転送することにします: 転送先: このルールが一致するのは: これは次に転送されることになります: 転送 URLで、_$の文字をそのまま使うには、先頭にバックスラッシュ(\)を追加して、\$_とエスケープさせます。 リクエストがページルールで定義されているURLパターンと一致すると、設定でCloudflareのアクションがコントロールされます。設定を使うと、いくつかのダッシュボードアプリで、複数のCloudflare機能を有効/無効にすることができます。以下の点に注意してください: 以下は、利用可能な設定の全リストで、Cloudflare Page Rules UIで表示される順序を示しています。 |
設定 | 説明 | プラン HTTPSの常時使用 | Cloudflare SSL/TLSアプリにある「Edge証明書」タブの**常時HTTPSを使用する**機能をOnまたはOffにします。有効にすると、301リダイレクトを通して、_http://_URLが_https://_に変換されます。 この選択肢がまだ表示されるなら、アクティブなEdge証明書がないということです。 | |
| Auto Minify | どのファイル拡張子が自動的に縮小されるかを示します。
詳細を見る。 | |
| HTTPSの自動リライト | Cloudflare SSL/TLSアプリにある「エッジ証明書」タブのHTTPS の自動リライト機能をOnまたはOffにします。詳細を見る。 | |
| Browser Cache TTL(ブラウザキャッシュTTL) | クライアントブラウザでキャッシュされるリソースが有効な状態を維持できる時間を管理します。Cloudflare UIとAPIの両方で、Enterpriseプランではないお客様がブラウザCache TTLを_0_に設定することは禁止されています。詳細を見る。 | |
| Browser Integrity Check | 訪問者のブラウザで、通常スパマーと特定のボットに関連づけられるヘッダーを調べます。
詳細を見る。 | |
| Bypass Cache on Cookie | リクエストにあるCookie名に対して正規表現が一致する場合は、オリジンサーバーからキャッシュをバイパスし、リソースをフェッチします。 この設定と_Cache On Cookie_設定を同じPage Ruleに追加する場合、_Cache On Cookie_は_Bypass Cache on Cookie_より優先されます。 下記の追加詳細で、限定的な正規表現のサポートについてご覧ください。 | |
| デバイスタイプ別にキャッシュする | 訪問者のデバイスタイプに基づき、キャッシュするコンテンツを分けます。詳細を見る。 | |
| Cache Deception Armor | 静的アセットをキャッシュしておく一方で、Web Cache Deception攻撃から保護します。この設定では、URLの拡張子が戻された_Content-Type_と一致しているか検証します。詳細を見る。 | |
| キャッシュキー | _カスタムキャッシュキー_とも呼ばれています。 キャッシュするリソースを決定する際、どの変数を含めるかを具体的に管理します。お客様は、URLだけではなく他の要素にも基づいてキャッシュするものを決定できます。詳細を見る。 | |
| キャッシュレベル | 選択したオプションに基づき、カスタムCachingを適用します。 バイパス -Cloudflareはキャッシュしません。 クエリ文字列なし - クエリ文字列がない場合、キャッシュからリソースを配信します。 クエリ文字列を無視する-クエリ文字列に関係なく、全員に同じリソースを配信します。 標準 - クエリ文字列を持つ静的コンテンツ全てをキャッシュします。 すべてをキャッシュする- すべてのコンテンツを静的コンテンツとして扱い、Cloudflareのデフォルトでキャッシュされたコンテンツを超えて、すべてのファイルタイプをキャッシュします。Page Ruleで エッジCache TTLを設定している場合を除き、オリジンWebサーバーからのCacheヘッダーを尊重します。エッジCache TTL>0__と組み合わせると、すべてをキャッシュするでは、オリジンWebサーバーのレスポンスからのCookieを削除します。 | |
| Cache on Cookie (Cookieのキャッシュ) | Cookie名に一致する正規表現に基づいて、すべてをキャッシュする オプション(_キャッシュレベル_設定)を適用します。 この設定と_Bypass Cache on Cookie_(Cookieのキャッシュのバイパス)の両方をPage Ruleに追加する場合、 _Cache On Cookie_が_Bypass Cache on Cookie_より優先されます。 | |
| ステータスコードによるCache TTL | Enterpriseのお客様は、オリジンWebサーバーの応答ステータスに基づいてCache Time to Live (TTL)を設定できます。Cache TTLは、有効期限が切れていると判定されたり、Cacheから破棄される前にCloudflareネットワーク内のリソース期間を参照します。ステータスコードは、リソースのオリジンが戻します。 応答ステータスに基づくCache TTLの設定は、静的ファイルの初期設定キャッシュ動作(標準Caching)をオーバーライドし、オリジンWebサーバーによって送信されたCache指示をオーバーライドします。非静的アセットをキャッシュするには、Page Ruleを使ってCache EverythingのCacheレベルを設定してください。no-store Cache-Control または Low TTL(max-age/s-maxageを使用)を設定すると、オリジンWebサーバーへのリクエストが増加し、パフォーマンスが低下します。
詳細はこちら。 | |
| Disable Apps(アプリの無効化) | 有効化されているCloudflare アプリを全てOffにします。 | |
| Disable Performance(パフォーマンスの無効化) | Offにする: | |
| Railgunの無効化 | CloudflareスピードアプリのRailgun機能をOffにします。 | |
| セキュリティの無効化 | Offにする: | |
| Edge Cache TTL(エッジキャッシュTTL) | Cloudflareエッジネットワークでリソースをキャッシュする時間を特定します。 Edge Cache TTL は、レスポンスヘッダーでは表示されません。 最小_Edge Cache TTL_ は、プランタイプによって異なります: Free - 2時間 | |
| メールの暗号化 | Cloudflare Scrape ShieldアプリにあるCloudflareメールの暗号化機能をOnまたはOffにします。
詳細を見る。 | |
| Forwarding URL(転送URL) | HTTP 301/302 リダイレクト_を使って、1つのURLを別のURLにリダイレクトします。
上記のワイルドカードの一致と参照について、お読みください。_ | |
| ホストヘッダーオーバーライド | 特定のホストヘッダーを適用します。
詳細を見る。 | |
| IP ジオロケーションヘッダー | Cloudflareは、訪問者の国別コードを含む_CF-IPCountry_HTTPヘッダーを追加します。 | |
| Mirage | Cloudflare SpeedアプリのCloudflare MirageをOnまたはOffにします。
詳細を見る。 | |
| 日和見暗号化 | Cloudflare SSL/TLSアプリにある「エッジ証明書」タブのCloudflare 日和見暗号化機能をOnまたはOffにします。詳細を見る。 | |
| オリジンキャッシュコントロール | オリジンCacheコントロールはFreeドメイン、Proドメイン、Businessドメインにおいてデフォルトで有効になっており、Enterpriseドメインについてはデフォルトで無効になっています。 | |
| オリジンエラーページのパススルー | オリジンサーバーから送信された問題から生じたCloudflareエラーページをOnまたはOffにします。有効にした場合、この設定はオリジンで発行されたエラーページをトリガーします。 | |
| Polish | CloudflareSpeedアプリのPolish 機能のオプションを適用します。詳細を見る。 | |
| 検索文字列のソート | 検索文字列の並び替えをOnまたはOffにします。検索文字列が同じ構造の時、キャッシングが向上します。
詳細を見る。 | |
| オーバーライドを解決 | オリジンアドレスを変更して、この設定で指定される値に変更します。
詳細を見る。 | |
| 強いETagsを尊重する | Cloudflare Cacheとオリジンサーバー間のバイトごとの同等性チェックをOnまたはOffにします。
詳細を見る。 | |
| 応答バッファリング | サイト訪問者にオリジンサーバーからのファイルを転送する前に、Cloudflareがファイル全体を受け取るまで待機すべきかどうかについてOnまたはOffにします。デフォルトでは、オリジンサーバーからパケットを受け取る時に、Cloudflareがそれをクライアントに送信します。 | |
| Rocket Loader | Cloudflare SpeedアプリにあるCloudflare Rocket Loader機能をOnまたはOffにします**。**
詳細を見る。 | |
| セキュリティレベル | セキュリティアプリからセキュリティレベル機能のオプションを管理します。
詳細はこちら。 | |
| サーバー側の除外 | CloudflareScrape ShieldアプリのServer Side Excludes機能をOnまたはOffにします。
詳細を見る。 | |
| SSL | CloudflareSSL/TLSアプリで「エッジ証明書」タブのSSL機能のオプションを管理します。詳細はこちら。 | |
| True Client IPヘッダー | CloudflareネットワークアプリのTrue-Client-IP ヘッダー機能をOnまたはOffにします。
詳細を見る。 | |
| Webアプリケーションファイアウォール(旧バージョン) | セキュリティ>WAF>マネージドルール>の順でWAFマネージドルールをONまたはOFFにします。
詳細はこちら。 Page Rulesを介して、個々のWAFマネージドルールを有効にしたり無効にしたりできません。 | | **Page Ruleの設定の問題により、「エラー 500(内部サーバーエラー)」**が発生する 根本原因:Page Rule の設定問題に起因する可能性があります。_転送URL_ルールのような、2つのワイルドカードを使用するPage Ruleを作成する場合、$2 プレースホルダーが2番目のワイルドカードを指すルールを作成することができます。下記の例をご覧ください。 同じルールを更新する場合、URLが一致する場合欄のワイルドカードを1つ削除して保存することができます。下記の例をご覧ください。 これを行った場合、$2 プレースホルダーが存在しないワイルドカードを参照することになるため、URLがPage Rule をトリガーする際「エラー 500(内部サーバーエラー)」が発生します。 解決策:Page Ruleを更新し、2番目のワイルドカードを参照する_$2_を削除します。ワイルドカードが1種類しかなければ、_$1_のみが使用されます。 この設定は、BusinessプランとEnterpriseプランのお客様にご利用いただけます。 Bypass Cache on Cookie設定は、以下のように基本的な正規表現(regex)をサポートします。 制限事項には以下が含まれます: 様々なプラットフォームでBypass Cache on Cookieを設定する方法については、こちらの記事を参照してください。 **注意:**この設定とEnterpriseプラン限定の_Cache on Cookies_の設定の両方を同じPage Ruleに追加する場合は、_Cache on Cookie_が、_Bypass Cache on Cookie_よりも優先されます。 Page Ruleを保存する際、CloudflareはURLが一致する場合フィールドで現行の各ゾーン名の後にスラッシュ(/)があることを確認します。たとえば、現行のゾーン名が Page RuleのURLが一致する場合フィールドでポートを特定する場合、ポートは次のどれかである必要があります。 現在のリクエストのURLがPage RuleとWorkersカスタムルートの両方と一致する場合、適用されないPage Rule設定がいくつかあります。WorkersでPage Rulesを使う場合の詳細については、開発者ドキュメントのWorkers: Page Rulesを参照してください。
Page Ruleの作成
Page Ruleの編集
ワイルドカードの一致と参照について
役に立つヒント
ワイルドカードの一致を参照
Page Ruleの設定の概要
Pro - 1時間
Business - 1秒
Enterprise - 1秒
既知の問題
その他の詳細
Bypass Cache on Cookie 設定
ゾーン名はスラッシュ(/)で終わる必要がある
example.com
の場合:example.com
は example.com/
として保存example.com/path/example.com
は example.com/path/example.com/
として保存example.com/some-path/cloudflare.com
の場合は、ゾーン名はcloudflare.com
ではないため、最後のスラッシュ_なし_で保存されることに留意してください。
Page Rulesがサポートするネットワークポート
WorkersでPage Rulesを使う
関連リソース